Sign in to follow this  
Followers 0
BobLfoot

PID Loop Implementation

56 posts in this topic

OK here is my scenario. 1. I have an Air handler which is circulating air to keep a process room at 50 Degrees F. 2. The Air handler has a cooling coil supplied with 10 Degree F Glycol and H2O mix. 3. THe glycol flow rate thru the coil is controlled by a Worchester Proportional Valve. {0 - 100%} 4. Control for the valve comes from a PLC5/30 outputting 4-20 ma. {0 to 4095} 5. At this time we have a free running 30 second timer which triggers valve position update. 6. If at trigger time room temp is above setpoint we add 100 to setting. 7. If at trigger time room temp is below setpoint we subtract 100 from setting. This is working moderately well. Can't seem to reach and maintain Setpoint though. And system is poor to respond to "spikes" in loads. We can predict these to follow shortly after we turn on a process machine in the room. I want to use a PID Loop Control. Any guidance for setpoints? P.S. - It is fairly critical I not Fault this processor with the process running. {Explosion Hazard exists controlled by other non plc means} but conatinment is not pretty and neither is the paperwork.

Share this post


Link to post
Share on other sites
Bob: You don't mention room size nor the amount of response (in terms of temperature variation) you get when making changes in your existing system. Also, how often the heat load actually (as a result of machinery starting and stopping) varies and how much that affects AC loading is obviously a factor. I am no guru, but I control a vacuum situation here that is not as exacting as your requirement, but the idea may work for what you are doing. By experimentation, I determined at which point nearing "shut" that closing the valve further made little difference. Then did the same thing on the "open" side. These became my "usable" or "effective" travel limits. So, when something disrupts my vacuum system, that event triggers the valve to travel to the high or low "effective" travel limit, as appropriate. When the vacuum reaches the max of it's deadband, the valve travels to the other end of it's "effective" travel. At that point, the program subtracts 1% from the limit setpoint that the valve just "left" (i.s., if traveling open, it just "left" the shut setpoint). When the process reaches the minimum point of the deadband, the valve travels back to "open" at it's previous point, minus 1%. Then the program subtracts 1% from the other limit setpoint. In fairly short order, the valve finds it's "happy place" and stays there until the next perturbation in the process. This may be too slow and sloppy for your application, but thought I'd send it along just in case. I read everything you write and have learned a great deal - thank you! Bill

Share this post


Link to post
Share on other sites
I have ran into this problem several times but never with a PLC5, The problem that I have ran into has been that the PLC way too fast for the "Slow Response" of the system. Most of the time it takes a bit of testing inorder to determine whether or not a PID will function properly without too much of a tempature swing. I would be very tempted to try a 5 second interval with a something like a increment of 3. I know this is not a proportional value but, the quicker the that the change is monitored the less correction will be needed. Another manner, is to use the output of the first PID to as the Process value of a second PID, which will slow the recaction / response. For the PLC5 I would just limit the Control Value to 0-4095 to prevent faulting out the processor, and enter a large Update Time.

Share this post


Link to post
Share on other sites
nonsense. I can control this with a 250 micro second update motion controller. A 30 second update is too slow. Since you have a analog input you need to calculate the rate of change of temperature too. You need a PID and use at least the PI part of the the PID. BobLfoot you need to get a trend with the CV and PV showing a distrubance. Try to get as much resolution in both data and time as possible. Then post the data. See www.controlguru.com

Share this post


Link to post
Share on other sites
Will do and thanks for the response Peter. I'm on a rare 4 day holiday right now, but I'll have more info come Tuesday.

Share this post


Link to post
Share on other sites
if you're putting the PID into operation while the system is running (possible - but not recommended) make sure that the PID's Loop Update Time setting is NOT "0" ... the PID divides by this number as part of its internal calculations ... the attempted "divide by zero" will usually fault the system ... also make sure that the setpoint is within range when the PID rung is executed for the first time ... in many cases, an "out of range" setpoint can also cause a fault ... teaching this week ... will try to participate more next week ...

Share this post


Link to post
Share on other sites
Thanks Ron. 1. Loop Update Not Equal Zero - Will watch this one. 2. Setpoint is in range - I'll make sure of this as well. How about Auto, SWM and MAN modes what is all this about?

Share this post


Link to post
Share on other sites
Greetings Bob ... I’ve had a little bit of spare time ... here’s what I’ve been able to come up with so far ... first of all, from your mention of the “SWM” (Software Manual) mode, it looks like you’ve decided to use the PD-type control block for your PID ... this is fine – perfect in fact ... the only reason that I might recommend using the N-type control block instead would be based on the fact that your plant might also use the older “classic” type PLC-5 processors for PID control ... (note that “Software Manual” mode would be called the “Set Output Mode” if you had been talking about the older N-type of PID control block) ... you didn’t specify which of the two available “PID Equation” settings that you intend to use ... the newer “Independent” setting is the default – and many people like it because it is generally a little bit easier to tune than the “Dependent” form ... the basic idea is that with the “Independent” setting, the three components of the controller’s output (Proportional action, Integral action, and Derivative action) are all separate (independent) of each other ... specifically, you can increase or decrease the effect of any one action without changing the effect of the others ... on the other hand, when using the “Dependent” equation, any change in the Proportional setting will always have a simultaneous effect on the Integral action and also on the Derivative action ... with all of that having been said, it usually looks like the “Independent” equation is the better way to go ... but ... regardless of everything that I’ve just written, personally I’d still recommend that you bite the bullet and use the “Dependent” equation for this project ... here’s the reason ... most other PID controllers use this “old-fashioned” dependent-gains type of equation instead of the “new-fangled” independent-gains system that sounds so attractive ... and this includes the SLC and MicroLogix platforms – and most other non-Allen-Bradley brands of controllers too ... also, most experienced people who have developed a “seat-of-the-pants-feel” for PID tuning, have done so with the older “dependent” equation ... and most published “systems” and recommendations for tuning are also based on the older “dependent” equation ... this means that any “more-of-this-and-less-of-that” type of advice that you’re likely to receive is probably going to be based on the DIFFERENT reaction of the older the equation ... so everything considered, I’d go with the “Dependent” equation if I were you ... still it’s your personal choice to make ... for most systems, either equation will give the same degree of control ... specifically, there is usually NO DIFFERENCE in the quality of control – just usually a slightly easier – or slightly harder - job when it comes time to “tune” the loop for your system’s characteristics ... moving right along ... you said: your use of the plural for “setpoints” is a little bit out of line ... here’s the basic idea ... there is only ONE “setpoint” for each PID loop ... with Allen-Bradley systems, the word “setpoint” always means the “target” setting ... specifically, it’s the desired temperature/flow/level/pressure/etc. that we’re trying to achieve with our PID controller ... I’m guessing that you originally used the word to mean the “settings for the tuning parameters” and not to refer to the “target” setting ... if I understand your project correctly, the “setpoint” will be your desired target of “50 degrees F” ... just so that everyone stays on the same page, here is a brief rundown of the MAIN abbreviations that we’ll be using in this project ... SP = the “Setpoint” – this is “what we want” ... (ex: our target/desired room temperature is 50 degrees) ... PV = the “Process Variable” – this is “what we’ve got” ... (ex: our current/actual room temperature is 59 degrees - too hot) ... CV = the “Control Variable” – this is what the PID controller is doing to the output device (ex: increase the control valve signal from 31% to 33% for more cooling effect) ... note that while it might seem logical, “CV” does NOT stand for “Control Valve” like some beginners assume ... and now we come to a fork in the road ... if we’re using the recommended “Dependent” equation, the PID tuning parameters will be: “Kc” for the Proportional setting ... “Ti” for the Integral setting ... “Td” for the Derivative setting ... but if we’re using the default “Independent” equation, the PID tuning parameters will be: “Kp” for the Proportional setting ... “Ki” for the Integral setting ... “Kd” for the Derivative setting ... now before I run out of time, let’s run through the basic mechanics of setting this PID thing up ... keep in mind that all of the following information is based on several assumptions (gosh I hate that word) about your system ... one assumption is that the input signal (PV/room temperature) arrives at the PID as a raw integer data value which ranges from 0 to 4095 ... if this assumption is not correct, then you need to tell us exactly how the signal is set up before we go any further ... in my example, I’ve used N7:54 as the PV location ... next we need to know how the input signal is scaled ... I’ve assumed that your “room temperature transmitter” puts out a 4.00 mA signal when the room temperature is 0 degrees F ... this would correspond with a raw data value of 0 at N7:54 ... I’ve also assumed that your “room temperature transmitter” puts out a 20.00 mA signal when the room temperature is 500 degrees F ... this would correspond with a raw data value of 4095 at N7:54 ... naturally these assumptions are almost certainly wrong ... for one thing, the wallpaper would catch fire at a room temperature of 500 degrees F ... but I included these examples to demonstrate the type of detailed information that we’ll need in order to get this thing working ... my assumptions on the output signal will probably be more accurate ... the output signal (CV/drive-to-the-valve) will leave the PID as a raw integer data value which ranges from 0 to 4095 ... in my example, this output signal will be sent to N7:75 ... I’ve assumed that your “control valve” accepts a 4.00 mA signal as a “fully closed” command ... this would correspond with a raw data value of 0 at N7:75 ... I’ve also assumed that your “control valve” accepts a 20.00 mA signal as a “fully open” command ... this would correspond with a raw data value of 4095 at N7:75 ... again, if any of these assumptions are wrong, we’ll need more accurate information before we can get this thing working ... moving along, here are some “just getting started” examples for discussion purposes ... your addresses and settings will certainly be different ... note to all readers: there are MAJOR (I repeat MAJOR) differences between how PID controls are set up in the various Allen-Bradley platforms – and sometimes even within the same platforms ... in other words, the arrangement that I’m showing here will NOT work correctly in an SLC or MicroLogix system ... but that’s another kettle of fish – to be fried another day ... the first rung above shows a “repeating trigger” arrangement using an XIO for a TON timer’s Done bit – and the TON timer itself ... the timer’s Preset value determines the cycle’s period ... we’ll use the timer’s Done bit in the next rung as a “trigger event” to force the PID into a regularly scheduled (tick-tock-tick-tock) operation ... the second rung shows the PID instruction using a PD-type control block address – triggered by the timer’s Done bit as described above ... the N7:54 Process Variable (PV) location shown is just an example ... in your system, this COULD BE the location used by your “room temperature transmitter” AS LONG AS the transmitter’s full-scale range of values runs from 0 to 4095 ... secret handshake: the PID always expects its PV values to range “full-scale” from 0 to 4095 ... the PID can still be made to work if this range is incorrect – but it won’t give the best possible control ... if your input transmitter won’t provide the required 0 to 4095 range, then you should tell us about that in your next post ... the “Tieback” setting has been entered as “0” ... this disables the Tieback/Manual feature ... we can add this functionality later if you need it ... chances are that you won’t need it at all ... let’s just leave it turned off for now ... the N7:75 Control Variable (CV) location shown is just an example ... in your system, this COULD BE the location used by your “control valve” AS LONG AS the valve’s full-scale range of values runs from 0 to 4095 ... secret handshake: the PID always outputs its CV values to range “full-scale” from 0 to 4095 ... if your output device won’t accept this specified 0 to 4095 range, then you’ll have to program some type of math function to properly scale the PID’s output value before presenting it to the output device ... this is one of the two pages of settings for a PID using the PD-type control block ... note that some versions of RSLogix5 have slightly different settings ... the entries that I’ve highlighted in yellow are the “MUST SET” entries that we need to work with to get started ... the “PID Equation” setting for “Dependent” has already been discussed above ... if you decide to use the alternate setting of “Independent” please let us know ... the “Control Action” setting specifies how the PID will mathematically calculate the amount of “Error” ... for some people, the work “Error” means some type of “fault” has occurred ... when the PID uses this word, it just means “how-far-off-target-are-we?” ... here are the two possible selections for “Control Action” and what is meant by each ... “E=SP-PV” ... suppose that we use this setting ... suppose that the PV (input) starts to climb ... suppose that it keeps climbing higher and higher ... with this particular setting for “Control Action”, the PID will eventually make the CV (output) start to fall (decrease) ... “E=PV-SP” ... suppose that we use this setting ... suppose that the PV (input) starts to climb ... suppose that it keeps climbing higher and higher ... with this particular setting for “Control Action”, the PID will eventually make the CV (output) start to rise (increase) ... basically the question that we’re asking ourselves here is this: which way do we want the CV (output) to move in response to a steadily rising PV (input) signal? ... some people needlessly confuse this simple issue by referring to one setting as “direct acting” and to the other setting as “indirect acting” ... but then other people reverse those same definitions ... one man’s “direct” is another man’s “indirect” ... personally, I refuse to enter into that particular debate ... in the case of the “cooling” project at hand, the “E=PV-SP” is PROBABLY the correct setting ... but ... if the control valve happened to have a “higher-signal-causes-lower-flow” type of action, then the setting would have to be reversed to properly control the system’s operation ... notice that the “Update Time” setting has been entered as 1 second – and that this entry exactly matches the 1 second cycle of the timer’s Done bit “trigger event” on the PID rung ... this is probably the most misunderstood of all of the PID settings ... many people tinker around with this one in a effort to “speed up” or “slow down” the response of the PID during their tuning procedures ... this should NOT be done ... the basic idea is that this “internal” setting (the “Update Time”) needs to match the “external” setting of the PID’s “trigger event” ... if the two settings don’t match, then any calculated tuning values for the Integral setting and for the Derivative setting will be “skewed” ... and (very important) those two settings will be “skewed” in OPPOSITE directions – and in DIFFERENT amounts ... I’ve covered this particular topic in this thread for those who want to know more about it ... there are quite a few related posts - so if you want the whole story, don’t just quit reading after the first one ... so as I’ve said, the “internal” and the “external” values must match each other ... now the question becomes how fast – or how slow - do we need to “update” the PID? ... the basic answer is that “fast enough” is “fast enough” ... specifically, anything faster won’t buy us any better control ... but anything slower WILL degrade the control ... I’m just going out on a limb here and guessing that once per second is going to be plenty fast enough for this particular project ... I’m almost certain that this will be ok since you mentioned that your existing control scheme is using an update of once each 30 seconds ... now if it turns out that my guess is “too fast”, then it’s not going to hurt anything ... once we get the loop functioning, we might come back and fine tune this setting ... in the meantime, let’s go with a 1 second setting and get on with things ... if you want to read more about this, then this thread might be interesting ... the “Engineering Unit Maximum” setting should match the “full-scale” reading of your “room temperature” transmitter ... I’ve just guessed at a value of 500 for this one – I’m almost certain that this will be too high ... in my example, the value of 500 would mean “500 degrees F” ... just to nail this down for any beginners who might be reading along with us, “Engineering Units” simply means “Human Units” ... in other words, we’re trying to specify a number range that will be meaningful to us as engineers/humans/operators/etc. ... but we can’t just pick a number out of the air ... to get the optimum control, we need the number that will match the “full-scale” reading of the PLC’s input signal ... for most PLC-5 systems this will be the “human units” reading which matches the full-scale “raw data” reading of 4095 ... and so when a “wide-open” signal of 4095 comes in, what number do we want our operator to see on his display? ... we’ll need to know the answer to that one, Bob, before we go much further ... along the same lines, the “Engineering Unit Minimum” setting should match the “low-end” reading of your “room temperature” transmitter ... I’ve just guessed at a value of 0 for this one ... in my example, the value of 0 would mean “0 degrees F” ... along the same lines as the maximum signal, when a “low-end” signal of 0 comes in, what number do we want our operator to see? ... and again, Bob, we’ll need an answer to that one too ... for the “Input Range Maximum” setting, we need to know what the “full-scale” reading will look like to the PLC in its “raw data” format ... for most PLC-5 input modules (like the very common 1771-IFE), this is the 4095 value that I’ve entered for my example ... other temperature modules (like the 1771-IXE) give signals that are in different ranges ... so here we need to know what specific input module you’re using – and exactly how it’s been configured for operation in your particular system ... smart money says that 4095 is the right number, but we won’t know for sure until you get back to us with more detailed information ... along the same lines, for the “Input Range Minimum” setting, we need to know what the “low-end” reading will look like to the PLC in its “raw data” format ... for most PLC-5 input modules (like the 1771-IFE), this is the 0 value that I’ve entered for my example ... again, we need to know what specific input module you’re using – and exactly how it’s been configured for operation in your particular system ... for most systems, the example values that I’ve shown for “Output Limit High %” and for “Output Limit Low %” settings will be correct ... specifically, these settings determine just how high – and just how low – our PID is allowed to drive its CV (output) signal ... in some systems, a “wide-open” signal of 100% might be much too high for safe, reliable operation ... in those cases, the “Output Limit High %” setting might be dialed back to (for example) just 75% or 80% to keep things from vibrating off the wall ... along the same lines, the “Output Limit Low %” setting might be used to “keep-the-valve-cracked-open” just a little bit so that the system will “simmer along” even when the PID tries to close the valve completely ... since we can’t see your system in operation, tweaking little things like that are up to you, Bob ... but the more you can tell us about your system, then the more we can help ... the “Setpoint” setting is the desired “target” value that we want the PID to maintain ... this will generally be expressed in the same “Engineering Units” format that we specified for our scaling on the “Configure” screen ... somewhere along the line, you’ll probably want to allow the system operator to make changes to this particular setting – without being forced to use RSLogix5, of course ... in most cases an HMI is used to manipulate the value here ... as a “learning thing” do a right-click on the value and notice that a “tool-tip” pops up with the correct address for the setpoint ... using my example, this is “PD9:0.SP” ... the same “tool-tip” feature works for all of the entries on the PID screen – but be aware that some older versions of RSLogix5 had some bugs that gave the wrong addresses for a few of the settings ... if you suspect that type of mischief, use the Instruction Set Reference Manual to nail things down ... anyway ... the value of 50 that I’ve entered for the “Setpoint” in my example is your desired “target” value of 50 degrees F – as far as I understand your project ... notice that I didn’t highlight the “A/M Station Mode” setting for our “just getting started” setup ... this setting is associated with the “Tieback” feature that we decided not to activate for the time being ... just make sure that this setting stays at its default value of “Auto” until/unless we get around to using it ... that brings us to the “Software A/M Mode” setting ... this is something that you asked about in an earlier post ... it’s a very handy feature that you’re probably going to need to use ... basically you can double-click this little box and select either the “Auto” or the “SW Manual” mode ... in “Auto” mode the PID will be trying to control the CV (output) signal ... in “Software Manual” mode you’ll be able to drive the CV manually by entering the desired output value in the “Set Output %” setting at the bottom of this screen ... (and please don’t bother to ask me why they didn’t keep these two “go-together” entries side-by-side) ... you’ll DEFINITELY want to experiment with this particular “manual control” feature during the earliest stages of setting up the PID ... basically, if things start “going crazy” while you’re tuning the loop, this is usually your quickest and handiest method of forcing the output to a rock-steady signal of (for example) 15% to settle things down ... next we come to three entries that I’ve highlighted in blue ... these are the “tuning parameters” (they’re never called “setpoints”) that you’ll have to adjust in order to “tune” the system for proper operation ... I’m going to keep this particular “tuning” step on the back burner for now ... but basically, you’ll have to put SOMETHING into the “Proportional Gain” entry before the PID will start to put out any type of signal at all ... I always just start with a value of 1 (as shown in the example) and make sure that the PID is driving the CV in the correct DIRECTION for a “rising” and then for a “falling” input signal ... this is part of “commissioning” the system before any serious tuning takes place ... going just a little bit further, I’d recommend that you leave the “Derivative Rate” setting at 0 until much later in the game ... there is NOTHING wrong with using Derivative action ... but it’s kind of like using garlic when you first learn how to cook ... a little bit goes a LONG way – especially if you’re not used to using it ... as for the “Reset Time” setting – this will control the amount of “Integral” action from the PID ... if you’re using the “Dependent” equation (as I’ve recommended) then you enter a SMALLER number here to Increase the Integral action ... and you must enter a LARGER number here to Decrease the Integral action ... by convention, entering a 0 value will turn the Integral action completely off ... as I said, we’ll come back to these “tuning parameters” later in the game after we’ve confirmed that the PID is correctly set up and properly scaled for the input and output devices that you’re using ... now for the “Deadband” setting ... I’d strongly recommend that you leave this entry at its default value of 0 until MUCH later in the game ... in fact, this will probably need to stay at 0 permanently ... some people make a lot of mistakes with the Deadband idea ... the most common misconception is to assume that the Deadband specifies a range of “acceptable” values ... in other words, “I need to keep the PV (input) within this range – or else!” ... that approach won’t work the way most people expect it to ... in simplest terms, the Deadband range tells the PID: “ok ... we’re close enough for government work – so don’t change the output signal again until we leave this Deadband range” ... oops! ... if we don’t change the output signal until we LEAVE the Deadband, then we’re guaranteeing that the input signal will eventually drift outside of our intended range ... nailing this down, the Deadband (if you use one at all) must be much “tighter” than your required “specification” range ... if it’s not, then you’re definitely going to exceed the “specification” range that you require ... you can read more about the Deadband in this post... in the meantime, just leave this one set for 0 and let’s get on with more important things ... now to on to the “Output Bias %” setting ... notice that I’ve entered a 0 into this one for my “getting started” example ... but what you’re going to find is that the 0 won’t always stay there ... specifically, this one is going to “jump around” on you as the system operates in its various modes – PARTICULARLY whenever you use the “Software Manual” mode and the “Reset Time” setting remains at 0 ... secret handshake: the PID sometimes uses this location “behind your back” as an internal math register ... let it do that ... just BE SURE to remember that once you’ve cranked in a value for the Integral action’s “Reset Time” entry, you’ll need to come back here and type in a 0 again ... if you don’t, then the “left-over” value specified here in the “Output Bias” setting will be ADDED TO the PID’s CV (output) signal ... and incidentally, this location is where we’ll eventually dial in the “feed forward” signal that our distinguished colleague Peter Nachtwey will certainly be interested in using ... now a reality check ... so far I’m up to eight pages of typing – and we’re just getting started ... no complaints ... actually I enjoy this stuff - just in case you couldn’t guess ... but notice that I’ve only mentioned about half of the settings on the PID setup screens ... and as for the settings that I HAVE mentioned, each one of them could use a LOT more detail ... and we haven’t even started to tune the loop yet ... my point is this: I personally consider this PID subject to be the “deep end of the pool” when it comes to PLC knowledge ... now you’ve already told us that this is something of a “critical” system that you’re working on ... you’re worried about “faulting the system” and so on ... well, here’s some friendly advice ... it might be a good idea to learn how to swim in a less-threatening environment before you try jumping right into the deep end of the pool ... we’ll help where we can, but it’s still your neck that’s on the block ... here’s just a suggestion: do you have (or can you put) a spare PLC-5 on the network (Data Highway Plus or Ethernet) with your existing system? ... if you can, then consider this approach ... suppose that you were to program a simple MSG (Message) instruction to read the existing PLC’s input signal (example: N7:54) and store it into your “spare” PLC ... and suppose that you were to program the “spare” PLC with a PID to use that input signal ... and suppose that once the PID in that “spare” PLC has calculated its output, suppose that you were to program another simple MSG instruction to send that output signal back over the network and into the existing PLC (example: N7:75) ... see where I’m going with this? ... the basic idea is that you could get all of your “getting-started-learning-PID” exercises done with very little (if any) risk of faulting (or otherwise affecting) your existing system ... once you’ve gotten everything nailed down and properly tuned, THEN you could program the final working version into the existing “production” PLC during a scheduled “down-day” at some time in the future ... I know that this approach works because I frequently use it in the lab for my students who want to see a quick demonstration of PID control – but who don’t have time to take the full week-long PID course ... I hope this helps ... I look forward to hearing from you soon ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
WOW What a mouthful Ron. Took me over 15 minutes just to read thru it. I'll have time to attack it in detail the coming nights, but let me say thanks a ton already. I have several "spare" PLC 5's taken out when replaced by ControlLogix so I really like the message idea. May even have it "fall back" to the old logic if the MSG errors or the value sent is out of range. One other thing I should have put in the original post. This system has room temp, Inlet Temp and Outlet Temp sensors. There is an aadditional problem with the coils "freezing" up with ice. I am "toying" with idea of regulating outlet temp around say 35 degrees whenever room temp is outside of a deadband of 50 +/- 2 degrees and regualting outlet temp to 50 degrees when room temp is in deadband. I know this adds complexity and may not be the right direction, I'll work on the PID running off room temp first. Again thanks and I'll get more info soon.

Share this post


Link to post
Share on other sites
One possible solution is to use cascading PID instructions. The Master PID would have the room temperture as it's PV, and the Slave PID would have the outlet temp as it's PV. The Master senses the room temperture and passes a setpoint to the Slave, you could limit the setpoint on the Slave to prevent your freezing problem. I use the cascading arrangement quite often on Chemical Reactor systems, the Master senses contents temperautre, and the Slave controls the temperture of the cooling media.

Share this post


Link to post
Share on other sites
I'll second Ken's suggestion. It is a standard approach for a system with 'indirect' control of the desired end result. i.e. glycol flow affects outlet temp which, in turn, affects room temp. Characteristically, these systems have a fast-acting inner (slave) loop and a slow-acting outer (master) loop. The outlet temp responds quickly to a change in glycol flow, but the room temp responds slowly to a change in outlet temp. The inlet temp can be used as feed forward to the inner loop.

Share this post


Link to post
Share on other sites
Ken your approach sounds interesting. Let me see if I understand the concept as applied to my system. Desrired Room Temp == 50 F Master Loop PID Setpoint == 50 degrees Process Value == Measured Room Temp Control Value == Value between 35 and 50 {is Desired Return Air Temp} Slave PID Loop Setpoint == Value from Master PID Process Value == Measured Return Air Temp Control Value == Value between 0 and 4095 for Glycol Valve Control.

Share this post


Link to post
Share on other sites
The slave PV should be what you previously termed "outlet" temp, i.e. cool air entering the room. If by "Return Air" temp you are referring to what you previously termed "inlet" temp, that's wrong. That could be used as feedforward to the inner (slave) loop.

Share this post


Link to post
Share on other sites
That doesn't fix the problem. If you limit the slave PV then the master will not be controlling room temperature. This freezing up problem must be addressed, it will not be fixed by tricks in software. Perhaps the temperature of the coils need to be increased so they don't freeze. Now one must increase the heat removal by changing the flow of the coolant. One can do this by increasing the velocity through one coil or using two coils. This freezing up problem is an engineering screw up that must be fixed.

Share this post


Link to post
Share on other sites
Peter do I understand that we should be able to run 12 degree glycol through our coils and pass 80 degree air over the coils and not have freezing if they are correctly engineered. The working theory is that regulating glycol flow can keep teh coils at a temp above freezing and prevent moisture in the air from freezing. You post implies the coils may be sized or laid out incorrectly? Can you elaborate?

Share this post


Link to post
Share on other sites
No can do. By design, a PLC-5 faults the first time you insert a PID instruction (it's a "design feature"). You CAN write your own PID equations of course. I had a similar problem recently. Process with a HUGE amount of "inertia". I learned PID tuning in the chemical process industry where typically the loops tend to be almost pure "PI" in form. To control the difficult process I had, I gave up on ever holding close to set point over the short term and settled for stable process as goal #1. So this meant large derivative gain (actually larger than P gain) in order to compensate for process upsets, which an integral gain about 10% of those...just enough to SLOWLY tune out long term stability issues. This is controlling a very large indirect heating oven at 1800-1900 F with a huge amount of thermal mass (12" brick) acting as a radiant heat source. The fact that it never reaches set point suggests that you need to back off on your proportional gain and increase the derivative (this is why your current P-only loop doesn't work well).

Share this post


Link to post
Share on other sites
Not true, you can add PID instruction without problems, while doing online programming. Just be careful. I just did it to a PLC5/11 not 5 min. ago. On a test rack I have. If you have read this somewhere please show me ( I'm from Missouri ). Edited by Mickey

Share this post


Link to post
Share on other sites
This should not happen. When it does you need to defrost the system. A long time ago I wrote software for refrigeration controllers. Ice insulates and reduces the ability to cool

Share this post


Link to post
Share on other sites
That is what happens when the system over reacts because of the system "being slow to respond" and the PID or basic equasion responding too fast or without limitiations.

Share this post


Link to post
Share on other sites
No, that is what happens when there isn't enough surface area to absorb the heat without having a large temperature differential between the room and the cooling coils. From what we have been told there is mositure freezing on the coils. This happens when the coils must be at freezing or below to remove the heat from the room. In this case a large temperature differential between the coils at freezing and the room at 50 degree causes the coils to freeze up. If there were twice the surface area over which to absortb heat then the coolant differential would only need to be half. Therefore the coils could remove the same heat at 40 degrees which would not freeze. Software can not fix all problems. The system must be designed correctly so it is controllable first. This is a heat transfer problem. I don't care how the system is tuned or what algorithm is used to control this system. If the cooling coils must be at freezing or below so there is enough temperature difference to absorb the heat then there will be ice forming on the coils and cooling efficiency will drop. There is moisture in the air that will freeze like frost and eventually build up. Perhaps there is an air conditioner that dried the air before freezing it that isn't working any more. There must be some reason why the engineers thought this would work.

Share this post


Link to post
Share on other sites
Just a quick update to everyone who has been so helpful. The whole reason this loop is being examined it the freezing problem not the temp control issue. Obviously it would be great if a tight temp control loop could be set up so the room was stable +/- 2 degrees, but with the nature and size of upsets that occur when a machine or machines turn on this is probably not supe realistic. I am now working with the RFG Engineer to implement "Defrost" logic and look at coil temp monitoring {keeping the coil surface above 34 degrees} by varying coolant flow under changes in demand.

Share this post


Link to post
Share on other sites
OK, let me see if I have the facts straight... The system has enough cooling capacity to cool the room under max load. It's not a case of under capacity in the coil, right? For example, if you control the valve manually and keep it from opening too far, you can get the room cold without freezing the coil. If you can't, Peter is right and software won't help. However, if you can control it manually, then you may just have more glycol flow available than you need. Your glycol valve may be oversized. However, as long as the valve uses enough of its range so that you have decent resolution, it may not need to be replaced. If this is the case, then you can fix it with software. If the incoming air was always the same temperature, then a simple output limit would work. However, I don't recommend it and I think the cascade approach is a good one. Set the inner loop so that the delivered air won't go below a minimum temp (setpoint limit). You don't really want the delivered air coming into the room to be freezing anyway. You should be able to maintain 50F in the room with air at 35F or higher. If you can't, you need to increase the airflow. Introducing really cold air is just going to make the room temp more uneven. The problem with the original control is that it allowed the glycol valve to continue to open until the coil iced. Once this point is crossed, it would continue to open the valve until it reached 100% which is actually reducing the cooling. Therefore, it's stuck until someone shuts it off or the room gets cold on its own. I think if you can get this running with a reasonable setting on the delivered air, your icing problems will go away. Or, you will find out that your cooling system is inadequate and needs to be improved. If you have to set the delivered air temp real close to freezing the coil, you've got capacity issues. One last thing... I'm betting you did this, but don't forget to check the air filters, seriously reduced air flow can ice a coil too. Back to your original problem, feed forward into the bias on the room temp control loop should help your response to major equipment starting up. If you come up with a bias number for each major heat load and push the total into the bias, that should work. The difference in the output of the loop when it is in steady state without the heat load and with the heat load is how I would suggest determining the bias numbers. Good luck, Edited by mellis

Share this post


Link to post
Share on other sites
Hope to get some time to play with this tonight. Before I do I need to publish a bit of news. 1. Discovered this week that the Control Valve is stuck and not adjusting and will need to be replaced. 2. The RFG Engineer has requested that the air speed setting be held on high at all times. 3. For those learning like I am I'm documenting my thought process and trial and error to help others "I hope" Output bias is zero for thie starter tests, but will be fed from an integer N11:215 which changes based on room/machine running status That's the plan -- In a day or two I'll post the luck or lack therof. P.S. - Tonight is a non - production night so I can fault the processor without risk for those that watch the details.

Share this post


Link to post
Share on other sites
Well I erred on the side of caution and used an "offline" processor to implement my first PLC 5 PID and so far it is looking promising. I'll leave my test program for you guru's to debunk. Trainer_PLC5.zip We need to replace the Glycol Control Valve before I can debug this code. Doen's look like it faults the PLC though which is good.

Share this post


Link to post
Share on other sites
You may want to use the PID output bias for feedforward when a major piece of equipment is started.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0