The document discusses using a PCSD dynamo to represent the states of solenoid valves in DeltaV. Each valve has three states - open, failed to open, and failed to close. The author is unsure how to represent all three states with a single dynamo. Matt Stoner suggests creating a custom module using a DC or EDC block to track the open/close state, and configuring alarms to track the failed states. He also recommends removing unnecessary parameters from the custom module to reduce loading.
The document discusses using a PCSD dynamo to represent the states of solenoid valves in DeltaV. Each valve has three states - open, failed to open, and failed to close. The author is unsure how to represent all three states with a single dynamo. Matt Stoner suggests creating a custom module using a DC or EDC block to track the open/close state, and configuring alarms to track the failed states. He also recommends removing unnecessary parameters from the custom module to reduce loading.
The document discusses using a PCSD dynamo to represent the states of solenoid valves in DeltaV. Each valve has three states - open, failed to open, and failed to close. The author is unsure how to represent all three states with a single dynamo. Matt Stoner suggests creating a custom module using a DC or EDC block to track the open/close state, and configuring alarms to track the failed states. He also recommends removing unnecessary parameters from the custom module to reduce loading.
The document discusses using a PCSD dynamo to represent the states of solenoid valves in DeltaV. Each valve has three states - open, failed to open, and failed to close. The author is unsure how to represent all three states with a single dynamo. Matt Stoner suggests creating a custom module using a DC or EDC block to track the open/close state, and configuring alarms to track the failed states. He also recommends removing unnecessary parameters from the custom module to reduce loading.
I am using VIMII to pass datasets from a third-party PLC to DeltaV via the Modbus TCP/IP. Each of the many solenoid valves with their limit switches has three states - passed as three bits: open/closed, failed to open, and failed to close. Each bit is configured as a class-based DI_SOFT_52 DeltaV PCSD module.
Now, I would like to add the valve dynamo on the process graphic, but am uneasy about which dynamo would accomplish the task. When selecting an available dynamo from the library, I can only specify one path/name, i.e. the DI_SOFT_52 module for the open/closed state. I am contemplating stacking three dynamos on top of each other and configuring each of the three animations in such way that only the active state would be visible. However, that seems crude. Can anyone suggest a more elegant solution to this?
dmitriy sagadiev
• 16 Apr 2018 4:48 PM
11 Replies • Matt Stoner
o 16 Apr 2018 8:14 PM
I would suggest (EDC if v13):
o Use the Open/Close bit to configure a custom module using DC/EDC block module and then just use the valve dynamo. You can start with a class/template you already are using when creating new module but I would recommend removing the items that won't be required (Modelock, Interlocks, Permissives, etc) Leave the DC_CTRL if you are using VLV_52 module and enable SP Track option on this composite o Could use the failed to open/close bits to do alarming on the custom module if those bits become true (Alarms Name and Priority appropriately set for operator if operator should respond). o Configure the DC/EDC TRK_IN_D parameter to be True with status of GoodNonCascade (Actual Mode will be LO always). o If using DC block, Enable SP Track on the DC/DEVICE_OPTS and ensure CAS_IN_D has status as GoodNonCascade configured or something setting via wire o If using EDC block, Enable SP Track on Tracking and CAS SP Track on the EDC/DEVICE_OPTS o Configure the DC/EDC block mode to only have CAS.
Otherwise you will have to do like you indicated or create a custom dynamo for your inputs (which scares most people to death :D).
• dmitriy sagadiev
o 16 Apr 2018 9:12 PM
In reply to Matt Stoner:
Thank you Matt. The version in use is 11.3.1. Is the EDC block module backwards compatible and/or available in the older DeltaV systems? If not, it sounds like I could use the DC block from the DI_SOFT_52. Given that PCSD is a template based library, I am uneasy about removing parameters (modelock, etc.) from the class-based module. I've seen what the effect of changing one class-based module has on the rest of the control network. Should the module be converted to classless?
• Matt Stoner o 17 Apr 2018 12:17 AM
In reply to dmitriy sagadiev:
No the EDC block is only v13 onwards.
I would either create a class just for these or convert to classless. It sounded like you had a fair number of these so I would go class based with a new class that is based on one you use now. Open the class and do a "save as" with a new name.
• dmitriy sagadiev
o 17 Apr 2018 4:18 PM
In reply to Matt Stoner:
Thanks Matt. If I use my valve for monitoring only (no control), how can I establish the reference between DI_SOFT_52 and the PCSD_52 On/Off Valve dynamo? The DI_SOFT_52 will be customized by adding two additional parameters configured as alarms for the fail to open/close states.
• Matt Stoner
o 17 Apr 2018 5:21 PM
In reply to dmitriy sagadiev:
I wouldn't use a DI_SOFT, just add the parameters in the new VLV class you create and then you can do alarming for those individual bits. No indication would be needed because it would be alarms if they ever become true. Just make sure that the priority is set appropriately for the operator to do something about the indication.
• dmitriy sagadiev o 17 Apr 2018 6:19 PM
In reply to Matt Stoner:
Okay. Should I still use VLV class for solely monitoring purposes? Say, I create a new DI class with external references for alarms. I'd like to reference the new class in the PCSD_52 On/Off valve. Is that possible? If yes, will the existing valve dynamos normally referencing VLV classes work as intended? I don't want to affect the PCSD dynamo performance if they are class based, too. Does the PMO configuration work in such way?
• Matt Stoner
o 17 Apr 2018 7:32 PM
In reply to dmitriy sagadiev:
I'm suggesting doing it this way because of the dynamo for the valve will be working. I also suggested removing composites that wouldn't be needed because it was indication only to reducing loading that isn't necessary. You can remove the composites Modelock, Permissive, Interlock, Force Setpoints and Motor Run Time if they are in the new module you created. Then change the parameter SUBTYPE_FPDT to be "V_12" and you won't have any FP or Detail issues. The valve dynamo would just need to turn off Aquire Info, No Symbols, Mode, I/L Info, Permissive Info, and set Abnomal Mode to No Indication.
Try one if you can and see how it works. If you ever add control of the valve you only have a little changing to do of the system instead of new module and new dynamo with this method as well. Little more load than DI Soft but you have a dynamo that will work instead of doing all the visibility options and producing a valve (if you had planned that) which is what I thought you were trying to achieve.
• dmitriy sagadiev o 30 May 2018 3:37 PM
In reply to Matt Stoner:
I built a PCSD discrete valve control module based on the _V11_IP_SOFT_52 in ver. 11.3.1 following the guidelines above. Please refer to the attached control studio capture. However, all modules in this class are in MODBAD alarms with undefined field values and “unresolved reference†MSTATUS.
I routed the close/open (0/1) bit via EXT_IN_D1. The CAS_IN_D parameter of the DC_CTRL function block outputs the UNDEFINED 255. I reckon that the operating parameter REQ_SP writes 255 to the DC_CTRL module and causing problems.
In SIMULATE, state of the module changes from 0 = CLOSED to 1 = OPEN; however, when I force the bit via EXT_IN_D1 to 0 (normally closed), the PV_D is UNDEFINED and when EXT_IN_D1 equals 1, PV_D is CLOSED. In both cases OUT_D is zero.
I would be very happy to gather your input on the subject if you have time to review.
• Matt Stoner
o 31 May 2018 1:21 PM
In reply to dmitriy sagadiev:
The MODBAD is being caused by the Unresolved Reference(s). These can be found by going to Diagnostics, finding the module (Controller Assigned/Assigned Modules/Module), right click and select Display Unresolved References. Fix those issues and MODBAD should go away.
The EXT_IN_D1 issue is because the DC1/STATE_MASKS parameter is configured to have 2
inputs and you only have 1 close limit switch. Change the 2nd Column for the inputs to be don't care (Grey out check box). If EXT_IN_D1 isn't a close limit switch you will need to change Column 1 to be open limit switch (See below).
• dmitriy sagadiev
o 31 May 2018 3:28 PM
In reply to Matt Stoner:
Thank you Matt. You are a rockstar! The unresolved messages happened to be two alarms I disabled: BYPASS_ON and INTERLOCK_ALM. I couldn't removed the two from the module in DeltaV Explorer, but successfully deleted them in Control Studio. • Matt Stoner
o 31 May 2018 4:11 PM
In reply to dmitriy sagadiev:
This is saying that somewhere BYPASS_ON and INTERLOCK_ALM are being referenced (most likely incorrectly). Do these alarms exist on that module?
If they do, export your module and search for references to those items in the FHX with text editor or send me that FHX in email and I can quickly see if I can see the problem.
