real time PID control latency

[denigmaz]

Hi,

I'm fairly new to LabVIEW and am currently trying to develop a PID controller using LabVIEW 8.2 and the PIDToolset with a LabJack UE9, which aims to dampen oscillations in a moving structure where the LabJack is being accessed via Ethernet. For our application it's necessary to have a very fast feedback control (since it's a dynamic system) using a hardware timer, with the acquisition and control tied together as much as possible, and a high sampling rate at fixed intervals.

But I'm running into a fair bit of trouble with data acquisition timing and latency which is resulting in the data acquired being inconsistent and full of artefacts, and I'm at a completely loss as to how to optimize the code further!

I'm using a scan rate of 200Hz (being passed into the LabJack VI), across 5 analog input channels. It's currently set to read in 8 scans per loop iteration (any higher and the waveform graphs start to have artefacts in them, but reducing this adds to the amount of lag in the program as it struggles to keep up with the acquisition rate). The acquired data from the LabJack is then passed into a For Loop which splits the interlaced data out so it can be processed.

We'd like the actual sampling rate to be as high as possible - 100Hz and up, but currently the data is showing an average 0.07s time interval, ~14Hz, which is way too low.  Also the program is eating up a fair chunk of CPU processing power, and not to mention there is a good 20 second delay between the waveform chart updates and the actual physical effect of the control taking place. Moreover, raising the scan rate increases the amount of latency in the program as the buffers are being filled. 

I've tried restructuring the program so that there are 2 loops:

- Loop1: For data acquisition and feedback control

- Loop2: For visualizing the data, user input and storing the data. This loop has a 30ms delay, as Loop1 requires higher priority to operate. 

*Note: I previously had a write to file function in Loop2, but found that it was reducing the speed of the program, so I took that out and replaced it with a build array, to which the next set of data is appended for 150 seconds, before the program finishes and passes out the data to be written to file. (though I'm not too sure how much of a gain in response this will give in the end, seems to help a bit.).

Also, a secondary question, since the data is being collected/array being built by Loop 2, how accurate is timestamp given by the write to file VI for each data point? I take it the time intervals are given every time Loop 2 is run, and is not the actual hardware acquisition rate (which I'm guessing is 200Hz/5 channels = 40Hz)? Or are these two tied together?

And how does this affect the feedback response? 

I've attached a cut down version of the code as it's too big to screendump (though there are a lot of broken wires, as this is only part of the package & can't be run).

Any help and feedback on how I could streamline the code further or how to increase the data acquisition rate & response time would be greatly appreciated!

[jkurtw]

 Hi denigmaz,

Is your heart set on using the LabJack device? I looked at the specs for that device and it looks like the analog output channels are software (command/response) timed, which is high in latency by definition. Also, Ethernet is high in latency.

Generally when you are performing PID, you need to update your output for every input sample:

1) Read Process Variable

2) Perform PID calc

3) Assert Output 

4) Repeat

It looks like you are reading several points each loop iterating in order to achieve a higher acquisition rate. My concern is that this higher acquisition rate is not translating to a higher control loop rate because you are skipping over points by not asserting the output for each sample acquired. 

To lower CPU usage you should preallocate your array that you are building so that your PC does not have to allocate memory on the fly.

Here is a simple example: 

Kurt 

[LabJackSupport]

We get similar latency from our 10Base-T Ethernet as full-speed USB (roughly 1 ms round-trip, Section 3.1 of the UE9 User's Guide).

This project by denigmaz also has a topic on the LabJack forum:

http://forums.labjack.com/index.php?showtopic=4526 

The UE9 does have the ability to do analog outputs in hardware timed stream mode, but usually you preload a buffer with some output waveform you want to repeat.  For a control loop, you need the 4 steps you describe, and each time you come up with a single analog output update, so it seems more natural to use software timing.

What denigmaz is trying to do seems OK.  He is using stream mode to collect inputs (your step #1).  Streaming at 200 Hz and doing 8 scans per loop, means the control loop is at 25 Hz.  Might as well just scan at 25 Hz, but whatever.  My other though is that if you want a 40 ms control loop, I think you could hit that with software timing.

In our topic #4526 I have attached a special stream example that shows how to set up stream for low latency.  After it reads each scan or block of scans, there is a frame where I can inject delay.  With the 200/8 = 25 Hz control loop, I found I could add up to 39 ms and it still keeps up.  Only with a delay of 40 or more ms does the buffer start to grow.  With a 200/1 = 200 Hz control loop, I found I could add up to 4 ms of delay and it still keeps up.  Since it takes about 1.2 ms to update an analog output, this still leaves extra time for processing and calculations.