DaqMX Wait For Next Sample Clock.vi Causing Slow Down

[zaphara]

hi,

I have a question about the proper use of the DaqMX Wait For Next Sample Clock.

I am reading analog voltage channels on a pcie-6259 NI card.

I would like to read single data points as fast as possible to perform feedback between each of those points.

I would like to have an error produced if I miss a data point.

From reading the forums, I have gathered that the best way to do this is using the Hardware Timed Single Point.

Attached is a simplified program I am using to test this.

If I remove the DaqMX Wait For Next Sample Clock.vi, my program seems to work.

I have added a counter measurement to verify the total time is as expected.

For example, the program seems to run at the proper rate for 120kHz.

However, without that vi, it seems the program will not generate a warning if I missed a sample.

So I thought the Wait Next Sample Clock vi could be used to determine if a single data point was missed using the 'is late' output.

However, when I add it in as shown in the attached, the program appears to slow down significantly.

At high rates like 120000 I get the error: -209802

14kHz is the approximate maximum rate before I start getting errors.

My question is: Is this the right way to check for a missed sample? I don't understand why the Wait Next Sample Clock.vi is causing such a slow down. Without that vi, the program does everything I want except I don't have strict error checking.

My confusion may be based on a lack of understanding of real time systems. I don't think I am doing 'real time' as I run this on a regular pc, so maybe I am using some functions that I should not be.

thank you,

Mike

[Mcdan · Accepted solution]

Mike,

You should be able to get read to return lateness errors and warnings by setting the DAQmx Real-Time->ReportMissedSamp property.  I suspect that if you enable this, you'll see errors or warnings (depending on the DAQmx Real-Time->ConvertLateErrorsToWarnings) in the case that you use read only.  I'm a bit surprised that you measured your application running at 120 kHz without Wait for Next Sample Clock (WFNSC), though I'm not surprised that it would be measurably faster.  I believe that if you call read only, you'll read the latest available sample regardless of whether you'd have skipped samples or not.  When you call WFNSC, DAQmx will always wait for the next sample clock, whether you are late or not.  In this case, you'll wait for an additional sample clock that the read-only case would not.  Again, I would expect that in either case, your loop would not run at 120 kHz.

The Real-time functionality in DAQmx (Hardware Timed Single Point - HWTSP) is a set of functionality which is optimized for single point operation, as well as a mechanism to provide feedback as to whether an application is keeping up with the acquisition.  There is nothing inherently wrong with using this functionality on a non real time OS.  However, a non real-time OS's scheduler is not going to be deterministic.  This means that your 'real-time' application can be interrupted for non-bounded periods of time while the OS goes off to service other applications or whatever else it needs to do.  DAQmx will still tell you whether or not your application is keeping up, but can do nothing to guarantee that this will happen.  As such, your application *must* bet tolerant of this type of interruption.

There are a few things to consider.  If it is critical that you perform action at a given rate, then you should consider using a Real Time operating system, or even going with an FPGA based approach.  If this is not critical to your system, then you could consider using either HWTSP where you don't report missed samples (DAQmx will simply give you the newest sample), or you could avoid HW timing all together and simply use On-Demand AI to acquire one sample at a time.  What's appropriate depends on the requirements of your application.

Hope that helps,

Dan

[zaphara]

hi Dan,

Thanks for the help.

I tried setting the ReportMissedSamp option true, removed the WNSC vi, and then checked the error status in my loop.

This appears to work exactly as I want - if I set the rate high (say 120kHz) then at some point in the loop it will generate an error and it appears I have detected the lost sample.

If I leave ReportMissedSamp false, then the loop will execute and appears to run fine  but I presume that I am missing a sample here and there due to interupts, etc as you mentioned.

So I am glad to have a solution that works, but still worried I might not understand one aspect of this - since it seems you and others would expect WNSC to be a crucial element of this setup.

When I run the sample program I attached earlier with WNSC.vi left out, the loop appears to run at the rate I request - based on measurements of a system counter before and after. For example, if I set the rate at 10kHz, the loop seems to run at 10kHz. If I set the rate to 20kHz, it runs at 20kHz.

This would lead me to conclude that my software is generally keeping up with the hardware. When I call DaqMX Read, if I am early, it waits until the new sample is ready and then returns. Which would be fine in this particular case, but I would think that makes WNSC redundant. So if you or someone can give me an idea of why my loop runs at the right speed even without WNSC.vi, that would probably clarify many things for me. It sounds like you are also surprised that is the case.

but this does seem to work now exactly as I need it. Thanks for your help.

cheers,

Mike

[zaphara]

hi Dan,

I realized what is probably the answer to my second question.

I had set it up with the poll option on - that was something I started using a long time ago - I will go back and investigate exactly how those options work, but probably that explains why DaqMX Read waits for me.

cheers,

Mike

[Mcdan]

Mike,

See the linked document on NI-DAQmx Hardware-Timed Single Point Lateness Checking.  This should do a better job of describing the various types of lateness checking and synchronization options available than I'll be able to here.  The main thing I would take away from this is that using WFNSC allows you to ensure that all processing and I/O operations complete before the arrival of a new sample clock.  If you are doing a control loop, it would be good because it would ensure that your output was ready before the clock responsible for outputting it occurs (or error if too late - basically enforcing a check that all operations occur within each sample period).  This may or may not make WFNSC a redundant feature.  If redundant, you should remove it as it will only serve to slow you down.

DAQmx Read will always block until data is available... ie, it 'will wait for you'.  The wait mode specifies how DAQmx will wait.  Selecting Poll means that in a tight loop, DAQmx will query the hardware to determine if a sample is available.  This is generally the fastest mode of operation, but this tight polling loop uses a lot of CPU.  HW can also send DAQmx an interrupt when data is available.  In this case DAQmx no longer needs to poll HW in a loop, but the interrupt response time will not be as fast as the polling case.  We leave it to you to decide which of these alternatives is better for your given application.

I was generally surprised to hear that you could keep up at a rate of 120 kHz on a windows machine.  When attempting longer-term testing on Windows (using WFNSC) , I've never been able to sustain a rate anywhere close to 120 kHz (In general, the longer that I try to sustain a rate, the slower I must go).  I figured that without lateness error reporting you were probably dropping some samples, although maybe not enough to significantly affect the timing of your test, which would have the appearance of generally keeping up.

It sounds as though you're getting a good handle on HWTSP and WFNSC, and are on the right track.  Let me know if you have any further questions.

Dan