Rapid on / off when approaching set point

Describe your system and processes, and post your config file.
todd
Posts: 26
Joined: Sun Oct 16, 2011 10:03 am
Bot?: No
Location: Pig's Eye, MN

Re: Rapid on / off when approaching set point

Post by todd »

Why can't we just have the gas valve turn off and not cycle? Todd
User avatar
ECC
Posts: 676
Joined: Fri Sep 12, 2008 12:29 pm
Bot?: No
Contact:

Re: Rapid on / off when approaching set point

Post by ECC »

You can! Use Hysteresis control. When it hits the setpoint, it will shut off. if the temp drops below setpoint (minus the programmable hyst range) it will turn back on.

PID control by definition aims to cut the magnitude of the output as you approach the setpoint to give a finer granularity of control. It does this by reducing PWM of the output, which works great for electric elements and SSRs. But not as well if you don't want to listen to gas valves turning on/off continuously. Hysteresis control is probably a better fit for gas systems.

What PWM is to electric rigs, proportional valves are to gas. But that's a whole different discussion... While it is possible to still use PID control and on/off valves and 'slow down' the switching... All that you would really be doing is making the PID controller less responsive (opposite of "finer granularity of control"). So don't use PID just to say that you're using PID, if the system is really setup better for Hysteresis control.
clearwaterbrewer
Posts: 383
Joined: Wed Feb 09, 2011 3:43 pm
Bot?: No
Location: Clearwater, FL
Contact:

Re: Rapid on / off when approaching set point

Post by clearwaterbrewer »

so someone needs to find/make a PID to variable gas flow valve...

no pulses from BCS, valve is closed... each pulse opens a valve a little bit, longer duration pulses open valve further... shorter or no pulses, valve closes...

or just have 2-stage burner with hysteresis control on both or just the high power portion and be done with it...
armous
Posts: 1
Joined: Thu Mar 26, 2015 8:50 am
Bot?: No

Re: Rapid on / off when approaching set point

Post by armous »

On this post there was an explanation of the PID sample and output cycle periods which still confuse me (when set to be unequal). The explanation of the PID period being longer than the output period makes sense, as described. What is the behavior when this is reversed and the sample period is smaller than the output period? For example what if you had a 30 minute output period with a min pulse of 20%, max pulse of 80% (6-24 minutes run time out of 30); then you set the PID sample period to be 10 minutes. The PID will sample 3 times during each output period potentially needing the system to be on or off. How does the algorithm decide if the the output period limits are being met when the sample is repeatedly changing during the same time.

I have a separate issue controlling a refrigerator which might be related to the prior issue. I've setup to control via PID (P only at 20 for simplicity). The PID period and the output period are both 30 minutes. The min and max pulse is 20% and 80%. I don't want the compressor to run unless it runs for at least 6 minutes and I don't want it to run more than 24 minutes continuously in a 30 minute cycle. This works fine and in most cases I get one 30 minute cycle with about 8 minutes of cooling then the PID drops below 20% and I get a 30 minute cycle without any cooling. After the 30 minutes without cooling the temperature is above a point where the next cycle will cool again. This holds a steady beer temp of about 50F with about one "on" period of about 8 minutes every hour (one cycle with cooling, the second cycle without). I've noticed that when the "dead" cycle of 30 minutes with no compressor (below min pulse) the compressor still turns on very briefly at the very beginning of the cycle, not more than 1 second. It's almost as if the PID sample is taken right at the beginning of the output cycle and it takes a few milliseconds for the processor to recognize it is below the min pulse, but during that time it defaults to being in the on state before it figures it out and shuts it down. I would like to prevent this behavior as it causes unnecessary wear and tear.

Lastly, is there a guarantee of contiguous operation during the output period? Or does the algorithm have flexibility to cycle as needed as long as it doesn't violate the % time during that cycle?
Post Reply