Control loops at high sample rates

[mattwilko]

I am trying to implement an active noise control system using Labview RT. However, I can't seem to get the control loop to run at sample rates of higher than about 3000Hz and still keep it real-time. I would ideally like to run it at 10kHz, however, at this sample rate, an overwrite error is returned.

Has anyone out there used Labview RT for ANC or have any clues on how to build a control loop which will run in real-time at high sample rates?

[Bob_Preis]

Let me know if One Channel PID Control.vi under \examples\Real-Time\RT Control.llb helps. It illustrates a few recommended techniques for RT programming in LabVIEW.

[mattwilko]

I have tried using this example, however, I am using separate input and output cards, so had to change most of the configuration settings. I couldn't get it to work for control loops with a loop rate greater than about 4kHz.

[Bob_Preis]

What hardware (controller, DAQ boards, other I/O) are you using? Are you performing single-point control, or are you reading from a buffer?

Is your VI set up to run at time-critical priority?

If you attach your VI, I might be able to give some pointers.

[Christian_L]

Matt,

Can you be more specific about what I/O hardware, number of channels, and SW/driver versions you are using? What controller/processor are you using? What functions in the driver are you using for your I/O in your control loop?

Your loop rate is mainly determined by the speed of the I/O which will be influenced by the factors I'm inquiring about.

Christian L
NI Consulting Services

[mattwilko]

My DAQ system consists of a PXI-8176 controller (PIII 1.26Ghz), Analog input card PXI-6052E, Analog output card PXI-6733. I am only using one channel I/O at the moment, but hope to use 7 channels for the control system. I'm using Labview RT version 7.0 with all the relevant drivers.

The control loop uses single scan and single update vi's.

[Bob_Preis]

With simple PID on one channel, using similar DAQ hardware (6070E + 6713) on a PXI-8176, you can get 10kHz easily. With no controls/indicators (i.e. no front panel comm), I've seen one channel PID reach 40kHz on that controller. In fact, there are a couple other things you can do to push the rate even higher, but at 40kHz and above, the controller won't be able to run anything else besides the control loop.

Exactly how much processing is in the loop? Are you running any subVIs at a lower priority in parallel to your control loop? If so, what do those loops do?

[mattwilko]

Controller - PXI-8176, AO - PXI-6733, AI - PXI-6052E.

I am hoping to perform single point control with 7 input channels and 7 output channels. At the moment the control loop VI attached simply reads a voltage, then divides it by 100 and writes it. The processing which will occur in the control loop in the ANC system will consist of a maximum of approximately 700 multiplications per sample.

[Bob_Preis]

Matt:

I ran your VI and found a couple things for you to try.

1) Set the VI to time-critical priority in the VI Properties page.
2) Remove the graph indicator from the loop.

#1 will ensure your VI is the most important task on the RT controller, preventing other OS threads from preempting your VI. #2 will reduce (but not eliminate) the amount of thread swaps required to run the UI thread so controls/indicators can be serviced. Ideally, you should have no controls/indicators in the time-critical loop because controls/indicators are serviced in a non-time-critical thread (hence the thread swap).

The RTFIFOs on the RT palette were specifically designed to solve this problem. The RT Communication Wizard in the Tools m
enu was also specifically designed to solve this problem.

As a final suggestion, take a look at the numeric value of the scan backlog. If you're not keeping real-time, and the scan backlog contains a value of 1, you probably just need to increase the number of initial "caching" iterations from 10 to 20 for instance. Hope this information helps.

[mattwilko]

I have tried both of your suggestions and they seem to have improved things, however, it still can't keep real-time above 2kHz, and overwrite problems still exist, but they take longer to occur.

I'm not quite sure I understand what you are suggesting in your final suggestion. I hooked up an indicator to the "data remaining" output and for all of the higher sample rates the value was always 1. Is there a way of getting rid of this, or is it a characteristic of the system. I have had problems with a one-sample delay when dealing with buffered systems in the past.