RS5000 PIDE w/2 TC's & SRTP???

[Gerry]

Here is the full quote:

Feed forward value. The value of feed forward is summed with CV after the zero-crossing deadband limiting has been applied to CV. Therefore changes in FF are always reflected in the final output value of CV. If FF < –100 or > 100, the instruction sets the appropriate bit in Status and limits the value used for FF.
Valid = -100.0 to 100.0
Default = 0.0

(emphasis mine)

FeedForward does not preload the integrator.

With all due deference to Ron - he has posted many long dissertations on the subject of PID control - I would argue that in this particular case, FeedForward may be all you need.

Given:

• air flow is constant - you say it is compressed air, presumably fed from a regulator.
• transport time (inlet to outlet) is negligible
• heater has fast response

You should be able to establish a transfer function for the heater by comparing inlet and outlet temperatures for different percentages of output. It may or may not be linear. Use this information to calculate the FF value based on the difference between desired outlet temp (setpoint) and actual inlet temp. This value on its own will provide the desired steady state output.

So, why use the PIDE block at all?
Well, maybe the air flow is approximately constant, maybe the heater response isn't quite as fast as you think, maybe you use a linear transfer function but it's really just close to linear. The errors introduced by these factors can be 'trimmed' out with the PID functions of the block (PV = outlet temp.). The bulk of the CV is the FF and the PID contribution is minor, i.e., coarse and fine controls.

So, I suggest using only FF to begin, then add PID if required.
If transport time is not negligible, then a lead/lag block may be required to condition the FF.

tip: make the cycle time on the SRTP block as short as you can

 

[Ron Beaufort]

Greetings Geared,



just to finish up from my end of the discussion ... the “more FF - less PID” approach offered by my distinguished colleague Gerry is probably the right way to go ... I’m sure that he has more “real-world” experience with a system like this than I do ...



I based my recommendations on the assumption (gosh I hate that word) that the actual “tuning” of the Proportional, Integral, and Derivative actions of the PID would be much easier to accomplish if the FF were turned off during the tuning ... from the simplest perspective, just “seeing the reaction” of the PID might be very difficult if the effects of the Feed Forward were stabilizing the system ... but again, that’s just an assumption ... as always with process control, a LOT depends on YOUR conditions, YOUR application, YOUR equipment, etc. ... specifically, one size does NOT fit all ...



and now a request ... after you’ve gotten this system up and running, please come back and resurrect this same thread ... be good enough to post the “final outcome” so that the rest of us can learn from your experience ... we’ll all appreciate that ...

 

[CroCop]

Here is the full quote:

(emphasis mine)

FeedForward does not preload the integrator.

With this instruction set, yes. With the ADC 06 & 205, it adds (preloads) to the integrator to feedforward. Sorry for any confusion.

 

[Geared]

Thanks guys,
I will begin testing this week and will keep you up to date with questions/observations.

 

[Peter Nachtwey]

Feed Forward

The heat required to maintain termerature will be roughly proportional to the outlet TC - inlet TC. I would multiply the difference between the two thermocouples by a feed forward gain and use the result as the feed forward input to PID block.

Tuning the feed forward is easy. Just disable or reduce the PID gains and try to get the feedforward to work as well as possible by itself. Then add the PID gains back.

If the air velocity changes then one can make the feed forwards even more adaptive by mulutiplying the difference in the thermocouple temperature by the velocity and then multiply by the feedforward gain.

The idea is to make the feedforward term is accurate as possible so the PID does as little as possible.

 

[Ron Beaufort]

I'm missing something here folks ... I haven't had time to think this one out completely - but here's what's bugging me so far ... if you can spot where I'm going wrong, please help me out here ...

when you set up the Feed Forward, shouldn't you (in fact, MUSTN'T you?) set it for not as "close as possible" to the final desired output - BUT - instead set it for something somewhat BELOW the final desired output ??? ...

maybe (probably) I'm just looking for problems where there aren't any ... but it seems to me that if you set the Feed Forward "as close as possible" to the desired final output (the target/setpoint), then you're definitely going to have a problem when the inlet temperature eventually strays a little too high ... specifically, the PID can NOT "cool" the air ... it can only "heat" the air ... so if the Feed Forward just happened to crank in a little bit too much heat, the poor PID could only TRY to go to a zero output ... but the FF addition would still keep the air too hot ...

I'm probably just missing something here ... but I've always considered the FF something to add in when (and if) it's necessary to "help the PID along" ... this idea of using the FF for the "bulk" of the control, just seems sort of "weird" to me ... so I'm ready to learn something new ... if you can make sense of this off-the-cuff description, please help me out ...

I'll try to be more detailed in a day or so ... or then again, maybe I'll have one of those "ah-ha" moments and realize just what you're trying to say ... but from where I sit right now, it looks like you're going to a lot of trouble to engineer a Feed Forward mechanism - just to do something that the PID was already made to do ...

boiled down (as close as I can for now) ...

I've always thought of the PID as doing the controlling - and a small amount of FF being added (or subtracted) to help the PID along ...

you seem to be talking about using the FF to do most of the controlling - and allowing the PID to add in (it sure can't "take out") enough heat to do the "fine tuning" ...

this approach is new to me ... so am I missing something? ... or just getting ready to learn something new? ...

 

[Peter Nachtwey]

Feed forward or Bias should be dynamic.

Ron, I think you understand and you are right about the feed forward supplying too much heat is being a problem. Your suggestion for the feed forward to supply just a little less than is needed is good.

you seem to be talking about using the FF to do most of the controlling - and allowing the PID to add in (it sure can't "take out") enough heat to do the "fine tuning" ...

Yes, certainly! Your hotrod has a gain of about 3.69 degrees per percent output. If you calculate the difference between the set point and ambient temperature and divide that by 3.69 degrees per percent output you will calculate an control output that will get the PV close to the SP with out the PID. The PID gains can then just be used to trim the system.

The problem with feed forwards is that they often need to be modified. For instance the system gain changes when you turn on your fan. If you calculated the gains with the fan on then you might get a gain close to 3 degrees per percent output. Now the PLC can monitor if the fan is on or off and change the feed forard gain, which is the inverse of the system gain, on the fly. Cool... or do I mean hot.

In motion control I calculate feed forwards based on velocity, acceleration and jerk. I know what these values are since they are calculated every scan. I can multiply each term by their feed forward gain each scan to get the current feed forward output:

Feedforward Output = Kv * target velocity + Ka * target acceleration + Kj * target jerk.

If the feed forward gains are calculated correctly the error will be very small while accelerating, deceleration or just moving along.

You can do the same thing with ovens. The amount of heat required is portional to the (SP - ambient) * heat added to each unit of material * rate at which the material is moving into the oven. You can use this data to calculate a feedforward or bias that changes dynamically. The BIAS should not be a constant value. Getting close is MUCH better than not trying at all.

One more thing again. Feed forwards don't have problems with dead times. Norm did a overn control lately with a lot of dead time.

Norm where are you?

 

[CroCop]

Peter, A couple of Qs if you don't mind

You can do the same thing with ovens. The amount of heat required is portional to the (SP - ambient) * heat added to each unit of material * rate at which the material is moving into the oven. You can use this data to calculate a feedforward or bias that changes dynamically. The BIAS should not be a constant value. Getting close is MUCH better than not trying at all.

Peter,

I have a quartz oven capable of putting out 8000 watts. I run the Setpoint at 150 C. My ambient is 30 C. The rate is roughly .4 inches/second.

How would I go about calculating the feedforward value? I can understand the motion, as Velocity is the derivative of Position, Accel is the derivative of Vel, etc., but I'm a little at a loss on the heat transfer.

 

[Peter Nachtwey]

Varying heat loads

If your load never changes then you don't have to worry about the feed forwards as a function of load change. You can still use the feed forward to estimate the output as a function of temperature set point.

CroCop, you must be heating widgets of some sort. What is the difference in the output required when no widgets are entering the oven and when widgets are entering at the fastest rate?
Now if the widget rate is half of the maximum rate, don't you think the difference between the output for half rate and stopped is half the output of the difference between the full rate and stopped?

The line speed isn't as important as the rate of widgets entering the oven and how much heat each widget absorbs.

Now your heaters will predict the load instead of respond to the changes.

 

[CroCop]

I'm heating a widget all right. It's a stainless steel wire with a PEEK covering. It heat shrinks the PEEK on the wire.

The wire is held by a gripper, which has a higher thermal load then the wire. I pass over the entire thing, grippers and all, and have a slight bump in PV when the grippers exit, and a slight dip when the grippers enter the oven. This leaves a small part (.2 inch) unmelted. It's not critical, but it would be nice to adhere the whole thing (we strip & cut the ends roughly .5 inch).

I'll trend my PV & output as a function of position with the grippers & wire. I'll have to see what the ratio looks like.

Thanks.

 

[Peter Nachtwey]

Control is similar to history

Use the past to predict the future. Use the PID to correct for things you can't predict.

 

[Ron Beaufort]

Control is similar to history
Use the past to predict the future. Use the PID to correct for things you can't predict.

now THAT'S profound! ... is that a Nachtwey original? ...

and thanks, Peter, for the information on FF ... and to Gerry for bringing up the "bulk FF" idea for discussion ... next time I've got the Hotrod fired up, I'll check some of this stuff out ... but at least now things make more sense ...

thanks again ...

 

[Peter Nachtwey]

Not original

now THAT'S profound! ... is that a Nachtwey original? ...

Some how I don't think you are convinced.

 

[Ron Beaufort]

Some how I don't think you are convinced.

convinced? ... Peter, if I ever have to "phone a friend" about something like this, yours is the number that I'll dial first ...

it's not that "I have to see it to believe it" ...

instead, it's that "I have to see it to fully comprehend it" ...

I appreciate your patience ...

 

[Peter Nachtwey]

"I have to see it to fully comprehend it" ...
I appreciate your patience ...

I can easily arrange that over the internet.