I've notice some things while I have been working with faceplates and scripts. These are not necessarily problems that I need help with, though I would be pleased to have feedback in any case. Rather, I figure that there are some who would just like to know this.

1) Scripts in Faceplates: If one is using scripts in one's faceplate, it is very revealing to open the MyProject.Device.VBTXT file in one's favourite text editor. Doing so will show that each faceplate instance in a project has a corresponding instance of the script.

The appearance of the script in this file varies somewhat from that which the programmer enters into the faceplate. For one thing, dynamic property names that were coded into the script are substituted by the actual tag values that the user links them to in the engineering software (ES).

Faceplate tags are modified and, as necessary, indexed. For example, if my faceplate's script is named TestScript, in the VBTXT file, it will show up as SMI_TestScript. If multiple instances of the faceplate are extant in the project, the faceplate tags may look like SMI_TestScript_0, SMI_TestScript_1, etc.

Since my current project uses an MP370 interfaced via ethernet to an S7-200 PLC, I do not have the luxury of integrated tags/symbols. Thus each must be entered manually into the tag database. Because of this, I have been attempting to shortcut the visualization development process by using dummy tags in the faceplate's dynamic property interface, thinking that I would return to the faceplate later after I have brought in the actual tags. So, for example, I would enter a tag named DumBool for all my boolean properties, DumWord for all my unsigned integer properties, etc. A possible problem with this is that some scripting logic, particularly boolean logic, appears to require different tag names for comparisonin an If...Then programming structure. When I run a Syntax Check on my script in the faceplate editor, the script checks out just fine because the script at that point contains different property names. However, when I would attempt to compile the entire project, these property names would be replaced by SmartTags("DumBool") resulting in logic that the script compiler no longer found acceptable. Here is one example of how the faceplate script might change when the project was compiled:

Before:
If Not SmartTags("Properties\AllOK") And SmartTags("Properties\PowerOff") Then...

After:
If Not SmartTags("DumBool") And SmartTags("DumBool") Then...

I am not asserting that this particular example would cause the script compilation to fail, only something similar and as a consequence of the substitutions that the project compiler makes. Unfortunately, one of Flex's apparent weaknesses is a lack specific error diagnosis for faceplate scripts.

2) NonDynamic Graphics Lists in faceplates: I notice that when I use an object in the faceplate requiring the user to select a graphics list in the ES, after I instantiate the faceplate a time or two, and attempt to use the same graphic list that I used before, the ES notifies me of an

Error setting the value in the faceplate instance: Component not found.

This appears to be a bug, but not one that prevents compilation of the project. In fact, the warning does not appear when the project is compiled, but only when the graphic list is assigned to the instance's static property.

3) Layer Settings on Faceplate Objects: Evidently, faceplates are generated as single, standalone objects. Within the faceplate editor, the faceplateobjects can exist on several layers, but once the faceplate is intantiated, it only appears on one layer.

4) Faceplate Automation: Faceplates apparently obey many of the rules that regular objects do. This is particularly true of what is allowed to trigger scripts or system commands.

OnlyDIRECT action on a tag or object from either the user, the PLC, or possibly also an OPC device will cause events to occur.

I emphasize the DIRECTness of the action because of a problem in a faceplate that I recently worked around. The faceplate featured an internal boolean tag which controls visibility of certain objects in the faceplate. One of the buttons on the faceplate would set the visibility tag if pressed by the user. That is, the button's Released event would set to True the value of the visibility tag. The visibility tag itself had an On Change event which would call the faceplate's script.

What actually was happening was the change in the visibility tag's state, directly controlled by the user, but not the calling of the script which was an indirect action. This is evident as the objects which were to change visibility did so, but thegraphic changes commanded withinthe script did not happen. Had the PLC or user had direct control over the visibility tag, the change in value, I suspect, would have triggered the script, but as Flex currently operates, events apparently cannot be chained in such a manner.

5) Limited Object Access in Faceplate Script: Certain object properties, such as a Circle's Radius, for example, are not treated as dynamic objects. Nevertheless, I had hopes that the new Faceplate features would allow dynamic adjustment of properties such as the Circle Radius. Unfortunately, this appears to not be the case. The Radius does show up in the object properties list, but it seems that this property can only be linked to a static propery on the faceplate interface. This means that, apart from possible techniques with which I am not familiar, the faceplate script cannot change the Circle Radius at runtime.

This is one particular area where a global script has a clear advantage over the faceplate script. Properties such as the Circle's Radius can be accessed by way of the HmiRuntime object in a global script. For example, this code allows access to the Radius in runtime:

Dim MyObject

Set MyObject = HmiRuntime.Screens("TheOneIWant").ScreenItems("MyCircle")
'...
MyObject.Radius = 42 ' Think Hitchhiker's Guide
'... etc

The ScreenItem's name is defined for an object under its Properties -> Misc -> Name.

Faceplate script access to the runtime objects is one thing to add to the wish-list, though.

For the moment, that's all. I suspect, however, there may be more to come...

The Captive Engineer

Just so everyone is aware, the original message had a couple item additions since it was first posted. Hopefully, these will be pearls of wisdominstead of mere trash of trivia...

Best regards,
The Captive Engineer