ni.com is currently undergoing scheduled maintenance.
Some services may be unavailable at this time. Please contact us for help or try again later.
08-27-2015 10:58 AM - edited 08-27-2015 11:02 AM
Now that we have that terminology straight, would you like to review your graphs?
It looks like you had your "manual setpoint" at ~12 before the switch. Is that right? During that time, the output of the controller was ~12.
Then, at the end, you are finally in control at ~ 85. Is that correct?
That to me indicates that you tried to switch to auto before you were steady and that you have some weirdness in the system where the controller increases the output slightly and your PV goes way down to almost 0.
I don't think we're going to get anywhere until we figure out why the system does what it does. I'm guessing there's a bug somewhere else.
08-28-2015 07:23 AM
"That to me indicates that you tried to switch to auto before you were steady". Does the system have to be steady before switching to Auto? If so, I don't understand the point of even using Auto.
08-28-2015 09:22 AM
No... you don't necessarily need to be in steady-state to use Auto, although it is better IF you are in steady-state. This would make the transition better.
I think part of the problem you have is because what you are calling "Manual Setpoint" is not what you think it is... Notice the graph. The controller output value starts at ~12 and then, your 'process variable' have the tendency to go to ~20. Then, you switch on the controller and the 'output shoots up and stabilize in ~80. It tells me that your mapping from the 'manual' to the 'auto' is not quite right. What happen it you feed ~80 to your 'manual setpoint' ?
Another aspect of your system is the 'rapid' transition. This is not very unusual... temperature systems are slow in response and it woudl not just jump like that. However, you said you are measuring power (W)? This is J/s rate and I believe that your system has a rapid response to the 'derivative' of the output, which means that you can improve its performance by using a 'rate limiter' on the output of the controller. This will require you to retune your controller, but it would avoid those spikes on the system. Also, this indicates that you shoudl avoid use the 'derivative' action on your controller. What happen if you remove it?
Again, depending on how tune, that kind of behavior could happen...
08-28-2015 10:53 AM
One more thing to consider... If you look at this large version of your graph:
You will notice that right after you go in 'automatic' mode (I assume it was a time step before the left part of the box), you will have a small change on output that express is a large change on the process variable. This indicates that: a) the sensitivity of your system is way too high or b) the value that the controller output is showing is not what is really applied to system in real life.
Then, notice that after this initial jump, then the PID rapidly try to track and go back to specific setpoint.
08-31-2015 12:33 PM - edited 08-31-2015 12:36 PM
@vt92 wrote:
"That to me indicates that you tried to switch to auto before you were steady". Does the system have to be steady before switching to Auto? If so, I don't understand the point of even using Auto.
In my experience, yes. When you switch from manual to auto, the controller has to back calculate what P, I, and D need to be in order to keep your output steady (that's the bumpless part). If you aren't steady, it will not calculate the correct values for P, I, and D.
The purpose of "Auto" is that once your system is "in control", the algorithm can adjust the output to adjust for perturbations. In your graphs, the algorithm did the right thing (slightly increased output from ~12 to ~13). It's the system that responded oddly (PV goes down?)