ArchestA Graphics Notes
Just ran a quick test on ArchestrA graphics to verify when the OnShow & OnHide scripts execute. I was also testing if AA graphic objects’ visibility properties are updated when the InTouch visibility was updated. Nothing Earth-shattering here, but just a quick FYI.
I created a simple AA graphic with a button to toggle visibility on a rectangle. I dropped that down in InTouch with another button to toggle the visibility on the whole AA graphic. The AA graphic also has simple LogMessage commands in the OnShow & OnHide scripts. I also had a regular script that executes once.
What I found was that whenever an InTouch screen loads, the AA graphic executes the OnShow script then the regular script. When the screen closes, the OnHide script executes. Toggling the InTouch visibility on the AA graphic did not trigger either the OnShow or OnHide scripts.
Toggling the InTouch visibility on the AA graphic also does not update the visible parameter on the objects within the graphic. That acts as expected. I was hoping there was a built-in easy way of detecting when the whole AA graphic changes visibility from within itself. The purpose would have been to refresh data (i.e. on a data grid) whenever swapping between some of our tabbed graphics. We currently expose a parameter as public to force the refresh from the containing AA graphic.
Also, if I remember right, there are issues with remote IO reference connections making that OnShow script unreliable. I believe that has either already been corrected in the latest release or might be on the list of issues to fix in the next release. If someone would like to post a comment on the details of the issue and/or the fix, I’d be grateful.
Good post, the symbol scripts is a mess that requires documentation.
I don’t use InTouch much these days but had to go in and replace UtilizationControl with a homebrewed control for one of our customers. In this process I ran across the reference binding issue (again) since my control linked up with a custom property named “Entity” which was bound to “Me.Tagname” in the template. The control is popped up with a ShowSymbol animation when a user clicks a symbol in the line overview window.
My first naiive attempt was to try to use the custom property in the OnShow script. This did not work, so I created an “Initialize” script that was triggered by a custom property set in OnShow. That worked in most cases, but only when InTouch was able to bind references before the control was opened. When InTouch takes a few seconds to acquire bindings for an opened window, it is quite simple to click and open the popup before bindigs are complete.
So I ended up with a DataChange script attached to “Entity” and a semaphore property to indicate if the control was initialized or not. That way, initialization could be done with both an existing and a fresh binding to Me.Tagname.
I kind of like the asynchronous data model but, lacking established patterns for aaSymbol development, everyone has to find out for themselves. I wonder what will happen if/when InTouch goes WPF. Will we be able to leverage some MVVM-ish patterns?
Rick,
Looks like you ended up doing what we do. We typically have a local custom property called “Initialized”. Then on the OnShow script we set Initialized to False. Then, our initialization script is a WhileFalse on Initialized, setting Initialized to true at the bottom of the script. We got bit hard by the fact that OnShow’s are too fast to wait to hookup with anything other than a Custom Property.
… Just as I was typing this I see James from WonderwareWest has posted the release notes I was looking for. I’ve done some informal testing and it looks like if you understand the nuances this is a big step forward to help people with this OnShow issue.
- Andy
Thanks for the compliment Rick. It’s not really related, but I wish AA graphic scripts had all of the same features/config that regular object scripts had. I ran into something the other day with script timeouts. As far as I know, the only place to adjust it is in the global timeout for the whole InTouch app. I wish the AA graphic scripts could be marked as asynchronous with individual timeouts. The declarations section could potentially be useful too.
Well… ..InTouch simply has too much baggage. Mix of different technologies that require completey different patterns and practices. On top of that InTouch aspires to be both object-based and tag-based.
I hope that a great deal of the obsolete stuff gets cleaned out and I still root for C# as scripting language with Visual Studio shell as editor and debugger.
Debugger? What is that? lol.
Any of you guys been exposed to Invensys Infusion yet? I haven’t had a chance to use it or look into it at all. I’ve done lots of Foxboro I/A config but having toiled in the trenches with System Platform for the last few months, I was curious how Infusion uses the System Platform components to interface to Foxboro hardware (does it use InTouch as a front end instead of FoxDraw?).
First off let me start by saying I have absolutely no inside knowledge on the future roadmap for InTouch or any replacements. With that said a couple small nuggets I have seen in the last few months lead me to believe that the days of running InTouch just to host Archestra Graphics are numbered. Absolutely no idea what this would look like but the idea of hosting graphics in a Visual Studio like environment sure sounds neat.
The latest version of Allen Bradley controllers on the really low end have gone to using a Visual Studio style IDE.
Hoping we get a big announcement at Ops Manage? Who knows.
Maybe when IAS 3.1 SP3 Patch 1 comes out this won’t be an issue. They are aware of it.
As per the IAS 3.1.300 Read Me, OnShow Symbol Script Issue
When the OnShow Symbol Script contains external references, the data may not be available at run time due to a timing issue. Application Server 3.1 SP2 has enabled a configurable OnShow Symbol Script timeout to allow external references to resolve. The symbol will be drawn disabled and all scripts will be delayed. Once the data is available, the symbol will be enabled and the OnShow Symbol Script will execute first, followed by the rest of the scripts. If the external data does not become available within the configured timeout, the OnShow script will still execute but will place a message in the Logger that not all references have been resolved. Because named scripts will be blocked until OnShow executes, some events may be missed. For example, the named script OnDataChange will not run during the time OnShow is delayed even if the data point is changing.
Thanks for the info.
I’m think I need to test it before giving it a verdict, but my gut says that it is likely to break or deadlock in conjunction with poor or intermittent bandwidth. Given a choice I would trade this new thing for 10 pages of documentation =)
I got caught by the fact that any Galaxy attribute that is manipulated by InTouch (ie through an Archestra graphic) generates an event (usable operator action log is very important in our system). For the most part it was just a matter of replacing holding UDAs with Custom Properties in the symbols (which in hindsite is the right thing to do anyway) but it was really tedious with some of my symbols that use the SQLDataGrid to populate a large amount of data on a page. I basically had to remove the .value animation to the arrayed UDA on all the text and replace it with writing to the .text field of each element in a symbol script to reduce the garbage events in our action log (which was up to 300 lines of unecessary code in some cases).
Regarding the OnShow, I created generic symbols so that when any displayed analog value is clicked, I write the attribute name to InTouch for example “Generator1.Megawatts”, invoke a ShowSymbol and use the InTouch tag to build my references using the SetCustomPropertyValue method on about 50 custom properties in the OnShow script to show related attributes for the analog value. I first went down the path of using a UDA to hold the string attribute name but the OnShow was too fast and I would get the information for the previously clicked value. Writing the string to an InTouch tag has worked every time so far,
Yeah the whole write an event when an InTouch script updates an attribute ate our lunch too. It’s still getting us in some parts that we haven’t had a chance to get back around to.
Our workaround (at least for values that might be written constantly in a graphic) is to inspect the current value and only write a new value if different. This doesn’t help when your floods are from numerous attributes though.
This result does, however, give some nice insight into the fact that Wonderware has been smart enough to not leave a gaping security hole by letting a script from a graphic write to an attribute that a user otherwise woudl not be able to. There are obviously ways around this (i.e. write a a UDA on the object with low security then react with a script that writes to a UDA with higher security) but this would be a deliberate design not somethign done my mistake.