B3000 Mistic PID loop infor

I am trying to understand the PID loop configuration variables as described in the MISTIC PROTOCOL USER’S GUIDE, Form 270-100823 — August, 2010. In particular the:

“I = Integral reset constant term in repeats per minute. Default is 0.0 repeats per minute.”
“D = Derivative rate constant term in minutes. Default is 0.0 repeats per minute.”

If I set these values to 0, are P and D and turned off?

The users guide says, “This velocity algorithm is inherently “anti-wind-up” since it has no summation in the integral term to saturate”. The equation indicates the integral is based on the error from most recent sample.

If this is true, why would the integral need to be reset at regular intervals?

I don’t know the specifics for the mistic PIDs.

If you set the I term to 0, then the I term will have no affect on the output, same with the D term.

You may be confused on the terminology. On a PID loop, the I term is commonly called the “reset”. The term itself isn’t reset, but the output of the PID is adjusted to remove the offset error.

The difference between the velocity and the ISA algorithm is that the velocity algorithm calculates how much to change the output while the ISA calculates the output itself. Mathematically they are the same, functionally they have different characteristics. I like the velocity algorithm for the fact that I can manually change the output and the algorithm will take over from there. Downside to the velocity algorithm on Opto equipment is that the feed forward isn’t really usable.

The user guide says that the velocity algorithm is inherently “anit-wind up”. This is true in one way, and false in the way that matters (see below). The statement implies that the other algorithms have some sort of wind up issue, but they don’t, as they have wind up protection programmed into them (the I term will no longer “sum” when the output reaches saturation). There are very few controllers that omit wind up protection (I’m looking at you Honeywell).

However, the PID will still have wind up issues if your output range is large while your actual device control range is small. For example, if you have a temperature control valve that is oversized and has a control range between 0% and 30%, and for some reason you lose flow - the PID will happily increase the output until the control valve reaches 100%. When flow starts up again, you will have excessive overshoot while the output “unwinds” back down below 30%. This can happen no matter which control algorithm you choose (velocity is not immune to this).

Thanks for the response. I am writing Python code in Linux to talk to the B3000 in Mistic mode. I am testing the PID commands by sending random values to a setpoint and monitoring an output module with a scope to see how changing PID loop parameters changes the response to the setpoint changes, mainly to see that I am in fact sending the right command for each parameter.

I’ve written a number of PIDish control loops in firmware, that is I rolled my own. I always limited windup by limiting integral growth so that the pid equation could never make the drive DAC exceed FS or go below ZS. So for a step change, the P and D terms would contribute more at first and my integral term windup would therefore be delayed by the fact that it made no sense to add drive bits to the integral than the DAC couldn’t use anyway.

It’s been several years, but I’ve moved from Python to Lisp for grins. If I send a command to read all PID loop parameters using the Mistic guide, the B3000 seems to reset without responding and the next command returns a powerupreset required error. I monitor my request packet and it it looks fine. I have not had an issue so far with any other command failing in like fashion. If I ask for a single pid parameter, it works fine. I’m guessing there is an issue with the firmware as reading all parameters takes a pretty good chunk of return data. No big deal as I can always create a command to read one or more parameters by sending requests for single parameters.

Also, I do not see a command to read the firmware version in Mistic equivalent to the one for Optomux. Is there one I am missing?