Emerson Exchange 365

In reply to István Orbán:

You've got several options but it comes down to either doing this in the controller, or from a workstation.

In the controller, you have to define the modules to be manipulated. It appears you do not have these modules defined by aliases under the Units? If the were, this would only allow for a common "phase" that could run to set modules OOS. If the aliases are all different, you still have to write a specific name reference for each module in each unit. What you would like is an indexed list of the modules under the unit so that you could write code to programmatically write to each module with a generic function (the Service module or a Module state Management Phase).

I am thinking of two options here. Create a Named set for each Unit and list the module names in this Named set. You could then be able to read each module name, concatenated it with the parameter and set a Dynamic reference parameter. When the path binds (CST = 0) you write the MCOMMAND value (OOS or In Service) and clear the path, move on to the next index, and if it is not "NULL" of "", loop back and do the next Entry.

This uses a Named set per Unit, but it allows you to manage the list of modules per unit with a Set UP download to the controller. And it uses a common piece of code rather than explicit logic that needs to be altered, which introduces risk and code maintenance issues.

Or you could use a separate Module List module, that uses a generic parameter naming scheme like '^/MODULE1.CV' to hold a module name. There is a unique module for each unit, or these could be Unit Parameters. A final '^/COUNT.CV' integer parameter is set to the number of defined MODULEX parameters. Again, using a dynamic reference, an Action expression steps through to read the Module1.cv value and concatenates this into the DYnamic.$REF field, waits for it to bind, writes the desired MCOMMAND value, Checks module is OOS or In Service, clears the $ref, and moves to next index. To manage this, you add MODULEX string parameter with module name to module and set Count to match.

Another approach is to use a VBA function that reads an XML file with the Unit/module names listed. (or a CSV file, what ever is easier for you). Then you can run through this list programmatically. You would want to limit the number of writes per second, and confirm all modules actually change state as desired. Maybe add a parameter in the Unit to indicate the unit is In Service, Out of Service, In transition, Aborted. If in transition, the function cannot be initiated, but could be aborted. That way, you avoid two workstations trying to set the modules at the same time.

The advantage here is that you'll get a record of the module MCOMMAND writes, who initiated the transition, and a transition complete message when the status is set to OUT of Service. But you also have Upload records for MCOMMAND to delete/ignore. But now you have an XML file to manage for setting the module list.

The downside here is that you have an XML file sitting in the workstation and VBA code to execute on it. You can add a LogEvent command in the controller function to log each module's transition. So, I'd lean to using either the Named Set or a ModuleList module, which could be an embedded block. I'd make sure to have a Status parameter that indicates when a Unit is transitioning to and from OOS, and allow for a user to Abort, and change their mind. And a good "Are you Sure" message. And of course, disable this whenever it is not appropriate to run it.

This would be a lot easier if we also had a String Array type parameter, rather then having to use Named sets. Then you could have a single Unit Level, String Array parameter. And maybe this could be a standard parameter on every unit that is automatically populated with the modules under a Unit. This would give an option to manage module parameters by Aliasing, or by index. Hmm. We would need to be able to use the array string by reference: '^/MODULE_LIST[x]/BLOCK/PARAMETER.CV' in an expression.

And while I'm at it, every module should have an indexed alarm reference so we can interrogate or set Alarm parameters in a generic way rather than explicit alarm names. If my Detail displays could reference:
'..../ALM_LIST[x].NAME, .CUALM, .NALM, .LIMIT, .ENABLED, etc. then the alarm settings in the Detail display would be generic, and simply work, with whatever alarm names are used, because it would show alarms by index. Having a String Array, and a way to embed this into a parameter path would solve this.

Andre Dicaire