PID help

[BobO]

As much as I wanted to use real-world values for SP, PV, etc., there are a few factors that make that less than ideal in the PID. The PID was built with 0-100% being more the range it wants to work with. Scale your real-world values to this range and the PID works so much more betterer.

You CAN use your real-world values instead, but some things will work less than ideally, especially with Autotune. The P, I and D terms have had a limit on decimal places when reading and writing these values from the interface buttons. This may have changed since I reported it, I just don't recall. (It does look like there are more decimal places now, cool.)

See https://forum.hosteng.com/index.php/topic,1787.msg15129.html#msg15129 on the resolution change.

Strictly speaking, the only part that is actually 0-100% is the output. I guess that leaks back into the other terms, but for auto tune, I would think it works out as part of the tuning process. I'm honestly not a process guy though, so my opinions aren't super relevant.

I guess the alternative would be to force you to define what 0-100% is in real terms. In a sense we are already doing that by putting the scale into the box, so maybe that wouldn't have been a big deal. We could probably look at doing a mode that uses the output scale parameters as the output bounds. I think that would let you use real units throughout. We only care for auto tune and bias freeze/output clamping.

And this is exactly why we spend as much time on the forum as we do. 

[PLCGuy]

going to check it out. Why is the PV value so low compared to my input value. I was thinking the PV is the current value of NO which is 74 degrees.

[BobO]

going to check it out. Why is the PV value so low compared to my input value. I was thinking the PV is the current value of NO which is 74 degrees.

The .PV is a field in the structure, and comes from you directly, or if you have enabled Scale to .PV option in the box, it comes indirectly from the source variable you specified.

You really need to walk through this: http://www.hosteng.com/FAQFiles/Do-more.htm#FAQ0041

[PLCGuy]

I walked through the thread, nice. I guess what i am seeing is PV is being calculated by the scaling. In my mind, using a temp controller, the operator enters the temp they want to achieve, ie, 400 degrees. In the other window they see the PV changing as the heater heats up. they see the setpoint and pv the same and the temp controller shuts off. But in DM they enter 400 and see the pv at some funky number. I do not want that. that would be confusing to the programmer if he had to look into the program. So what I did was entered 32 and 1330 for both scales and now pv matches the input by me. I only tried this at home, will try it when I get to work on the actual oven. 32 and 1330 is the range of the thermocouple. Maybe i do not need to scale, by the PID does not allow that. the only way to assign input is to click on the scale so I can enter N0. I do not see a way to tell the PID to use N0 or any memory for input unless clicking on scaling.

[BobO]

The input to the PID function is the .PV member of the PID structure. You can set it anywhere you like.

[BobO]

You can also use the .PV member instead of N0. No need to use another variable.

[BobO]

Maybe this would be a good time to back up and talk about design philosophy. I think users sometimes have a mental image that prevents them from seeing the forest for the trees. Maybe I can help.

We could have built a PID box that had an input parameter for every single value used: PV, SP, Output, Gain, Rate, Reset, etc...and that might actually be easier to grasp, but it isn't super convenient. What we realized though was that since we already needed to allocate some work space for internal loop variables, we could expand the structure to include every input and output variable for the entire loop. So instead of creating 20 different tags, you just create one. And it really becomes self documenting.

Let's say you need a loop to control a tank temperature, so you create a loop tag called TankTemp. So rather than documenting 20 different tags, it's one and done. PV? TankTemp.PV. SP? TankTemp.SP. Gain? TankTemp.Gain. Etc. Those variable can be referenced throughout the program like V10 or N7 or R15...they are no different. There is no real benefit to using N7 to reference the PV and then copy into TankTemp.PV.

Maybe you don't like the name of a field. Let's say that the loop output is actually driving the tank's burner, and you don't like TankTemp.Output. No problem. Individual structure fields can have their own nickname, so you can assign TankBurner as the nickname for TankTemp.Output.

Since we realized that in some cases, your PV and Output would be directly tied to their respective analog channels, we added the scale options to simplify the hookup. They aren't required, just there for convenience.

The decision to use 0-100% for the output was also intended to simplify. We don't know what your physical output is: bang bang, PWM, 12 bit analog, 16 bit analog, scaled engineering units...we don't care, it's all 0-100%. And in reality, it is. Somewhere between fully off and fully on. By using a normalized output, we didn't need the loop to have more knowledge when auto tuning. One less thing to get wrong.

While it may be different than other products, our intention was to simplify. Sadly, I think we did the opposite, at least at first. But once you understand, you can create a brand new loop, wire it to the associated I/O, and auto-tune it in a couple of minutes. With other implementations you'd still be creating tags.

[Controls Guy]

Nice explanation. And I think, also the right direction to go philosophically.

[PLCGuy]

Wow, the forest doesn't seem so scary now. That all makes sense. I never thought about accessing .pv directly.  Actually mine would be called Zone1_PID.PV. That makes more sense if someone gets into the program to read it. Turns out I might not need the scaling. At least that works in the SIM. I will check it out Monday in the real oven we are building.

Sometimes brainiacs create things, thinking okay, that is easy. But not so obvious to a person other then me. It is all clear in my head but to a novice , it is not. What i generally do after building a machine is get a couple operators and say, okay go for it. Amazing what I thought was quite obvious  easy, is not. I have to make changes to the hidden gems. Which is not bad, heck i created it, I know what it means.

I really like the view Host takes on these matters. AB would never do that.

[Mike Nash]

...

Since we realized that in some cases, your PV and Output would be directly tied to their respective analog channels, we added the scale options to simplify the hookup. They aren't required, just there for convenience.

The decision to use 0-100% for the output was also intended to simplify. We don't know what your physical output is: bang bang, PWM, 12 bit analog, 16 bit analog, scaled engineering units...we don't care, it's all 0-100%. And in reality, it is. Somewhere between fully off and fully on. By using a normalized output, we didn't need the loop to have more knowledge when auto tuning. One less thing to get wrong.

...

There is one area that would be nice to have covered within the PID instruction for the case where a bipolar output is required. We can modify or scale the PID.Output either outside the instruction or scale it and stuff it elsewhere from within the instruction and these options are fine. The bipolar-ness is only lacking in having the output reset to that bipolarised zero when the instruction input is false.

It works fine to scale the output to -whatever to +whatever, but it does require a MOVE or MATH or something to force the PID.Output to that "imaginary" zero point if the instruction needs to be reset (off). The Invert Powerflow and a MOVE works well, but I would like to see the PID instruction be truly bipolar where zero is output if the PID input leg is false. This would allow non-symmetric scaling when needed.

[PLCGuy]

Success! Just giving an update to using the PID. I take my thermocouple reading, no decimals, load into PID_O1Z1.PV and load the setpoint into PID_O1Z1.SP.  In my PID box, no scaling. Press Auto-Tune and off it goes. Takes awhile doing heaters because of such a swing, but when done, I loaded the calculated to the plc. Guys are amazed how the PID hold the temp within a couple degrees plus and minus. I take the PID_O1Z1.OUTPUT and feed that into the TIMEPROP to control the SSR. I did find I needed to bumb up the time to 2 seconds in the TIMEPROP box.

Bobo that explanation you gave did the trick.  The operator sees real live numbers. PV being the thermocouple temp. They just enter from the HMI the temperature they want to achieve and off it goes. Very nice. You can watch the PV rise as it reaches the SetPoint temp. No fudging required.