PID state machine problem

[Arctic_Fox]

Hi.

I have a problem with my state machine design and I need help figuring out what to do.

I´m using a six step state machine for testing HVAC machines. It goes Password->Idle->Run->Acquire->Report->Shut down. Run and Acquire states have PID controls in them (almost identical states) and they´re controlling very fast three-way-valves for mixing desired water temperatures. In Run-state I´m trying to get static values for the temperatures and when I´m satisfied with them, moving to Acquire state for getting data to the report. My problem is that when switching from Run to Acquire, PID control outputs start from zero and at that point static temperatures are gone. Worst case scenario is that the tested HVAC-machine shuts down because of the wrong temperature liquids and I have start from the beginning.

Is there a way of telling the PID.vi to start the output from a specific value? In this case, continue from the last value that they were outputting in the Run state?

I know that gain scheluding would do the trick(machines would not shut down) but I don´t want use that because the original problem would still be there.    

[GerdW]

Hi Fox,

what about using a parallel loop for your "Acquire" state?

That way you can have the "Run" state active in your main loop and it controls the "Acquire" state in your second loop by some locals/notifiers/whatever...

[nathand]

---

@Arctic_Fox wrote:

Is there a way of telling the PID.vi to start the output from a specific value? In this case, continue from the last value that they were outputting in the Run state?

---

The correct way to do this is to put the PID in parallel with your state machine, so that you're using the same PID regardless of which case the state machine is in, as GerdW suggests.

However, there is a way to start the PID from a specific value.  Use PID Advanced, which has a "manual control" input.  On the first loop cycle after change states, set the manual control value to the previous output, and set the Auto? input to False.  That will initialize the output.  In the following loop cycles, set the Auto? input to false so the PID will continue running normally from that state.

Be careful using multiple instances of the PID VI to control the same parameter.  Each will maintain an independent integrator, and switching between them might lead to unexpected jumps.  If you insist on doing it this way, make sure you reinitialize the integrators (the reinitialize? input) each time you switch.  I usually set the reinitialize? input to the inverse of the auto? input unless there's a specific reason not to do so.

[Arctic_Fox]

Thanks for advice.

I¨m thinking of trying go with the advanced PID for now but I would like to know more about the parallel loops.

I´m not quite sure how to use parallel loops with the state machine and how to switch states... Could you give me an example?

My first solution that I thinked for this problem was that I could remove the 10 PID-controllers from the Run- and Acquire-states and place them outside the state machine. My state machine is inside a while-loop and this would make those PID:s active all the time but I allready have swiches for manual- and off-states for the PID:s so it would not matter.

So removing PID vi:s from the state machine, placing them inside the while-loop that surrounds the state machine and leaving all the necessary write DAQmx-functions inside the Run and Acquire-states would make them do corrections on valve positions only on those two states. Right?

[nathand · Accepted solution]

---

Arctic_Fox wrote:

So removing PID vi:s from the state machine, placing them inside the while-loop that surrounds the state machine and leaving all the necessary write DAQmx-functions inside the Run and Acquire-states would make them do corrections on valve positions only on those two states. Right?

---

That's the right idea.  I'd leave the DAQmx functions outside the state machine as well.  If you need to write a fixed value to the outputs when the PID isn't running, use the PID on/off switch that you already have to determine what value to write (PID output or something else).  Also, I'd make sure the PID reset input is true whenever the PID is not running.