Recent Control & Safety Systems Discussions
Similar Posts
Upgrade iFix Graphics from V14 to V15
Data Amount on IFIX
issue with ifix service mode
Can Calibrate lock in iFix
Remote Login Graphix Ifix error
Share

Graphics - convert iFix to HTML5

Here's my thoughts on graphics conversion - I would be interested in yours.

Basic Requirement: Ensure "look and feel" of converted graphics (including faceplates and details) is very similar to iFix graphics. Legacy graphics include 4:3 aspect ratio main graphics designed for old monitors (which get stretched to fit new 16:9 flat screens) as well as those designed to utilize 1680 x 1050 capability. Layout file is three regions per screen (most are dual-head workstations) with a band for our "custom" toolbar (1680 pixels wide) which still uses some of the old icons from Fix 32 days, a 1680 pixel wide section for the "main" graphic, and a 1680 wide "alarm banner".

We do not use PCSD (?) and only use stock dynamos for MPC (so 99% are "custom").

Alarm colors / sounds / icons etc. will all need to match the old and conform to our "Alarm Philosophy".

Step 1: Create a set of GEMS that correspond / closely resemble existing dynamos. Improve them / consolidate where possible but make sure fonts / colors / etc. are about the same. Incorporate good stuff from new graphics engine (hover, context menus, etc.)

Step 2: Import custom toolbar; see if most functionality is preserved. Import or modify the stock alarm banners to span 1680 pixels.

Step 3: Edit the XML file that is used for replacing dynamos with GEMS, to tie our custom dynamos to their corresponding GEM.

Step 4: Try the conversion engine / wizard / whatever on some graphics and see what we get.

I assume faceplates and details named in the database have some like-named analog in another directory. I might try to get the operators to "like" the new faceplates rather than re-create new ones to match the old custom faceplates.

If you think this path is frought with peril I would be interested in your experience.

-John

John Rezabek

6 Replies

  • Andre Dicaire
    I've migrated a few displays to Live to see what happens. In general, the result is a working display with the same look as the original. Some things are not handled and you might have to add them post migration, such as Embedded Trends (though 4:3 aspect ration displays probably don't have this feature in them.

    You are on the right track to create corresponding GEMS and to update the XML file that maps across. Out of the box, the XML has mapped the HP Dynamos to HP Gems. The replacement algorithm checks for the Dynamo to contain certain information and variables objects before it calls the XML map. So older dynamos may not map even if you enter them in the XML. I suggest you build an Operate display with all the Dynamos you use in your displays. Map these in the xml and migrate this file. That will allow you to see clearly which dynamos mapped successfully and what issues you might still have to deal with.

    Be aware that the Gem replacement does not bring forward the Dynamo configuration options like Orientation. The GEM will be applied with its default information and you will have to tweak these to adjust position/orientation of objects like valves and such. Older Dynamo libraries had multiple versions and don't have all the options of HP Dynamos. IF these map to corresponding Gems successfully, that would work.

    As you know, the migration will not migrate custom VBA script. The migration tool recognizes scripts created from the Animation wizards and applies these to Live animations, but if you manually customized the vb script, that will likely be lost and you will have the default animation behavior. Replacing the Dynamos with mapped Gems is best an you test your Gem behavior for all those animations.

    Dynamos that are not mapped and replaced get an unlinked Gem in the new Live display, to the best of the migration tools ability. You can convert these to a linked Gem later once you have created the Live version you want to use.

    As for the balance of the display, each object is recreated. Line segments, arrow heads, data links are all created in Live without any of the new features. Line segments are not linked end to end and so there is some clean up to get the display optimized. It will look pretty much like it did in Operator. Line arrows are separate from the lines.

    Objects like tanks and vessels come across as bitmaps, and identical items get unique bitmaps. You'll want to update these with Gem versions so you can align text font, size and color with our display style guide and library standards. Color tables will not map to the library color standards and new standards will be created in the migration library.

    There are new Faceplates and Detail displays called contextual displays in Live. The Module display information still defines the linked displays, which must have the same name as what you used in Operate. New faceplate layouts were created. If you wish to revert to the same look and feel as Operate, you will have to replace the OOB contextual displays that use the same name you had in Operate. Now is a good time to evaluate if your operators might want some of the new Live faceplate features and maybe consider using the new displays moving forward. It's a thought...

    Emerson has been working on a migration service with in house tools to deliver value to customers, but I'm not yet aware of where this service stands in terms of dollars per display. In house tools are easier to create without having to be supported by the entire organization. The end product is what your are concerned about, and the process can be a combination of tools and people.

    If you decide to migrate your displays yourself, you need to be prepared to learn a lot about the migration tool and the errors and warnings it generates, and how to resolve every item. Then once you are finished, you will be a migration expert with knowledge you won't need ever again... Emerson will be doing many migrations and will be much better at it.

    When you migrate a 4:3 display, the Live display will have a 4:3 aspect ratio and will "letter box" in the Display Frame where it appears. It is very easy to change the display size and reposition items to make what might have been cluttered displays less cluttered. What is king in Live is the aspect ratio. Displays are independent of resolution. a small display will scale up to fill the display area. The display size dictates how big the Gems will appear in the display, as they too have their size. the OOB Gems were designed around a 23 inch HD monitor. So when you migrate your displays with different Aspect Ratios, you can adjust the Live display size and aspect ratio to get the right "feel".

    I think the migration tool gives you a quick migration to get a feel for Live, but it leaves a lot of clean up work to make the display efficient to work with and to align it with your library standards and such. I would recommend seeking out your Emerson Impact partner and consider migrating your displays through a service.

    Andre Dicaire

  • John Rezabek

    In reply to Andre Dicaire:

    Hey . . . sounds like the method of editing the XML file to improve mapping of GEMS to custom (end-user-created) dynamos is not covered in the training classes? Is it documented somewhere that you've found?
    Thanks,
    John
  • Andre Dicaire

    In reply to John Rezabek:

    John, Not that I can find. In BOL, there is a section on converting Grpahics (search XML and Dynamo), but it does not discuss the mapping file.

    There are two files:
    DynamoCrossReference.XML
    DynamoCrossReferenceAddition.XML

    Both located in the Graphics-iFix/Local directory.

    If you've tried this conversion tool, you know that the HP Dynamos are mapped and replaced with the HP Gems. You can see all these mappings defined in the DynamoCrossReference.XML. the "...Addition.xml" file is empty. Not sure what that is intended for.

    When I reviewed the VBA code, I think I can say that the Dynamo has to have some recognizable syntax or else, the conversion does not call the replacement functions that use the XML file. Those will be converted to unlinked Gems, and its way easier to deal with them in Graphics Studio rather than try to modify the iFIX displays.

    I'd say a Migration Guide would be of great use. I don't know if one exists or if one is in the works. Emerson has been working on migration services to support customer migrations. I suggest you work with your local Impact Partner to figure out the best path forward. Remember, there is no rush to migrate now, other than wanting to avoid having to build new graphics in Operate and adding to the number of displays to migrate in the future.

    One thing I'm coming to believe to be important is to define your HMI Style guide and DeltaV Live Toolkit. The way I see it, the style guide takes your HMI Philosophy and breaks it down to the Items that you will implement in the DCS. The toolkit is the actual configuration objects and is represented in Graphic Studio as the GEMS, STandards and functions. You want this clearly defined before you start migrating.

    You also want any one doing work for you to use your toolkit. I saw a recent project with 4 configuration teams handling different aspects of the project and each provided new standards and functions that overlapped rather than using the "STANDARDs" already in the toolkit.

    Andre Dicaire

  • John Rezabek

    In reply to Andre Dicaire:

    Thanks for checking Andre . . . I'll have to get some training on Style Guide and Toolkit. Since we are interacting with 20-year-old modules in many cases (so no hooks for high-performance graphics and no impetus to add them) - also no "Classes" - there will be some square pegs for round holes or vice-versa, I imagine. Surely Emerson considered backwards compatibility and legacy configurations when developing "Live" <g>.
  • Andre Dicaire

    In reply to John Rezabek:

    Yes I do think backward compatibility is considered, and addressed. The HMI runs with the Runtime modules, so it does not matter whether they are Class Based or not. Also, most GEMS are focused on a primary function block in the module, like the PID or AI or DC blocks. All the static objects in displays are recreated in the conversion tool, but enhancements like Line End treatments, Intersections and connected end points are not there in the old HMI display.

    The OOB GEMS use some common component GEMs to achieve the Display ready HP_GEMS. You might need to make some adjustment to a few of these to achieve full compliance with your control module structures, such as how you want to handle Simulation status on FF blocks versus Native blocks. But PID and FFPID are mostly identical when it comes to the Operating parameters. So the latest GEMS will still work with your Modules.

    If our modules work with the OOB faceplates and dynamos in iFix, they will work in Live. If you modified things in iFIX, you'll have to work that through the migration.

    That's why the STyle Guide and Toolkit development is most important. This exercise will expose those things that really should be aligned with a the HMI philosophy , which should evolve with a migration to Live. Once the Style Guide and toolkit are ready (mostly ready, as these also have a lifecycle to keep evergreen), you have the answers to all your migration questions.

    One more observation. I think most facilities have an L3 centric display design. The new concepts of situational awareness and the use of Overview(L1) are not there. The Overview displays are mostly navigational displays with very little Information, but maybe some data. In a migration project, the migrated displays can still be used, and provide familiarity to Operators. It is the L1/L2 layer, which is a smaller subset of displays that provide opportunity to enhance the operator's access to information and quick decision making. So yes we will migrate many displays as is. We can right wrongs that have accumulated over time. But mostly we can elevate the situational awareness with some of these newer techniques and ideas.

    This all gets back to revisiting the HMI Philosophy, ensuring the Style Guide provides the implementation details, and then bringing it to life in the Toolkit (Library). We can evolve these in parallel so progress is made early, but without the clear philosophy and style guide, implementation can suffer from lack of consistency.

    Andre Dicaire

  • Brian Hartman

    In reply to Andre Dicaire:

    We've been exploring how well the iFix display conversion works.  It would be very useful if we could replace our custom iFix process dynamos with process GEMs for existing displays at sites.

    For the DynamoCrossReferenceAddition.XML file, we utilized the same XML structure as the DynamoCrossReference.XML file, we did not specify a DTD.  In the example below, the intent is to replace the custom dynamos AI_IN and AI_OV with GEMs AI_IN_NEW and AI_OV_NEW:

    <DeltaVDynamoCrossReference>
    <!--The name of a dynamo is NOT the name that is displayed in the dynamo set.
    The actual name is contained in the frsDynamoInfo variable in the dynamo
    group and along with the ps_dataSource variable makes the detection of a dynamo simple.

    Dynamos with duplicate names are commented out but left in place-->
    <DeltaVDynamo Name = "AI_IN">
    <DeltaVLiveGem>
    <Value>AI_IN_NEW</Value>
    </DeltaVLiveGem>
    </DeltaVDynamo>
    <DeltaVDynamo Name = "AI_OV">
    <DeltaVLiveGem>
    <Value>AI_OV_NEW</Value>
    </DeltaVLiveGem>
    </DeltaVDynamo>
    </DeltaVDynamoCrossReference>

    Running ExportToDeltaVLive in Operate Configure on a iFix display containing AI_IN and AI_OV dynamos resulted in a DV Live display, where the replacement GEM instances AI_IN_NEW and AI_OV_NEW were created as expected/desired.

    An issue with the conversion process, however, is that the replacement GEMs are expected to be in the OOB Library library, where I expect a lot of customers would also have their own library (that is our direction anyway).

    If you add a library path to the GEM class name, e.g. NewLibrary.AI_OV, the export fails with error that it can't find GEM class Library.NewLibrary.AI_OV.  This is not insurmountable but it would be really nice to control which library the replacement GEM was coming from - has anyone else worked with this and found any more information/workaround?

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.