Getting a PID loop with AI/AO to run fast

[beanbag]

Hello,

I am running Labview 8 with a PXI 8195 RT controller and PXI 6229 cards.

For now, I am just trying to get a simple loop that reads a value (on a ADC) and spits out the same value (on DAC) to run really fast.  I looked at some examples, but a lot of them were for Traditional NIDAQ, which won't work for me.  (I have to use DAQMX).  Below about 23 kHz, the execution traces look normal, with a lot of "ETS Null Thread", which I assume to be idle time, and DAQmx read and writes of about 2.5 us.  However, once I go above about 26 kHz, everything seems to go to hell, with DAQmx write taking significantly longer, e.g. 16-30 us.  Of course, the loop doesn't keep real time any more.  Even if I empty out the loop, it still only runs about 30-something kHz.  I know I must be doing something wrong because the 8195 is supposed to do PID (which I assume includes a read and write) at 47kHz.

Some other things I tried were: turn off debugging, set to time critical.  I didn't disable usb because I can only connect via a usb keyboard, and if I disable that, then... well...

So below I included my vi.  I tried a few different variations, but never broke this 25-ish kHz barrier.  If anybody knows what I am doing wrong, please let me know.  Thanks

[Stuart_G]

I am not sure what the expected rate is supposed to be 47k seems about right for single channel and certainly I would expect greater than 25khz.  Here are some additional tweaks to try to see if it helps increase the rates:

#1.  I know you said you couldn't disable USB, but in my testing this is ALWAYS the thing that causes the largest bottleneck. If it is an RT system why do you need a keyboard?  Just boot into PLap and run. 

#2.  In MAX you can set your Advanced ethernet modes for the controller.  If you set it to polling it will increase your speed.

#3.  Try using a normal while loop and see if that helps.  Try this last though as I think #1 and #2 will give you the best chance of improving your rates.

StuartG

[Kevin_Price]

This may not solve your main problem, but you've GOT to disable USB if you want deterministic timing.  Back in RT 6.1 we performed some characterizations with USB enabled and disabled on a PXI controller.  There were very dramatic spikes in the loop time data with USB enabled which completely disappeared with it disabled.  As I recall the durations were in the realm of 10's of msec, far too much even for our relatively modest target of a 1 - 2 kHz loop rate.

Sorry, can't look at the vi b/c no LabVIEW on my network PC.  I haven't done RT under DAQmx though, so am not sure how much help I'd be anyway.

Why do you need the keyboard again?  When you run the PXI controller as an RT target, you're not interacting via keyboard, right?  Don't you have a host PC hooked to the PXI system via the LAN cable?

-Kevin P.

[beanbag]

Thanks for the replies.  No, I don't need the keyboard.  But the only way to connect a keyboard is thru the USB.  Once I disable that, I won't be able to access the BIOS anymore.

[beanbag]

Update:

I read from the manual that even if you turn off USB, the USB keyboard can still work, so I did it.
That only helped a little bit, but what helped a lot was changing the ethernet to polling mode.
Right now, I can get 38kHz, which is pretty reasonable, but still not 47 kHz as advertized.

The funny thing is that I can only get the 38 kHz by using software timing, i.e. only specifying the timed loop period.  If I try to use hardware timing as shown in my example, it goes slower, like 26 kHz.

[Kevin_Price]

What was the old (default?) setting for ethernet?  I'm curious about the code now too, but don't have immediate access to LV 8 so will try to check later.  Could you post a screenshot?

-Kevin P.

[Stuart_G]

This still seems slow.

I am not in front of my RT system right now so I will try to guide you through this the best I can remember.  I am not sure about this controller but I think it might be the one with two USB settings in the bios.  The one you should disable is something like Advanced>>Legacy USB support.  There may be just that setting in your bios I can't remember.

Did you try with just the while loop?

If you are using SW timing how are you determining your rates?  Are you using the timed loop?  HWTSP will give you the most accurate results.  Use that and try without the while loop.  I also don't remember your code now.  It looked pretty optimized, but make sure you have removed all indicators and controls from inside the loop.  If this still doesn't get you there I can show you some other optimizations which may get you there.  Keep in mind the 47kHz (if I remember correctly) is near maximum speed.  That means a pretty much headless system with no user interaction or communication.  In other words you won't be able to do much at that speed except let the system run.

Kevin...the default ethernet setting is interrup.

[Richard P.]

I realize this is an old post by now, but I wanted to add that there is a property node for a DAQmx task which allows you to set it to Polling:

"Wait For Next Sample Clock has two modes of operation: Polling and Wait For Interrupt. Wait For Interrupt mode, which is the default, allows lower priority processes to execute while the time-critical loop waits for the next sample clock. Polling mode allows for higher sampling rates, but it prevents lower priority processes in the system from executing while the time-critical loop waits for the next sample clock."

Polling won't have the latency of "Wait for Interrupt" so instead of waking up the VI when the sample is ready, the DAQmx VI hogs CPU while polling for a new data point. This is key to achieving the published PID rates.

Check out this benchmarking DevZone article: http://zone.ni.com/devzone/cda/tut/p/id/5423

It mentions polling vs. interrupt mode.