PID Forward/Reverse acting bit

[davidbgtx]

Is there some bit to change the PID from forward to reverse acting, like PID.act or something?

[franji1]

It's part of the PID instruction itself.

[davidbgtx]

Yes I see it in the PID instruction. I have a need to change the PID instruction from forward to reverse acting depending upon whether which direction the machine is running. I was hoping to just move a 1 or 0 to some address like you do with Gain for instance, since all the other parameters remain the same when I reverse direction. I guess I'll need 2 PID instructions then?

[franji1]

If you are needing to do it while in AUTO mode, could you just negate the .Gain?

If you can do it in manual mode, probably best to have 2 PID instructions with 2 different PID structures, but then have the specific PID structure's .Output drive the real world output based on which loop needs to "actively" control the process.

[davidbgtx]

Never thought about negating Gain. I can do 2 PID's , I'm just lazy. Thanks for your help

[Controls Guy]

Still be nice to be able to write directly to anything in the structure, though.

[davidbgtx]

The wish list never ends, and I'm glad!

[franji1]

Still be nice to be able to write directly to anything in the structure, though.

Like this?

MATH MyLoop.Gain "-MyLoop.Gain"

[Controls Guy]

Can you write to MyLoop.Direction or .ReverseActing or whatever the member is called?  I interpreted the other posts to indicate that you could not.

[franji1]

Can you write to MyLoop.Direction or .ReverseActing or whatever the member is called?  I interpreted the other posts to indicate that you could not.

There is no such structure member.  That flag is a parameter in the instruction, not in the structure.

Similar with the Algorithm (Position vs. Velocity) Initialization Mode, Error Squared, etc.  Those are flag parameters in the instruction - they are not flags in the structure.

[Controls Guy]

Can you write to MyLoop.Direction or .ReverseActing or whatever the member is called?  I interpreted the other posts to indicate that you could not.

There is no such structure member.  That flag is a parameter in the instruction, not in the structure.

Similar with the Algorithm (Position vs. Velocity) Initialization Mode, Error Squared, etc.  Those are flag parameters in the instruction - they are not flags in the structure.

Hmmmm.  Not liking that very much at all.

Update:  OK, looking at the instruction, the stuff that's set there is well chosen, i.e. it's stuff that in 99.99% of all PID applications will never change at runtime.  Still, why not make EVERYTHING a struct member and just use the PID instruction as a faceplate to those members?  Then if you want to write to them you can.

In DL-Classic and AB, all loop config settings are stored in known, documented locations and changeable at runtime (and I do).

[BobO]

Update:  OK, looking at the instruction, the stuff that's set there is well chosen, i.e. it's stuff that in 99.99% of all PID applications will never change at runtime.  Still, why not make EVERYTHING a struct member and just use the PID instruction as a faceplate to those members?  Then if you want to write to them you can.

In DL-Classic and AB, all loop config settings are stored in known, documented locations and changeable at runtime (and I do).

At this point it's academic. We're not going to make changes that affect existing apps.

It's the same argument for SysConfig vs Instruction as Instruction vs Image Register. Stuff set in the SysConfig has a very well-defined lifespan, as does stuff hardcoded in the Instruction. When you make things fully data driven (Image Register), the lifespan is just the current scan, which means you have to deal with every possible change to the data. That greatly increases potential for fail, particularly in code that has persistent state over multiple scans. The stuff we put into the instruction was stuff that we viewed more like I/O config...not dynamically changing and tied to physical characteristics of the system.

[Garyhlucas]

You guys made PID so easy to tune I no longer think twice about using them!  We have multiple blowers on VFDs to a common header it was way easier to add a second PID loop for when two are running than to try and get one loop to control well

[davidbgtx]

If you are needing to do it while in AUTO mode, could you just negate the .Gain?

If you can do it in manual mode, probably best to have 2 PID instructions with 2 different PID structures, but then have the specific PID structure's .Output drive the real world output based on which loop needs to "actively" control the process.

Since my PID output range is from 6000 to -6000 (60hz), I just multiply the PID output by -1 when I change directions. Too simple, guess that's why I didn't think of it at first. Thanks