Hardware-Timed Single Point Acquisition Expected Rates

[MBoyd]

Hi All, 

I have PXIe-4300 SC Express cards and need to perform hardware-timed single point (HWTSP) aqcusition for a continuous closed loop control system. I come from the higher acqusition rate with buffers realm, so this area is somewhat new for me. I am wondering what type of rates I could expect, using the cards I have, from performing HWTSP acquisition. I tested the system with the example HWTSP from LabVIEW 2012 help and was only able to achieve 1000Hz for a finite time (< 10 mins) for a single channel. I was hoping to be able to perform this over multiple channels but can't even acquire for a half-second when 4+ channels are added. I am not sure if this is expected behavoir or if I am missing something because if these rates are expected rates, I may have to reconsider the application. I also wasn't sure if the card type I am using could be causing issues. Any help would be greatly appreciated. Thank you.

[0utlaw]

Hello MBoyd,

Without knowing more about your setup (What OS? What controller? What failures are you seeing when using the DAQmx shipping examples? Which specific example are you referencing?) it's difficult to offer recommendations, but this White Paper will likely be of interest to you:

Benchmarking Single-Point Performance on National Instruments Real-Time Hardware

http://www.ni.com/white-paper/5423/en/

Midway through the page there are also links to the benchmarking code used, which may be helpful.  After a quick glance-through it looks like one point to note is that the default example does not reconfigure the default wait on sample clock wait mode, while the benchmarking code provided via the link above does.  Changing your wait medhod it to polling will likely speed things up.

It's not clear if you're using an RT system or not, but if you're currently using a Windows controller then approximately 1 kHz is what I'd consider a "normal" operating upper limit for most loops that rely on some form of scheduling or triggering that interacts with the OS.  Faster is certainly achievable, but that's something to keep in mind.

This thread has some additional information on using the DaqMX Wait For Next Sample Clock.vi on Windows that you might find useful:

Thread: DaqMX Wait For Next Sample Clock.vi Causing Slow Down

http://forums.ni.com/t5/Counter-Timer/DaqMX-Wait-For-Next-Sample-Clock-vi-Causing-Slow-Down/td-p/123...

Best Regards,

[MBoyd]

I apologize for not being clearer the first time through. Currently my PXIe chassis is connected to an external Real-Time controller via fiber MXI cards (PCIe/PXIe-8375). The controller is a DELL T7600 that NI personally sanctioned as supportable NI Controllers. My current testbed code contains no other operations other than the single-point read from the DAQ card. Other than that single read, the while loop is currently empty. 

What I am unsure of is that the white paper linked previously states that the system can run in Polling Mode vs Interrupt mode which will result in faster operation, but I am unsure how to actually make the change from itnerrupt mode to polling mode. 

[MBoyd]

I'd also like to add the error that I am seeing when the system fails now that I am down in the lab. The error is -209802, which states that the DAQmx Wait for Next Sample Clock.vi detected one or more missed clocks since last call. The error provides solutions which essentially leads to slowing down my acquisition rate. This was tested with 4 channels on my PXIe-4300 at a rate of 1khz. I am not sure if this is too much to ask of the board or not. I also found that a property node changes the vi's operation to polling mode which didn't seem to give me the required overhead to properly operate the circuit. Any help is appreciated. Thanks.

[0utlaw]

Hello MBoyd,

To check- have you attempted deploying the benchmarking code linked via the aforementioned whitepaper?  The link is at the end of the PXIe-8108 benchmark section, just in case here it is linked again:

Example Programs: Single-Point Benchmark Code - DAQmx

http://www.ni.com/example/30204/en/

As for other references, these documents may also be helpful:

NI-DAQmx Hardware-Timed Single Point Lateness Checking (not specifically what you're concerned with at the moment, but demonstrates quite a few options for HWTSP I/O)

http://www.ni.com/white-paper/3215/en

KnowledgeBase 3JD8K21V: Why am I Receiving Errors -209802 or -209803?

http://digital.ni.com/public.nsf/allkb/84CD06A921462FD986256FC4005611C9?OpenDocument

My impression is that this simultaneously-sampled card shouldn't see much of a hit when acquiring from all channels, and that well over 1 kHz should certainly be possible.  It seems more likely that there is some sort of RT priority, transfer latency/read processing, or synchronization problem.  Out of curiosity, how fast can you run a loop containing a simple software-timed read with a 1us wait timer (one of the SW Timed Input examples, but minimize the execution throttling/wait timer)?  Obviously this isn't what your end goal is, but I'd still expect a rate of >1kHz.

A few other clarifying questions:

-What is your actual target loop rate? 

-How many channels do you intend to acquire from, if possible?

-What do you mean when you say that polling mode didn't give you the required overhead to properly operate the circuit?  As a note, polling in an otherwise uncontrolled loop will likely utilize whatever CPU cycles are available, however this is intended and accurately represents that the polling function is querying for an update as fast as possible until the event of interest has occurred. You should still be able to perform your processing and AO before beginning to poll, with the caveat that your maximum loop time still needs to be less than the single-point sample period.

-Have you attempted using a timed loop synchronized to the sample clock rather than the wait for sample clock function?  This may be a viable option.

-Are you running this code interactively via the LabVIEW development environment (Click the VI's run button while targeting the RT Controller) or deploying it as a Real-Time executable?  Interactive execution will almost certainly slow things down quite a bit.

-You indicated that a Read is the only function in your primary loop- are you using the Wait until next sample clock function or the Report Missed Samples property?

It would also be helpful if you could post the actual code you're using, if possible- there are often small things that are much, much easier to pick up on when you can see the code.

I'd also recommend getting in touch with NI tech support directly if you can- this type of question is the sort of thing they handle regularly and they likely have additional resources to answer questions such as expected rates for your hardware/software configuration. Be sure to mention that you are looking for advice on acquisition times for the PXIe-4300 and reference this thread if/when you call or email support.

Best Regards,

[MBoyd]

I actually found out what the issue is. Stupidly enough I didn't think about it until I took some time away from the code to do something else. The example code displays the data to the screen via a waveform chart. Being that I am running on a real-time machine, this was taking a lot of execution time cuasing the system to overrun on it's time. Once the code was removed to a consumer loop, the system easily met my time requirements.

Thanks for the help. I greatly appreciate it.

[0utlaw]

Aha!

Yes, that would definitely do it!

Thanks for posting your findings- I'm sure it'll help others in the future.

Regards,