Emerson Exchange 365

What you are asking for is very risky (won't be supported) and you could potentially lose configuration and/or corrupt the database if you don't do this correctly (which is why it wouldn't be supported).

Can you use a Command Driven Class and then just link the module blocks to the correct item needed?

If the logic is staying the same and you are only changing module names then I would definitely suggest using this method instead. You can even IGNORE module blocks for cases that don't have "exactly" the same equipment. To learn more about this method, In Books Online you can go to

• Configuration -> Module Reference -> Equipment module example
• Configuration -> Batch -> Batch Tutorial -> Equipment definition -> Equipment module classes

In reply to Matt Stoner:

I agree with Matt.
If I were you (Jaime) I will create class-based Command Driven Module, and Control Modules for field equipment.
I dont know how looks your sequnece (actions, transitions, monitors) and DIAGRAM
If we need to use the same logic (but different field equipment) best way is using something like alliases linked to field equipment.
Actions and transitions should contain alliases - not real equipment names.
Next is to create CDMs to each unit, and you need only to bind proper devices (equipment) to alliases.

In reply to Matt Stoner:

Due to time constrains, it would be more efficient to edit the .FHX file than turning all the sequences to class-based, and editing their parameters to be used in a class-based environment. The sequences and the equipment are the exact same, all I'm doing is literally adding a prefix to a lot of the tags/names.

I'm now considering a few options; some feedback or opinions would be appreciated:

A) Create a new Command Driven Control Module (Let's call it Mod-A) based on the exact same Named-Set that the original Command Driven Control Module is using. This would generate new Function Block Definition Names, which I can use to edit my .FHX file. I would then delete Mod-A, and re-import my .FHX file. Hopefully this would create new COMMAND blocks, instead of updating the original ones. Only downside is, I'm not familiar with how DeltaV Explorer keeps track of the Function Block Definition Names, so I'm not sure if this would cause more grief.

B) Create a copy of the original Command Driven Control Module, go into each COMMAND block, and manually update all fields with the new prefix. This is less preferred as it would be very time consuming, and since the COMMAND Blocks would have the same Function Block Definition Names, it would probably also update the original Command Driven Control Module (Unless, manually editing the contents COMMAND Driven Control Module, auto-generates new Function Block Definition Names).

C) Create a new Command Driven Control Module (Let's call it Mod-A) based on the exact same Named-Set that the original Command Driven Control Module is using. This would give me the full lay-out of the module. I would then copy and paste the contents of each COMMAND Block from the original into Mod-A, export my new Command Driven Control Module into an .FHX, modify it, and then re-import.

I should mention, I am running this on a lab set-up with complete virtualization. So any problems encountered while testing this can easily get reverted. I would make sure the modules are fully tested before being deployed to the real applications.

Thank you!

As said by others this is very risky. I recommend using class based approach.

Consider using an isolated DeltaV system ( a single proplus) to import, check, and manually adjust manipulated FHX . Then export items from this isolated system and import into development system.

Regarding SFC command composites identificator (__#####_#####__); note that this string is changed by deltav when a COMMAND is edited, even if you only open COMMAND into control studio DeltaV will change this identificator if EQM is saved. So, if after importing modifed FHX you open imported class with Control Studio you click on all commands and then you save the class all those identificators will be changed.

In reply to Jack_France:

Thank you for the answer Jack, this worked great. Also, It's good to note that like Matt said, changing the time stamp is not required, a change to the "User" name field does the job.