LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Control loops at high sample rates

Data remaining is the same as scan backlog, so you're doing the right thing. AI SingleScan's opcodes "read newest" and "read oldest" should be used in the following manner:

During the first several iterations as the CPU cache adjusts itself to new instructions, you need to ignore the "scans remaining" parameter because the loop will not necessarily be able to keep up with the requested scan rate. While this is happening, use "read newest", which returns the newest scan from the onboard FIFO and flushes the remaining stale data from the FIFO.

After enough*** iterations have passed, switch the opcode to "read oldest", which will read the oldest data from the onboard FIFO. If the loop is keeping real-time
(i.e. keeping up with the scan rate), the oldest value will be the only value available. The reason you need to switch to "read oldest" is because this opcode allows the FIFO to fill up if your loop isn't keeping real-time. And the reason you want to allow your onboard FIFO to fill up is because that will allow you to monitor "scans remaining" to determine if you're keeping real-time.

By only calling "read newest", you'll never know if you're keeping real-time because that opcode flushes all data except for the newest point, which means "scans remaining" will always be zero.

***Note: How many iterations is enough? Depends on the application. For slow rates, you can read oldest data from iteration 0 onward. Usually, the faster your scan rate, the more warmup iterations you'll need. Try something greater than 10, which is the default used in the RT examples.
0 Kudos
Message 11 of 15
(1,308 Views)
I have tried what you suggested using labview RT, and have increased the "cache" to 10,000 samples and it still does not keep real-time even at a sampling rate of 4000Hz.

However, I tried running the control loop in Windows on the PXI, and according to the "data remaining" and the real-time indicator, it stayed real-time up to about 8000Hz. I am therefore slightly confused as to why it seems to work in windows and yet not labview RT. Any suggestions? Sorry to keep bugging you with questions.
0 Kudos
Message 12 of 15
(1,308 Views)
Matt,

I have another idea, but it's a longshot. When we first started selling the 8176 RT controller, it shipped with USB enabled in the BIOS. When USB is enabled, it generates an interrupt every 1ms, interrupting even a time-critical thread.

Reboot your controller and hit the DEL (or appropriate 'F') key to enter the BIOS. Disable USB, save changes, then reboot. Here's a related KB.
Message 13 of 15
(1,308 Views)
The PXI controller did have the USB enabled. After disabling it, the simple control loop ran at rates up to 40kHz in real-time! So at the moment at least, everything seems to be working.

Thanks very much for your help on all this, it has been very much appreciated.
0 Kudos
Message 14 of 15
(1,090 Views)
May I suggest giving him some stars?

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 15 of 15
(1,090 Views)