Sampling rate problem with USB-6211 DAQ and PID VI

[jharwert]

Hello all,

I'm using a USB-6211 DAQ to acquire voltage data points from a force sensor. I am then comparing these data points against a desired setpoint function and using a PID VI to output a duty cycle based on the error between the setpoint and the actual data. If the force sensor voltage is lower than the setpoint voltage, then the PID increases the duty cycle to increase the force sensor voltage. If the force sensor voltage is higher than the setpoint voltage, then the PID decreases the duty cycle to decrease the force sensor voltage.

The program is working as intended, however, I cannot get it to run at a faster sampling rate than 5 Hz with the USB-6211 DAQ connected. Attached is the program I'm using and a pdf view of it. Does anyone have any advice on how to improve the sampling rate speed?

Some background on the front panel values:

T - Total time that the program runs

N - Total number of data points sampled throughout the time, T

Frequency - Frequency value of the square wave generated by the duty cycle

fs -  Desired peak force sensor value

fd - Desired lowest force sensor value

[Kevin_Price]

There are a number of candidates that can be limiting your loop rate.  I can only identify them, not solve your whole app.

1. The "Wait (msec)" function.  It looks like you're trying to set the loop rate equal to your sample rate.  But you've also over-constrained your loop timing with your task.  Either remove the "Wait" function, or don't configure a sample clock for your AI task and simply do a software-timed on-demand Read inside the loop.

2. The dreaded DAQ Assistant inside the loop.  Sigh.  Find another way with native DAQmx functions like you did for AI.

3. A Matlab Script node inside the loop.  Dunno *how much* overhead is involved to invoke the Matlab script interpreter every iteration of the loop, but I guarantee it isn't worth it for the trivial calculation you do.  Go native LabVIEW.

4.  The Express VI to recalculate your 0 to 5.0 volt square wave (that you then generate with AO).  You should use one of your device's counters to generate a digital pulse train.  

5. Updating GUI charts inside your control loop.

So in short, literally almost everything inside the loop deserves some scrutiny and modification.  Hopefully others will give more detailed suggestions.

-Kevin P

[cbutcher]

I'll take a shot at some more suggestions. When I use numbers, I'm referring to Kevin's points above:

1. As Kevin said, just remove the Wait. Your DAQmx Timing node (for the Analog Input task) will moderate your loop rate without any problems.

2 & 4. If you right click on an Express node and choose "Open Front Panel", then accept the dialog (click Convert), you can see the code that is run by these nodes. I almost always find them incredibly confusing. (Undo to get the Express node back). Given that your device allows Counter pulse generation, you should instead use the DAQmx Counter out options. A more detailed description is available with examples here: Change Duty Cycle on a Continuous Pulse Train of NI-DAQmx Task

3. It's a lot of overhead (especially when first starting - significantly more acceptable once running, but still not negligible). You only need a few basic Numeric operations. You can probably also move some parts of the calculation outside of the loop (moving parts of the calculation out of the loop is in principle a good thing, improving speed, but in practice probably won't make much difference)

5. You could take a look at the Producer/Consumer for an alternative way to update a graph with results without requiring your PID loop to handle thread switching to the UI thread. You can also make your code clearer by changing the Merge Signals into a Bundle node, and using a plain Waveform Chart (no waveform required).

• Your Flat Sequence Structure around Start does nothing
• Your wires are fairly twisted. Straightening them out will probably make the diagram easier to read (for others, and for yourself in the future)
• You can use a Caption (for the graph) to give a long name on the front panel, whilst retaining a shorter label for the block diagram.