Using NI-4351 Card and AI Start there appears to be time delay

[IPSMAG]

I am trying to get accurate time stamps for the sampled voltage points using the NI-4351 Card. I am running the AI-Start and AI-Read VIs in a timed loop where the loop is acquiring one buffer of data each iteration. I have tried lots of things and have been running some tests using timed loops and displaying loop period and the difference between expected start and actual start times of successive loop iterations. After running some tests, it appears that the time for the loop to run for N samples with time sample period, dt, is N*dt + 500mSecs (approx). If the timed loop is forced to start ealier than this formula eg, offset say 100mS, the "Actual Sample Frequency" given out of the AI-Start VI is zero. This suggests that the perhaps the AI-Start VI is not acquiring immediately and as I am obtaining the time stamp from the "Get Date/Time VI" at the start of the same loop, I am concerned that my time stamps could have a 0.5 second error. Does the AI-Start VI commence sampling immediately or is there some time delay (I have left all the triggering settings on this VI as the defaults)? How can I be certain that the time stamps I am assigning to the sample points are accurate?

[Corby_B]

Hello IPSMAG,

Thanks for your post!

I see that you are using the 4351 card and have some concerns about the start giving you some delay. I would first like to as is there a reason that you are calling the "start VI" every loop iteration? If you are going to acquire continuously then I would recommend calling this VI outside your timed loop and that way the delay will not be a concern at all since this will now be a part of the setup time instead of your loop iteration time. The Start VI simply starts the ADC on the board and allows you to pull samples when the read VI is called so yes the AI start commences the sampling. The time stamp is being applied software timed so there is always a potential of the time stamp being off from the actual time of data taken. Take a look at the example program  Continuous Scanning.vi. To get to this example open LabVIEW and go to Help >> Find Examples. In the example finder go to the search tab and type in "435x". Take a look at the "Continuous Scanning.vi". This shows an acquisitions using the fast mode or 60 S/s.

As for using "Timed Loops". These are typically used in the LabVIEW Real Time environment and targeted for FPGA situations or controllers. So I am not sure that using this loop is specifically benefiting you and your program however questions regarding this would be better directed toward the LabVIEW forums. 

Let us know if this addresses your concerns/questions about the 4351. Have a great weekend!

Cheers!

Corby_B

http://www.ni.com/support 

[IPSMAG]

Hi Corby,

Thanks for the reply.

First, I will explain why the AI Start has been used in a loop (I have looked at the examples for the NI-4351 card and many others in trying to find a solution).

The application is designed to run in the field in remote locations for some time (years if all goes well) and timing is important so the data can be analysed with respect to data recorded by different systems. Sometimes power to the equipment goes out for extended periods and the application starts up when power is restored. As the documentation suggested that the NI-4351 card on-board oscillator takes some time to stabilise, and as it is the sample frequency that is used to calculate the time stamps for the data points (T + N/f where T is the start of sampling AI-Start, N is the number of samples and f is the sample frequency from the AI-Start VI), I could not assume that the "actual sample frequency" on startup was the same as some months later and that time stamps calculated using this method would be in error after a significant period. Hence the AI-Start and AI-Read are in a loop where this possible source of error is reduced, ie if the sample frequency is f + df where df is the variation over time from the f at startup and there are N samples and N is extremely large, the N*df also becomes large. I have looked at some examples and they all seem to suggest getting the date/time stamp from the system when starting the acquisition as the method for calculating the time stamps (please let me know if there is a better way).

Assuming the method above for time stamps, then it is important that the time request from the system and the start of the actual A/D conversion be virtually simultaneous and this is where I am concerned. When writing the time stamps to files, the end of one file and the start of the next were always virtually one sample point + 0.5 seconds apart and I was trying to determine the source of the 0.5 seconds delay and this is why I employed the timed loop. The timed loop appears to behave as documented, ie, it would indicate if the loop did not finish as expected etc. I wired the loop period to N * f  where f is "Actual sample period" from the AI-Start VI and the loop only finished correctly when a delay of approx 500 mSecs was added. If this delay is between the start of calling the AI-Start VI and the actual start of A/D conversion then this would incorporate a 500 mS error in the data point time stamps as the "Get Date/Time VI" is run at the same time as the AI-Start VI. I realise this is timing in software but I thought I should be able to obtain better accuracy than a 0.5 second error. I hope you can help.

regards

[tnek]

Hi IPSMAG,

 The 500ms delay that you are seeing is just the time that the NI-4351 takes to be configured. This can be checked by benchmarking the AI Start or 435x Start functions. As Corby mentioned, this delay would not be there if the start function was not called each loop. However, since this delay is fairly constant, you can compensate for that in your timestamp. If you wanted to be even more precise, you can measure how long the start function takes to execute and factor that in. Hopefully gives you a little more insight into what is going on.

Regards,

Kent

Applications Engineer

[IPSMAG]

Hi Kent,

Thanks for the reply. My understanding is that the AI-Start initiates the A/D sampling and as I am getting the date/time in software with the "Get Date/Time VI" simultaneously, this 500mS delay would occur regardless of whether this is done inside or outside a loop - if you know of a way to avoid this situation using software timing, please let me know. If not I will try and measure the delay incurred by the AI-Start configuring and add it to the timestamps. Could you please confirm that the approximate 500 mS delay is occuring before the AI-Start VI actually initiates the sampling so I can be sure to ADD the delay to my timestamps and not subtract it.

regards

[tnek]

Hi IPSMAG,

Since the NI-4351 does not sample very fast, you may want to just take your timestamp right after the AI Start function has been called. If you check the number of samples in the buffer right after the start function, you will notice that there are still 0 samples in there since the sampling rate is so slow. If you could think of another way to have the AI Start outside of the loop that may help but if you wanted to keep it inside I would recommend only taking the timestamp right after the AI Start and not at the same time as the AI Start. You can do some benchmarking on it yourself to see what the easiest method is for you to use. The NI-435x driver gives you a little more control over the acquisition and the timing so you may want to also try that.

Regards,

Kent

Applications Engineer