Mistic PID issues? Gain reversed than expected

I am having an issue with Heater outputs being reversed; I think I found a solution but am confused on why it became a problem in the first place, if someone else out there is still working with Mistic hardware…

I will try to summarize:

  • Plant was run in 2013 with no issues on Pac Control Professional v9.1a.
    Based on all documentation and from what I can tell looking at the strategy: gains were positive. This tracks with the command help window for “SetMisticPidPterm” where negative gains are typically used for cooling applications (we are heating).

  • Plant is trying to start in 2024 on PAC Control Pro v10.5b.
    When I try to turn on a heater, with a host setpoint higher than the I/O point analog input value, the heater won’t turn on (output stays at 4mA), but when I set the setpoint lower, it shoots up to 20mA. After investigating and putting in a negative gain value, the heater(s) work as expected.

Was there a change between the PAC Projects 9 & 10 that would cause this? Or am I missing something else? I don’t really want to change all my initialized gain values without fully understanding what went wrong / what changed.

Oh, and unfortunately, to complicate things, we are running the strategy on a SNAP-PAC-S2 r10.0h control engine but I have NO idea if this was installed pre- or post- 2013… If that was installed after, would that change how the strategy looks at PIDs?? The pop-ups for “Edit PID Loop” still look Mistic-y and not like the SNAP or EPIC PIDs (as in, I cannot view/change the algorithm or anything).

Thank you!

That’s a tough one… I totally get your concern and while I have four thoughts, sadly none of them are black and white…

  1. I downloaded the PAC Control readme: https://documents.opto22.com/RM_PAC_PROJ.pdf
    Did a search for a few key terms and found some ‘mabeys’, but nothing really solid. (See point 4).
  2. I download the SNAP Controller firmware readme: https://documents.opto22.com/RM_SNAP_PAC_FW.pdf
    Did a search for a few key terms and found some ‘mabeys’, but nothing really solid. (See point 4)
  3. I wonder if some persistent variables got mixed up or not backed up / restored in the controller firmware update.
  4. Both the PAC Control updates and PAC Controller firmware updates did make some key changes around the PID loops when we found that the calculation was not done correctly. Since many folks would be impacted by this update/fix we kept the old loop formulas in play and marked them as Obsolete.


It should not have caused what you described (i.e., P, I, D, and scan rate values are correct, just the sign is flipped on the P term), it’s close enough that it makes me pause and go ‘hmm.’

That’s where I got a bit confused on the readme files & some other forum posts- they all have screenshots that look like yours; but this is what my “edit PID loop” options pop-ups look like

They don’t have the option to change the algorithm at all, I’ve just been assuming it’s the “anti-wind up velocity algorithm implemented in the form of the difference equation” based off a copy of the Mistic User Guide from 2010 I was given. I don’t know if it’s because of the hardware type we have - it could be that much older?
mistic card io unit edit popup

Also, in regards to your Point 3: there are Gain, Integral, and Derivative values for each PID stored as persistent numeric variables. They were definitely lost as the entire system was shut down for ~11 years, and no one gave me a restore file at all… however, they still have those P, I, D terms in the window that have been written to all the num vars anyways? It’s not my code but there are blocks using “getMisticPidXTerm” and then later uses “setmisticPIDXterm”.

Okay, so gain doesn’t really seem to be the source of my issue after all; it’s that the setpoints keep flicking to zero briefly but constantly?

"Set I/O Unit Configured Flag" - #2 by nick_stephens → I’m not sure this really applies to us because all the PIDs do use I/O points and not host as the input, but I tried it anyways and un-clicked the “enabled communications” to the Mistic and instead used the Command “enable comms to I/O UNITS”, but still getting the same issue.

Then I tried a good ol’ power down and power up on the controller, and now in PacDisplay when I tried to change a setpoint I’m getting the error for a Server :=> AsyncWrite fail 0xc0040502 but the only KB article that comes up has to do with recipe files which I double checked and don’t have any. And also it’s only for about half of the setpoints, the other half seem fine, and from what I can tell there isn’t any differences, but when I look at the points in debug mode for some of them I get this:

Wow, there are some cascading errors here. I think it’s time to hit up support and peel back the layers.

Regarding Nicks’s ‘set I/O configured flag,’ that was my tip for doing bumpless downloads.
Without that, the PID loop restarts after each download, and you can get a blip from the first few PID calculations.
Your ‘enable coms’ is sort of making things worse as the enable comms forces a restart after each download.
So, back out your change, and I don’t think either is the root cause of your issue.

The error you are getting now about ‘definition unknown’ is caused by a version mismatch between PAC Control (where the defs are stored) and the I/O / Controller firmware (where the defined commands are executed).
Support will be able to help guide you on versions for each better.

Edit. The setpoint jumping around is because (I strongly suspect, but can’t know for sure) you have chart(s) that are writing different values.
Do a PAC Control search for the PID loop name and see how many places it is referenced and what each reference is doing. You may have to put some debug type variables in to see whos writing to the PID and why.

Yes the first thing I checked was searching for the PID loop tag and all even all the Mistic PID instructions, and couldn’t find anything that would be overwriting.
And for the version mismatch, it was the latest firmware & pac project pro.
Turns out, it was likely the “enable runtime operator logging”; that was one of the biggest changes I had made and un-checking that seems to have fixed all my problems?!