export/import graphics displays
example:
$'pr::Application_1/Programs/Horometros:{2ffd1a35-cd14-43b7
-99f4-f2183e6dd443}:TG4_PU_001_Horometro'
Answers
What version of 800xA? 5.0 SP2 Rev0, A, B, C, D or E?
I assume the GUID was "Control Module", etc. before you made the move?
The system can use name or GUID syntax. GUID is prefered by the computer while plain text is prefered by humans...
Sometimes, a GUID may be returned to make a path unambiguous, e.g. if a duplicate named aspect exists.
Please submit some more details.
/S
before export
when import in other AS
add {2ffd............}
Whenever you use the Graphic Builder to create or edit a connection to a data point, the Graphics Builder immediately "resolves" the Object "Name" that you entered into the internal GUID identifier for that object:aspect:. Your graphics only store the GUID. When you view the graphic, the connection to the OPC server is made using the GUID.
When you re-open the graphic to edit it again, the Graphic Builder resolves the GUID back into the original object name.
This means you can change object names without the Graphic noticing - because it stores and uses the GUID.
When you export the graphic it contains ONLY the GUIDs - not the object:aspect names. When you import the graphics to a new system the graphics builder tries to resolve the connections again. So the two systems have to be Identical - not just the same object names but the same GUIDs. The only way to do this is to import/export Everything - not just the graphics - and make sure that the two systems (ie the one on-site and the one in your offfice ) are always synchronised.
If the two systems are not identical, then the graphic cannot resolve the GUID's back into Object connections properly. When you view the graphic it will show data subscription errors ( actually unresloved connections). When you edit the graphic, you see the GUID from your office system because it cannot be resolved in your on-site system.
In your case it looks like somebody edited "Application_1/Programs/Horometros" either in your office or on-site which has changed one of the GUIDs for an object you are trying to display.
You need to synchronize the two 800xA systems again by importing/exporting the relevant program.
Or you can edit the connections manually in Graphics Builder on your target system.
This issue may come up when we have two aspects with the same name in the object or a missing referenced aspect in the system.
I am able to repro the issue with the following Steps:
1. Create two objects of type "Generic" in Functional Structure. Name it as "Object1" & "Object2".
2. Create an aspect "Graphic Display PG2" in Object1 and "General Properties" aspect in "Object2"
3. Create a Property in Object2\General Properties aspect.
4. Now edit Object1\Graphic Display PG2 and add a text control. Refer the Text property from Object2\General Properties aspect.
5. Export "Graphic Display PG2" including dependencies and save it as "PG2Export.afw"
6. Delete both Graphic Display PG2 & General Properties from the respective Objects.
7. Create another aspect with the same name in Object2. i.e, General Properties aspect. ( not required to create any properties in this ).
8. Now try to import PG2Export.afw and it will prompt for overwriting or skip sub tree. Select "Skip sub tree" if it finds an aspect/object.
9. If we edit the Graphic Display PG2, it will show the path with GUID.
Since the dependency is missing in the system or there is a ambiguity to resolve the references, it will show the GUID.
For me it is showing as "String($'pr::Object2:{6f6d51ca-d3dc-4267-99cd-21449647f0f1}:ABC')"
Here the GUID is referred to General Properties aspect. This is just an example of showing GUID in the reference.
Add new comment