Hello DeltaV community!
I teach students DeltaV and we often run into a problem with Control Studio and undo.
If you use ctrl-Z (undo) after making a change to a PID1 block parameter, all 'associations' with the PID block are lost - that is, alarms lose their connection to the alarm parameters (e.g. HI_HI_ACT, etc) and any History Collection points being read from the PID block are deleted. It's almost as if undo deletes the PID block then pastes in a new block, reconnects the connectors, and sets the parameters and block name to what was previously there. It successfully un-does the last change, but there is collateral damage.
My students don't realize there's a problem until they go to download and Duncan informs them all their alarms are not associated with a parameter. The module is saved before the download is attempted, so they are stuck with the disconnections.
To reconnect the alarms, I have created a custom .fmt import-format file and import the pid_loop alarm parameter defaults - it’s a clunky recovery (and only reconnects the parameter and alarm message parameters, not the conveniently displayed limit value, although the limits work).
Is there a better solution to ‘reconnect’ the alarms back to the way they look in the module template?
I can provide screenshots if I’m not being clear.
Many thanks,
Chris
I'm not sure what version you are using but for v13.3 and v13.3.1 this behavour is listed as known issue TFS227316 in the release notes NK-1600-0334 or NK-1500-0151. It seems to affect any function block where an alarm is assigned to a parameter, not just PID. The full description is below. However the Prevention procedure doesn't seem to work for me. Even if I save, close and reopen after assigning an alarm, the issue still occurs when I change a parameter and then undo.