The export utility has an XML look up file that maps dynamos to GEMs and replaces the dynamos rather than migrate them. You can go in and add mappings to expand what is covered.

There is no mapping of color tables in this XML file.

So migrating your Operate color tables to map them to some defined Standards in your database (rather than having new ones created) you will have to identify these and possibly parse the converted XML files to replace items with your Standard prior to importing the display into Live. That's where I would start.

In preparation for migration, I created a couple of displays in which I added one copy of my dynamos and some sample configurations using color tables and such. Then I migrated those to see in a controlled fashion, what the migration tool did and what tweaks I would need. All new standards are created in a Migration library. I then looked at the XML files to find all the migration issues documented and figured out which I would want to address with a "search and replace" tool in the xml file, and which I would resolve in Graphics Studio. Then I migrated one at a time.

The results of a conversion look pretty good at runtime without any modifications, however, there are many details that cannot be truly converted to use Live features.
- Lines will come over as individual segments, just as they are in Operate. They are not connected so some corners can still show a slight offset depending on actual endpoint values etc.
- Arrows remain as separate objects. Live line endpoint options are not enabled to replace arrow points.
- some objects such as vessels and tanks come over as bit maps, which you might want to convert to a GEM. Each instance of an object becomes a new Image Standard.
- some animations are not implemented in the same way or are not available on certain Live objects. These are noted in the migration log. you will also see associated migration issues identified in the description of the Live object, in the form of #mig-26#, which you can look up in BOL for description of the migration issue.

The biggest issue is with custom VBA scripts that were created outside of the Animation and wizard tools provided by Operate. The conversion utility does not attempt to convert these to Typescript. This is a manual task. In many cases, what was created in VBA in Operate is available as a function or option on Live objects. For things that are not handled, Typescript provides a powerful language, and a learning curve.

The migration tool gives you the ability to quickly migrate a Operate Display to Live, and actually use the result at runtime. However, you will likely want to clean up these displays to make use of improved features in Live and align the Standards and functions with your library. This can be done over time while still having a functional display for your operators.

Emerson has developed a migration service to assist in display migrations and your local sales office should be able to discuss these options.

The DeltaV Live Conversion Service has 3 options available:

• Option 1: Engineered direct conversion from DeltaV Operate to DeltaV Live
• Option 2: Redesign adopting Advanced Operator Displays with a DeltaV Live Conversion
• Option 3: DeltaV Live Self-Perform Conversion


There are so many different ways to solve any problem. The services provided by Emerson involve a combination of internal software tools and manual review to ensure end results deliver the functionality of the original. And for many customers, it is an opportunity to improve their operational efficiency by upgrading their displays, not simply migrating them.

Andre Dicaire

In reply to Andre Dicaire:

You mention editing the XML. Okay, so I created a .grf with several lines on it, each a different color. I look at the XML and see where the properties are defined, for instance:
<BackgroundColor Type="Color" RawValue="#FFAEB0B2" Blue="178" Green"176" Red="174"/>

So, even if I could change this in the XML prior to using the conversion utility, how do I make it a standard. It seems all i can do is change the color. Well, i can change the color after the fact if I wanted.

I'd expect to import the XML into Graphics Studio. Open it and click on "Line3" and under Line Color property have it say S_Color_ProcessLine or whatever standard color I had created.

In reply to Andre Dicaire:

also, while we are on the topic of conversion, it seems that we have to build new GEMs regardless. We can map the dynamos to a GEM for when we convert a graphic. .but we can not convert dynamos to GEMs directly. Is that correct?

In reply to TreyB:

The migration tool creates an XML file for import into Live. The tool is actually built in VBA as a wizard in Operate. The tool uses an existin reference XML file that maps Dynamos to GEMS. The GEMS must be existing in the target Live database.

You will not find Dynamo to GEM mapping in the output of the migration tool. IF a Dynamo is not replaced, i.e. it is defined in the mapping XML with a corresponding GEM, the tool will do its best to create an unlinked Gem in the migrated XML file. You could subsequently edit the Live display, and replace this item with a new GEM that you create post migration. Rather than spend time modifying Operate displays to work with the XML mapping, you can make the change in Live and get proper positioning.

The XML Mapping and migration tool work with dynamos that follow a specific data structure. older dynamos or custom dynamos that don't have such structure cannot be mapped to GEMs without modifying the dynamo, or rewriting the VBA could to identify these items.

My recommendation is to post edit the Live display and not spend time pretreating the Operator displays.

Emerson has more advanced tools for migrating displays in house. You can contact your local Emerson sales channel to discuss using migration services to migrate your displays. the Out of Box migration tool will migrate to a functioning display, but you will still want to clean this up using Live features.

Operate continues to be supported so that the migration process can follow the system upgrade to v14 and beyond.

As for color tables, they are replaced with Color standards. There is no mapping of these in the migration tool, so new color standards are created as part of the migration process. You can update the Live display to use your standards and remove the migration color standards.

The migrated XML file could be used a source to post process this with a custom tool to replace references with library standards, but that is not part of the migration tool in the product. That is something you could look at, or let Emerson help with this via a migration service.

Andre Dicaire

In reply to Andre Dicaire:

Makes sense on the GEM mapping. I have already begun migrating a dynamo set. I have a GEM class folder and the converted GEMs. Of course, most nothing works for scripting, but for the most part, we're just bringing over graphics. The actual scripting will have to be edited to match our custom. Which is a work in progress as I learn the new environment/language better.

With the new color standards created during the migration... i see those in the ConvertedDeltaVLiveDisplaysAndGlobals, but that does me little good. I already know what the colors are and the name it gives, doesn't help decipher what was actually created. SO, I'm likely to just recreate all the color standards within Live. This is what you refer to when you say "update the Live display to use your standards".

If the XML file could be modified to reference an existing LIVE standard color, so on import it uses that instead of a generic "#FFAEB0B2" color.. that would be ideal. I just don't know how to modify the XML in that way or if the import is even capable of it.

If we are going to be touching every object in order to change the color, then we are getting to the point where a complete redraw is probably less work or equal to a migration.

As for the services offered, i'm quite sure that is a budget item that wouldn't be considered until we at least attempted an in house conversion on a large scale. Of course, we'd continue running Operate primarily while this was being done.

In reply to TreyB:

i forgot one thing. I actually do not recall where i can find the XML file for mapping dynamos to GEMs.

In reply to Andre Dicaire:

Yeah, none of the mappings worked for me. All our custom dynamos were created with the wizard in Configure. So, they should have the proper structure. I tried both XML files for the mapping. Everytime it created an unlinked GEM. Oh well, it seems like rebuilding is going to be the best option. Thanks for your help.