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
Andre Dicaire
In reply to Andre Dicaire:
In reply to John Rezabek:
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?