Increase delay but peak appears at earlier time?

[rschmeling]

I am trying to work some bugs out of my program and I am having some difficulties. 

The data collection is being done with a NI 5761 digitizer and NI 7965R FPGA module on a PXIe 1071 chassis.

This is just a very simple VI to collect a signal from a photodiode that is monitoring a laser, and I am trying to change the delay as to when the laser will fire.

As I try varying delays (0,1, and 2 microsec) my peak actually moves to an earlier time that it is being read.  This is completely opposite as to what should be happening and I am thoroughly confused. 

Any suggestions as to why I am seeing this happen?

[rschmeling]

Here is the data that I am seeing with the delays of 0, 1, and 2 microseconds.

[Chris.N]

rschmeling,

I have a few things to say about your program that can hopefully help you.  It appears you are trying to trigger your acquistion with the OK button.  The FPGA VI is much faster than your host VI, so the while loop you have in the FPGA VI is going to iterate many more times than you Windows VI.  Because the mechanical action of the OK button on the FPGA VI is not set to a Latch mechanical action, I think you are acquiring more data than you intend to.  Furthermore, you never flush your DMA FIFO on your host side. Because I believe you are writing more data than you intend to on the FPGA, I also believe that you might be reading stale data from the FIFO on your host VI.  You can take the number of Elements remaining from your FIFO Read Method and follow up with another FIFO Read of that many elements to empty the host side buffer (Be aware that if overflow occurred on the FPGA, you might need an additional flush of the size of your FPGA side buffer).  Finally, I cannot see your subVI responsible for producing the Laser PDL chart. It could be possible that the way you are creating the chart is part of the problem.  

Cheers,

Chris

[rschmeling]

I have attached the scaling vi that I forgot to add. 

I ideally would like to trigger the triggering and the data collection from another channel that I am monitoring.  For right now I am trying to simplify and use the ok button to trigger it. 

I can not use a FIFO mode to clear the FIFO.  Those are for target scoped and vi-defined, the FIFO I am using is a host-target FIFO.  I have collected data at each delay 10 times to compare the timestamp and the is only slight jitter in the peaks at each delay.  I know the FIFO capacity is 16,384 and I am reading only 16,000 points.  If what you say is true wouldn't I see the peaks constantly shift by 384 points?  ( I have attached a spread sheet with the peak times and heights that I have collected at delays of 0,1, and 2.)

I understand the host VI is is going to operate much slower than the target VI.  The target VI is only triggering the laser once and the data collection and then going to the idle or false state.  So this isn't operating in continuous data collection.  So since this is for a single measurement does the major timing difference between the host and target make a difference then?

Ryan

[Chris.N]

rschmeling,

Thanks for the new VI.  The project would be better so I could see things such as FIFO size, I/O, and not have broken wires everywhere.  Also, the number of elements you are reading is Record Size/2, which is only 8,000 points not 16,000 according to your controls default value.  For troubleshooting purposes, it might be easier to use constants. 

You say this "The target VI is only triggering the laser once and the data collection and then going to the idle or false state.  So this isn't operating in continuous data collection."  I disagree with this because the mechanical action of the OK button on the FPGA VI is not set to latched.  Because the FPGA VI is so much faster than the Host VI, this code will have executed many times before OK button finally gets written false by the host side.  If you want the target VI to only run once, you should set the mechanical action to latch and then create a while loop that polls that boolean value before executing the rest of the code in your while loop when it sees a true.  You could also implement a counter in FPGA so you can actually see how many times your case structure is actually executing the way you have it now.

Also, you are using target to host FIFO, not host to target like you stated.  I know it is target to host because you are writing on the FPGA (target), and reading on your host VI.  There are two main things which are important when transferring data this way.  The first is monitoring the timeout on the FPGA and latching that value should you ever timeout (Once you timeout, you are losing data).  This latched timeout boolean should be monitored from your host and act accordingly depending on your application.  

The other danger of DMA FIFOs is getting stale data.  The way you are using it, there is potential for stale data (and overflow but as long as we implement correct triggering and perform flushing I think we can get by without monitoring the overflow if the FIFO is large enough).  Therefore, you should perform a flush like I had stated in the previous post.

Please change the mechanical action to latched and create an additional while loop that polls that value before acquiring your FPGA samples.  Then, before writing your OK button back to true, perform two FIFO reads.  The first read should be for 0 elements and the second read should have Elements remaining from the first read wired into it.  It is important that your “Collection iteration count” is smaller than your DMA FIFO to ensure that there is not overflow on the FPGA, otherwise a third DMA Read would be needed that is the size of the FPGA FIFO.  By doing this, it will ensure that your data is actually correct. 

I really suspect this to be the case because you are assigning dt values to the array by saying the first value is 0, second value gets dt, third gets 2*dt and so on.  If the first value of your array is not newly sampled data, then we would see unexpected results like you are seeing.

Regards,