Hello,
I would like to implement a logic which stops the execution of all modules within a unit, except the Unit Support Module.
My original idea was to just put a flag in the Unit Support Module which all the modules are referencing to place themselves in OOS. This is fine, but once they are in OOS, I have no way of placing them back into In Service because the logic within the modules is not executing. I tried doing this, hoping that the wire is transformed into a reference in the controller and it gets executed, but it isn't:
As you see, even if the USM_OOS parameter is set back to "In Service", it won't get written to the module's MCOMMAND.
So, do you know any more elegant solution? Or do I need to hardcode a reference to each module's MCOMMAND parameter within the USM itself? (i.e have a huge expression which acts on module1/MCOMMAND, module2/MCOMMAND, etc. which would have to be updated each time I add or remove a module)
Thank you,
In reply to Matt Stoner:
In reply to István Orbán:
Assuming I go ahead with the implementation, what would be the more optimized way to do it? Having in mind that we have some units with 200+ modules. I don't know how healthy it is to maintain so many references in a module (is there a limit?), even though they are all on the same controller.
Option 1: hardcode the module names in an expression.
Pro: references are not maintained in parameters. Contra: expression needs to be changed when a module is added/removed.
Option 2: maintain external references to all modules' MCOMMAND parameter.
Pro: expression is fixed, does not need to change. Contra: 100+ ext.ref. parameters.
Option 3: something tricky with dynamic references and configuring just the names of the modules as string parameters.
- build reference to just a limited number of modules (25-50?) at a time
- set MCOMMAND
- point references to the next set of modules
- etc.
- when done, destroy references (point to dummy or leave them empty)
Disadvantage would be that it takes multiple scans to shut down the unit, but this is not a huge concern.
In reply to Michael Krispin:
The required logic could be handled on the communication modules(landing modules, diagnostic module for VIM's configured in deltav), in the diagnosic module of VIM you can write a logic to enable/disable(the alarms) based upon the respective equipment device is connected/disconnected, the modules will be continously running in the controller.This way you can retain the other features as it is and also not deviating from the standard configuration of DeltaV. 1. The point is your logic should handle(enable/disable alarms) the control modules of only those connected equipment. 2. The number of connected slave equipments equals to the respective slave logic modules written in the vim diagnostic module. 3. Show on the faceplate of the control module if either the device is connected or disconnected.
As Michael suggested, you are handling a different/smart application. need to give a design thought of logic implementation either on class level or classless design of library.
Karma doesn't have any menu, you get serve what you deserve.
By any chance is this all going through a VIM? If so I would look into to using dataset scan control, (page 82 of the modbus TCP vim manual), you can disable either devices or registers from DeltaV. When they are disabled, I believe the registers just go to 0 by default. This gets around the OOS issues presented above, and should cut down the alarms from disconnecting the equipment. If you need help with this, you can contact your LBP, or just call the GSC now that Mynah is a part of Emerson! They should be able to help you out with this if it's the direction you want to go.
In reply to Tyler Anderson:
Andre Dicaire