CLX PID ladder

When using the PID instruction, I've used the timer trigger with the DN bit in the rung as I've read. PID works fine. I've included a examine on instruction (auto mode)in the same rung when we are in auto. Does this make sense. Also what is the best method to shut down the CV of the PID when not in auto mode. Thanks for your help. You guys are great. Hopefully I'll get to a point I can start answering some questions.

No. Leave the PID running all the time. To set it to 'Off' or 'Manual', set the PID_DATA_BLOCK.SWM bit true.
Then you can directly write to the PID_DATA_BLOCK.SO if you like.

I agree, leave the PID running all the time.

I use a man/auto bit to set the LOOP.MO bit and manipulate the tieback for manual positioning. That way you have bumpless transfer from manual back to auto.

Thanks, do I have to write to the PID_DATA_BLOCK.SO or is this setting my output to zero if I don't?

Forgot to mention I have 50% bias.

Setting the .MO sounds like the way to go since I may need to manipulate the unit in a Manual mode also but I don't know anything about tieback.

There are several ways to do it. What I do is use the tieback variable (float).

In auto I write the loop output LOOP.OUT to both the tieback and to your register value for manual output. When the loop is switched to manual (LOOP.MO bit set), write your manual output value to the tieback variable and that controls the output directly. Switching back to auto is bumpless, the loop starts to control from where the manual output variable was left last.

I tend to always use a seperate register for setpoint and manual output so the range can be checked before loading them into the PID block registers.

Black Jack
In the case I'm working on there wouldn't be the need for bumpless transfer (I think). I have:

+/- 10 volt detector - PV
+/- 10 volt output to drive actuator - CV
setpoint = 0

While in auto, in closed loop. While in Manual, drive the actuator
to either extend or retract for the duration of how long the operator holds either button. When placed back in auto, actuator
to drive process back to setpoint.

This is why I want to get clear in my mind how to program when the operator example... releases manual mode retract button that the CV does not keep driving the actuator.

Thanks

I have found that I don't need a bumpless transfer and learned you can defeat this by checking the "no bias calc" in the PID configuration if proportional gain only is used, which supports my purpose just fine. I set the PID .swm bit and moved 50 into the .so

which stops the output. When I go back out of swm and the PV
has changed, the CV drives the process to the setpoint immediately.

If I want to jog while in swm, I move a higher or lower value than
50 to the .so. Tried this several times and works fine.

You might like to consider execution of your PID instruction inside a Periodic Task, rather than a timer trigger in your main task's scan, especially if your main cyclic task execution time is "getting on a bit". You must also set the PID Update Time (PID.UPD) the same as your interrupt interval. And I agree with the other answers, no conditions on the rung, execute PIDs every scan

PIDs are easier to tune, and the output more stable when executed at more precise intervals.

Also if the program scan time changes (additional code added, for example), then you don't need to worry about PID execution and update times.

Thanks daba

Is the "interupt interval" the same as the update rate in the PID configuration?

I guess you mean the periodic task interupt interval.

Thats a good point and I agree that the control seems to me much tighter when using a periodic task. I do set my update and periodic task the same.

Yes, Jim

The Period Task Interval (CLX) = Interrupt Interval (PLC5 etc.)

The Interrupt interval at which the Period Task is triggered is another way to say it.

And doug2,

doug2 said:

I do set my update and periodic task the same.

Click to expand...

Exactly right, and as it should be, that's the only way the PID knows how to do it's Integral and Differential Maths properly. I've seen PID loops set-up with, say, 1 sec in the .UPD parameter, and the PID scanned in the main task at something like 120 mS intervals. The loop appeared to be quite stable, although sluggish, and I guess the I + D terms were just meaningless numbers, obviously arrived at by "trial and error" tuning.

I moved the PID instruction into a Periodic Task at 500 mS interval, put the .UPD parameter to 0.5 Secs, and retuned the loop. I was able to get a much faster response, and stable, smooth control.