Hello everyone,
I have a PID loop, that has a FF AO block, and I need to perform a download of this module without moving the Valve.
My plan is to put the PID loop in Manual Mode, and then perform the download, but I don't now if this will assure that the valve wont move.
Another idea that I have is to put that AO block on manual mode, and then perform the download.
Please let me know your comments, and the best way to achieve this.
Thanks,
AVQQ
Alejandro,
A few other details of your configuration might help, but it sounds like you have a controller-resident PID block.
Is your positioner a later-model Fisher DVC6200? Even the older generation DVC5000's default behavior was to "hold last position" on a communications interruption. During the download, your PID will be "OOS" for a scan or more and so I'm thinking no updates to the positioner.
When it starts executing again, the PID will initialize to whatever the "BKCAL_OUT" is fed back from the AO block. For those where we have checked "use PV for BKCAL_OUT", we sometimes see a slight bump as the valve position may not precisely track the AO setpoint. When you have the PID in MAN I would type a small change so that "Yellow Pages" (?) records it & the download includes the precise output from before . . .
For some added comfort, if your configuration allows, you can take the AO block in "AUTO" using Control Studio. We rarely do this, but in that case the disposition of the PID should have no effect on it. The PID will go to "IMAN" but you can leave your target mode as MAN. Once the download is complete, set the AO mode back to CAS.
One caveat - if the "download check" lists the AO block (or any device-resident block) as one to be downloaded, I would "uncheck" it (this is in the dialog that appears during the download). I think DeltaV does this because the "Yellow Pages" have recorded some online changes i.e. tuning. The FF devices will remember those changes without being re-downloaded, unlike the controller which may revert to database tuning parameters et al. We ONLY download device resident blocks when we know we are making a deliberate device, configuration, or schedule change (for example, a device replacement with a later version will update the schedule to utilize faster blocks).
Another thing comes to mind - some obsessive types program the parameter "Fault State to Value" (check under IO_OPTS) which overrides the default "hold last value" behavior. On loss of communication for a period that exceeds "FSTATE_TIME" (in seconds) the positioner will go to the setpoint specified in "FSTATE_VALUE". You would think this behavior would be suppressed during a module download but I've never tested it. If you see that "Fault State to Value" is checked in IO_OPTS then I would just set FSTATE_TIME to a large number (temporarily) like 300 or 600 (seconds).
Of course the least risk is to take the loop on (physical) bypass, if available (with a manual bypass valve). That way you can test all these scenarios and reassure yourself that the devices behave in a robust fashion.
Please let us know how it goes . . .
-JR
In reply to John Rezabek: