[link="http://www.everdyn.com/blog/"]From Everdyn's blog[/link]
In this series of posts, ’the boss’ looked at how to select a PC to run your HMI on, and I looked at how data flows between ArchestrA objects and Archestra Symbols on the screen.
Now I want to look at an approach to decreasing the amount of subscribed data by making use of the cache introduced in 2012 R2
On a detailed popup for a piece of equipment, some data (eg tank level) is dymanic. Other data, such as units, is effectively static. Truly static data is hard-coded into symbols, but in order to make inheritance work, lots of data that never changes is treated as dynamic.
Units are animated from the owning object
Above you can see how static data (units) is treated as dynamic. If the value stored in someobject.Units changes then the symbol will instantly change. While we don’t need this to change we often build systems this way so that we can configure attributes at the object level rather than giving each object a unique graphic. An alternative would be to override the custom property Units in the popup graphics in the actual object. This would be very tedious and would make it (almost) impossible to bulk load the galaxy with objects.
There is a way to use bulk-load files to modify graphics like this, but it is not part of the standard product. If you really need to programmatically build or modify symbols, contact Everdyn as we can customize a tool to help you out.
Since ArchestrA 2012 R2, Popups are by default stored in the cache when they are closed
By default ArchestrA symbols are cached
What this means is that custom property values are retentive (until InTouch is re-started). Those that are extended to objects stay bound, but are put off-advise when the popup closes. On re-opening, they are put back on-advise. Those that are not keep there last value when the popup opens a second time. This can catch the unwary out as in the past the on-show script only saw the deign-time values.
If we know that the value, once retrieved from the object, is not going to change, then we can break the link and keep the value. This means the the popup opens faster (after it has been opened once) and the load on the engines is decreased.
The way this is done, and indeed the whole point of this post is demonstrated in the following script example
Disconnect Custom Property
Now unless you are familiar with the SetCustomPropertyValue script, it may not be clear how the above works.
The first parameter is the name of the CustomProperty to set – hence it is in quotes.
The second parameter is what you want to set the CustomProperty to. This will either be a value or an address – depending of the third parameter. In this case we are giving a value. The value is the value currently contained in Units, hence no quotes.
The third parameter is the same as the icon next to “Default Value ” (see below). True is the T symbol (T for True – easy to remember!), and false is the tag symbol.
The script effectively over-writes the design-time configuration of the Custom property Units from:
Configuration at Startup
to:
Effect of changing a custom property in the script above
Note: In the example above I assumed that the value of Units in the object was “Litres”. Of course the whole point of this is that whatever is in the object is effectively hard-coded at run-time on a per instance basis.
Of course you need to make sure you are not re-using the same instance of your popup for more than one object.
So there you have it. A way to disconnect all the UDAs that don’t change, without loosing the power of inheritance!
Questions? No? Class dismissed!
The post Wonderware Archestra graphics optimization (Part3 : Semi-Static Data) appeared first on EVERDYN.