View Full Version : Unexpected sign change at pid loop output
October 1st, 2009, 10:56 AM
Hi all. Iíve got an FX1n running a P/I loop. When the output of the loop is required to drive full-on, the value in the associated register counts up and eventually exceeds the advertised range of 32767 and continues onward, which means that the 16th bit in that register comes on and the output is interpreted as negative. This doesnít help much in maintaining the real output in a saturated state. Any thoughts or experience on this one? Cheers.
October 2nd, 2009, 03:23 AM
the variable is a signed integer and you should use only integer, also a maximum can help
October 4th, 2009, 06:50 AM
Thanks, Shooter. I understood what was happening, but not why it was happening, especially as the manual gives a range of 0 to 32767 for the output. Can I specify a "D" register to be unsigned? DB.
October 4th, 2009, 08:01 AM
I've never done PID control on a FX1n but are there not minimum and maximum control limits built into the PID instruction? There should be some way of controlling the PID output and limiting it to a certain range (I'm thinking a combustion air system where you never want to fully close the air/gas valves)
Even if its not in the PID instruction itself, could you not put [Less than] and [greater than] instructions ofter the PID to limit its output?
October 4th, 2009, 08:30 AM
The PID should never overflow. It should saturate at 32767 and stay there. Limiting the output will not limit the control signal generated by the PID. It will still take time for the PID to unwind a get back into the positive range.
I would write my own PID but first I would find out why the control signal needs to saturate. This is caused by a few things:
1. The polarity of the wiring is wrong. If so there will be positive feedback instead of negative feed back
2. The control system doesn't have enough power to reach the set point.
3. A step change in the set point is causing a huge error and the resulting huge control signal.
October 4th, 2009, 09:43 AM
Christoff, that's exactly what I had to do. Effectively: if [o/p] >32767, [o/p]=0. I really didn't want to for the reason that Peter states. Peter, the wiring is ok; there's enough power to do the job (when it settles, it's running at about 30%). But from cold, or even a large positive demand step change, surely there's nothing wrong with it saturating so long as the proprietary loop software doesn't do crazy things like exceed the advertised max value? DB.