Ok the way things turned out, i found out that there was a little known problem with the PID algorithms in versions previous to 9.5…if you were having an impossible time, trying to tune your PIDs, this would be why. On a previous Oven in 2013, I was going stir crazy trying to get the PID to work. On that oven I created a table that retuned the loop every 10 degrees of the ramp and finally, after a massive number of attempts, got it to hold +/_ <0.5 degF all the way up ramps from 100 to 360 degF. Man was that painful.
On this oven, about half way through this, Josh found out that the bug existed and then I used the correct PID and managed to get it to hold the same level of control all the way up the ramp using just one tune. Gee, when the PID works correctly it works just like in the movies.
The ramp I use is required by spec, so I generate the set point based on dividing the total ramp temp by the time required for a 5 deg/min ramp rate.
One interesting caveat here is that instead of using the actual lag time of the process of 18 seconds, I found that with respect to the ramp, the lag time is probably associated with the time between set point changes, in the case probably about 1 second. I set the scan time to 0.5 and 1 second and found that these worked perfectly even though the actual process response time is 18 seconds, and that’s because the controller is updating the set point much faster than this based on the ramp slope. In order for a PID to keep up with the changes in set point, the scan time has to be related to that and not the process reaction time.
Another thing that did not occur to me at the time, was that this oven versus the earlier one, has the wrong kind of burner for this application. The burner is a Immersojet, meaning that it’s designed to heat water, not air therefore the heat exchanger creates even more lag time versus a direct fired burner.