Formula node speed of execution for PID control

[sirius18]

Hello all,

I'm working on a project where we need to get data from a DAQ board (cDAQ 9178 with input module: 9205 output module: 9264). We read temperatures from a thermister, send it through a software based PID control loop (without the control and simulation toolkit. Built our own PID loop using shift registers) and write the output of the controller to a peltier heating element. We would like for the system to run at a minimum of 10kHz frequency (100kHz preferred), but from the forums, I found that getting LabVIEW to run at anything higher than 1kHz on Windows needs the Real-Time module, which is also not so reliable, since it depends on the way the OS is programmed to prioritize. (-? I'm sorry if I'm wrong, this is what I understood from the old posts here).

The PID is in a formula node, as a C-code along with a coded customized setpoint signal (which is a function of cosines that I couldn't generate using any of the pre-existing signal generation blocks in LabVIEW). My first question is, does using a formula node with a C-code slow down execution? Is it faster to run the system using a PID block from LabVIEW?  Also, I've attached the code and a screenshot of the signal I'm generating as set point. Is there any way I can code this without using a formula node, in case it's the node that's slowing the process down? I wasn't sure how to give "if-elseif-...-else" statements using the block diagrams to generate the signal I need. I am probably wrong, but I thought implementing the entire code using blocks might speed things up since different computations occur parallely, whereas in a formula node, the code is executed sequentially..?

Moreover, we know that the peltier and thermister respond almost instantaneously (hardware spec sheets) but still, we have a very large time constant when the system responds and despite using a control loop, we get a time lag between the temperature of the metal block that the peltier is heating/cooling and the set point that we provide. So, we figured that the software was probably slowing it down. Is there any way we can overcome this?

We used a sequence structure and figured that the DAQmx writing takes about 75ms on an average. Can we speed it up somehow, to reduce the delay time in control loop? 

Thank you!

sirius18

[Thoric]

Running any timing on Windows higher than 1kHz is not simple, due to the limitations of the system clock.

The Real-Time module you refer to is not for Windows, but for executing your code on a Real-Time platform (such as a CompactRIO) which uses an alternative operating system (such as VxWorks). This will give you more determinism (reliability), but not necessarily the ability to run a timed loop at more than 1 kHz.

Of course, your code can run as fast as the processor will execute each iteration, which could be MHz, but if you want this timed then you need to syncronise with a clock, and that requires compatible hardware.

The native LabVIEW PID functions will most likely be faster than your c-code function, simply because the LabVIEW PID functions are optimised and the c-code function is an interpreter.

If you are not sure how to best program your PID control in native LabVIEW, then might I suggest you read the Basics training material to understand the fundamentals of programming in LabVIEW.

I'd be very suprised if the Peltier had an 'instantaneous' response time, it is a heating/cooling device that generates a thermal gradient. It necessarily takes time to generate such a gradient, and depending on the physical size of the device and magnitude of the gradient I would expect this to be in the order of seconds. A 1kHz control loop for controlling the temperature of such a device should be more than sufficient.

[sirius18]

Thank you for the response, Thoric! 

I have a few more questions:

1. If I were to use an external clock, can I input the external signal via the DAQ and use it to time the circuit? Or will I need any other hardware?

2. You mentioned that a 1kHz control loop should be sufficient to control the temperature. However, despite tuning, the best response we were able to get from the PID looks as shown in the attachment. There's a time lag in the rising half, which we need to avoid. Basically, we need the metal block's temperature to track the input waveform. We tried slowing down the input waveform, but that didn't reduce the lag. Do you have any suggestions as to what we could do?

[Thoric]

In response:

1. I don't know, I'm not a hardware expert when it comes to cDAQ, so I can't comment.

2. The time lag is likely a hardware response time, not the software. The Peltier surely can't provide a thermal gradient instantaneously, therefore there will always be a time constant delay. I'd like to be proven wrong, however, so hopefully someone else can comment further?

[nathand]

1. Depends on your DAQ hardware.  Some boards do support using an external clock as a timing source for a timed loop.  That said, if the control loop is properly coded it should be able to tolerate a small amount of jitter.  As far as I know, an external clock isn't a guarantee of consistent timing - Windows can still interrupt it.  At 1khz, I doubt that an external clock will be a noticeable improvement over a timed loop at the same rate.

2. The nature of feedback control is that it's always going to lag the setpoint slightly.  That said, you might be able to improve the tuning.  Try more derivative gain to drive the response faster, assuming that your signal is as clean as it looks (noise will make derivative control ineffective).  That should also help cut down on the overshoot.  What method did you use for tuning?

[AndyClegg]

Regarding sample time for control loops, the general guideline is that you need to sample at least 10x faster than the fastest frequency you want to control. But this also depends upon the performance requirements - i.e. the stability margins of the closed loop, which basically is down to how aggressive or not you want the controller tuned.

In a digital control loop you will always get delays related to the sample time - typically 1-2 samples depending on exact implementation. There can be some scope for improving performance by looking at detail of timing of AO-calc-AI cylces and make delay as short as possible.

What is the time-axis units of your image - is it samples, or seconds ? Assuming it is in samples, the sample rate looks a bit too slow for that signal and that close loop response is quite aggressive, so could be limiting performance.

Feedforward of your trajectory might be a great help here, but depends upon how linear or consistent system response is - which is important for feedforward to work well.

[sirius18]

Thanks nathand!

1. Our DAQ hardware seems to be taking ~70ms to write data. Is there any way we can reduce this? 

2. We used Zeigler Nichols tuning (closed loop technique). But the response is still quite jittery. Our mentor doesn't want a derivative component, so we played around with the P and I values to get the best possible tuning. That, however, didn't help much, since the response still lags. Is there anything else we can do?

We removed the noise by averaging the input to the PID and this makes the output much smoother. We added a simple low pass filter (using C), but that didn't show a marked improvement.

[sirius18]

Thanks Andy Clegg!

The time axis was in seconds, not samples. The frequency we want to control is very less, (our set point is a function of cosines and the time period is about a minute) while our sampling rate is that of the cDAQ 9178- 100kHz, I believe. We figured out that the DAQmx writing is the most time consuming process of our loop. Is there any way we can improve it? 

We do have a feedforward input, but the system seems to have a large time constant (tf ~= 5/(26s+1) -- We found this by taking the step response and used LabVIEW as well as Matlab to obtain the transfer function from the data we recorded.) So, even with the feedforward, the response is sluggish. The peltier heats up really fast, we tested it outside the control loop and it didn't take 26seconds to heat the block up. But somehow I'm not able to explain the large time constant. 

[sirius18]

Also, how do I make the timed loop structure run continuously? As in, I need the loop to restart after every 10ms. After wiring everything together, I could only make the loop execute once. And then, the VI stops running.

[AndyClegg]

Ok. As the time is in seconds, you do not need such a fast sample time. I would say that anything less that 0.1sec / 10Hz would be more than enough for tracking that speed of setpoint trajectory. The benefit of going any faster than that would be negligible - from a dynamics point of view, and sounds like you are maybe getting sidetracked by trying to make the sample rate very high.

Some points to think about:

• the sample rate of your data acquisition loop is not neccessarily the same as the how frequently the PID controller is updated - check you understand this distinction - it is the controller that I am saying should be no faster than 10Hz. Typically sample rate of data acquisition is set to match that of your controller.
• the sluggish behaviour of your closed loop system may be coming from the speed of the system you are controlling - there are limits to how fast you can make a closed loop system before it goes unstable, even without any effect from discrete control. That is the stability limits may not be arising from the sample time.
• if the system heated up in <26seconds, then you would expect that to be reflected in the Transfer Function - did you get this from a system identification tool, or just from measuring the time to steady-state ? You have to be careful with system identifcation that the data you input is suitable for the algorithms - for such simple dyanmics best to do it straight off the response data  - at least as a check.
• Note the "26" in the transfer function is the time constant, and it shoudl be about 1/4 of the time to reach steady state, that transfer function gives a time to steady state of about 104seconds.
• feedforward can be used if you want to get around such things - and it doesn't matter about the speed of the dynamics, providing they included in correctly. You can use feedforward with just a scalar gain (which you may be doing and may be less helpful), or you can also include the transfer function.
• FINALLY - always look at your controller output to see if that is saturating.