Long interval PWM and PID control

g.mccormick

Lifetime Supporting Member
Join Date
Jul 2012
Location
IN
Posts
960
I have an application where I will be opening and closing an actuated ball valve to humidify a space. The valve is a pneumatically actuated double acting valve with a namur mount solenoid valve on it. I don't think I want to be opening and closing this thing at 1hz (it will probably not live that long doing that). Since that steam pressure to this valve is very very low, I'm expecting that the open time will be long, and I plan to have a long base time PWM for control of the valve. I'm thinking that the basetime will be 30 or 60 seconds.

My question is, should I set my PID loop execution time to the same as my PWM basetime? I would think that I should. If I had the PID loop executing faster than the PWM time, then the loop would be calculating many times before actually acting on the output. Thoughts?
 
My question is, should I set my PID loop execution time to the same as my PWM basetime? I would think that I should. If I had the PID loop executing faster than the PWM time, then the loop would be calculating many times before actually acting on the output. Thoughts?

Absolutely not, you must set the PID loop update time (.UPD) to the same time period at which the PID instruction is executed.

PID instruction execution is typically scheduled in a Periodic Task for maximum accuracy, but in slow-acting loops it is satisfactory to use a self-resetting timer in the continuous task.

Whichever way the instruction is executed, match the execution interval to the .UPD of the PID control block. The PID terms will take care of the slow response of the controlled Process Variable.
 
Can you 'guess' the deadtime and lag time of the process from your design inputs?
Ideally you want your loop update time to be < 0.1*lag time.
It is easiest if your valve duty is equal to your loop update time.
If not, you can still get away with a trick of ending early, ending late, starting early or starting late.
Eg, duty =1minute, loop update =20s
OP =50%
You turn your valve on.
20 seconds later your OP changes to 45%.
7seconds later you turn your valve off.
 
Absolutely not, you must set the PID loop update time (.UPD) to the same time period at which the PID instruction is executed.

PID instruction execution is typically scheduled in a Periodic Task for maximum accuracy, but in slow-acting loops it is satisfactory to use a self-resetting timer in the continuous task.

Whichever way the instruction is executed, match the execution interval to the .UPD of the PID control block. The PID terms will take care of the slow response of the controlled Process Variable.

In another thread, it was suggested that the PID execution interval could be dynamic, using the PLCs clock, to "tell" the PID how much time had elapsed since the last execution. The suggestion was that this would compensate for varying execution timing.

At first glance you might think this is a great idea, since the PID does calculations based on what has happened, in real-time, since its last execution.

But consider that the PID instructions accumulate Integral and Derivative values over many executions, so these are just going to be meaningless if you vary the instruction's execution rate.

Integral and Derivative are time-based gains, so the PID instructions have to be executed, regular as clockwork, on a known time-base for the I and D terms to work as expected.

Basic concept - execute the PID instructions on a fixed timebase. You can vary execution rate for any control logic, but the PIDs themselves need a constant rate.

Furthermore, there is no point in executing PIDs every 10mS if the analog input driving it are only updated every 100mS. That is just a waste of processor resource.

A little bit of thought behind what is being done, and when it is being done, can alleviate many process PID "problems"
 
daba,

speaking generally and not specific to allen bradley PID blocks, why wouldn't this work for a PID with a elapsed time that wasn't exactly the same every iteration:

proportional term = error * proportional gain

integral term = integral term + error * elapsed time * integral gain

derivative term = (error now - error last time) / * derivative gain

cv = proportional term + integral term + derivative term


the steady state error is multiplied by time for the integral term
the derivative term is automatically accounting for time by virtue that there will be a larger change the longer the elapsed time is. We could divide the derivative term by the elapsed time to get change/s but then would just have to multiply by elapsed time at the output stage to account for the execution period.
 
Try to use the longest time possible (without interupting the process) 60 seconds still is a lot of movements in a day, It will break the mechanics inside. So better to use 30 minutes or even more. Do Not use standard PID as this is not best for the process, it will be going up/down too much. Just test it every 30 mintes too low open valve too high close it.
 
Try to use the longest time possible (without interupting the process) 60 seconds still is a lot of movements in a day, It will break the mechanics inside. So better to use 30 minutes or even more. Do Not use standard PID as this is not best for the process, it will be going up/down too much. Just test it every 30 mintes too low open valve too high close it.

I disagree. It is a lot of cycles, but that isn't a problem. I've used much shorter cycle times than that. You simply need to specify the operator for either "modulating" or "continuous duty" and you will be OK. After all, an analog positioner can be cycling almost continuously - that's what "modulating duty" is for.

Having said that, PID is not a good choice for long response time. I suggest following Lare's suggestion of floating control.
 
I am using an AutomationDirect P2k for this, not a AB product.

Tom and others, your comment on floating control, in reading that document it is basically propotional only control correct?

Output = Pgain * (setpoint - feedback)

I think that would probably work very well for something like this. I would use the output to drive the 1min timer. I would also probably add logic around the this so that if the output is greater than say 95% just keep the valve on constantly, and if the output is less than 5% keep the valve off. That way it is quickly cycleing at the frindges.

Psuedo code:

if PV < Setpoint then
Output = Pgain * (Setpoint - PV)
else
Output = 0
end_if

Tmr1_enable = NOT Tmr1_Done
Tmr1_preset= 60sec

Tmr2_enable = NOT Tmr1_Done
Tmr2_preset = (Output/100) * 60sec

if (Output > 5 && ( (NOT Tmr2_DONE && (Tmr2_val != 0)) OR (Output>95) ) then
OutputValve=ON
else
OutputValve = OFF
end_if
 
I disagree. It is a lot of cycles, but that isn't a problem. I've used much shorter cycle times than that. You simply need to specify the operator for either "modulating" or "continuous duty" and you will be OK. After all, an analog positioner can be cycling almost continuously - that's what "modulating duty" is for.

Having said that, PID is not a good choice for long response time. I suggest following Lare's suggestion of floating control.


He said it had a solenoid on the actuator so it’s most likey just an open/close actutator he has. Just the wrong equipment for the job. Agree that an analog positioner is what he needs.
 
He said it had a solenoid on the actuator so it’s most likey just an open/close actutator he has. Just the wrong equipment for the job. Agree that an analog positioner is what he needs.

Oh yes I def. have the wrong equipment. The "mechanical engineer" that was in charge of this equipment screwed up two ways.

1. He thought he was buying a steam boiler (you know something that would just make pressurized steam all day long, say 10-15psi). Instead he bought a steam humidifier (desiged to boil water and vent steam directly into duct work, running at 0psi).
2. Since there is not going to be any steam pressure, he supplied 1.5" fullport actuated ball valves.

I would very much like to have a pressurized steam source feeding a modulating valve, but ....
 
He said it had a solenoid on the actuator so it’s most likey just an open/close actutator he has. Just the wrong equipment for the job. Agree that an analog positioner is what he needs.

My mistake. There are solenoids designed for rapid cycles, though. An example would be pneumatic pick and place applications.
 

Similar Topics

Hello, I have a issue with tuning a slow acting PID loop using AB PIDE instruction. The system is designed to cool a tank after it heats up...
Replies
141
Views
102,422
I have Allen Bradley plcs, I have had Circuit breakers and other automation equipment in the past. There's no solid buyers local. How much do you...
Replies
2
Views
192
I have a question. I work in a very large plant and this one (of many hundreds of control cabinets) contains one 5580 (1756-L83E), two 1756-L73...
Replies
6
Views
198
Hi to everybody. I need to read the first 12 characters of the message that a barcode reader sends to the ascii card (1734-rs232 ascii) and I...
Replies
8
Views
720
Hello all. This is a very lonnnnnnng shot but worth a try. I have an OMS Group Impact100 metering machine. At this customer it blows foam into 3d...
Replies
0
Views
182
Back
Top Bottom