If I am inside a script in a Perspective view object, is there anyway to get the details of a tag that is bound to a parameter on that object?
What I think I want is the equivalent of system.tag.getConfiguration that works on a bound parameter rather than a string path to a tag, but I can't seem to recognize what that function would be within the System Functions.
No such thing. If you need such at runtime, use an indirect tag binding, and just look at the property feeding the indirection.
(It is possible in Vision with SDK apis, but nothing like that is accessible for Perspective.)
I'm guessing you mean use an indirect binding with no indirection parameters, but I can't quite see the relevance. So pretend that I'm really dumb today, what does that mean in terms of being in a Perspective script?
Object or component?
I'm not sure of the correct terminology here, but the architecture is:
At this point I can bind a tag to the surfaced Param A. In my script all the way back on View #1, I want to get same the details of the tag that I would have got using the tag path and system.tag.getConfiguration.
I know that I am likely doing Bad Things™, but I would like to get these details because I am trying to make View #1 into a robust library object, so I want to gather information in case the person making the binding has .. shall we say .. not chosen the correct means of configuration.
My current solution is that instead of binding a tag to Param A, I instead copy the path of the tag, and paste that in as a static value of Param A and then insert the value of Param A into a call to getConfiguration(). Which, while it works, is Ugly™ and I want to see if I can eliminate that ugliness.
OK, to summarise, I think your setup is as follows:
- View
- Embedded view component
- path : View#1
- param : ParamA
where ParamA is working as a tag path in text format but you would like it to accept a tag binding instead but still be able to access all the tag's properties.
Yes, that is correct. From within a script running on View#1
But was hoping not to have to explain everything in order to avoid confusion. However, I apparently failed at that .. lol
Ok. Still no. You cannot introspect a tag binding in Perspective to get the tag path. You are stuck with Ugly™.
Furthermore, View #1 has no knowledge/access to the view in which it is embedded. For its parameters, it just gets parameter values. There's no difference within View#1 whether the parent view is supplying a constant, or values and updates from bindings, or value updates from scripts.
Perspective does not have any concept of traversing view encapsulation boundaries, like you can with Vision Windows and Templates. So even if Perspective offered a way to interrogate a tag binding, only the parent view could do so.
Keep it simple.
Name the View#1 parameter clearly so that it's obvious that it only accepts a string path. e.g.,
tagPathString : [default]MyFolder/MyTag
I already do that, and I am pointing it out in documentation. But part of the problem is that I have multiple parameters, and only one of them requires this treatment, and I hate inconsistency.
The other part is that there is a lot of emphasis on bindings in Perspective, so it's going to be easy to slip up and bind something to ParamA instead of paste in the path value.
However, I just realized that if someone does bind to ParamA, then the call to getConfiguration() is likely going to fail, so I will have some advanced warning that things aren't going well. I just need to figure out how best to indicate that to the user (I'm thinking of something like the Quality overlay system)
Well, they might bind an expression that yields a dynamic tag path. Which your embedded view should handle just fine, as long as it is smart enough to accept changing tag paths at runtime.
But keep in mind that if they don't supply a tag path, then the entire usage within the embedded view will fail. Any indirect bindings using the bogus tagpath will fail, and give you your overlay.
FWIW, I think your use of getConfiguration is unwise. You should simply indirect bind the tagpath with the .PropertyName suffix to obtain the current value of interest to your nested view. No concern with supplying default values. And no heavyweight scripting. (Don't use scripts where you don't need them.)
If you have a large set of properties of interest, perhaps with multiple tags within a folder tagpath, you might find my tags() function helpful (from my Integration Toolkit).
Remember I mentioned doing Bad Things™? I am deliberately abusing system.opc.writeValue(), which requires knowing that the tag I am pointing to is an OPC tag, and getConfiguration() provides me with all the information I need for that function. If the tag is not an OPC tag (EG Memory) then I am abusing another set of functions: system.tag.write...()
But the abuse is needed (and I have tested the abusive and non-abusive versions of what I want to do). However, note that this not for a production system, but instead a hardware simulation test system where I can accept abusing Ignition in order to achieve what I need.
Yeah, and the specific properties needed can be indirect bound instead. My point still stands.
No excuse. Arguably a hardware simulation system is simply a production tool for QA of your other development systems, so I dispute your label for it, whether relevant or not.
Well, in this case, you will have to suck it up and use the Ugly™ way, because Perspective strictly encapsulates its views.
You could argue that, but then you'd need to explain to me how I can fit about 15 or 20 full sized cabinets in my 10 x 12 home office, along with a full selection of remote I/O connected via various Ethernet and Profinet cables, and an 11kV supply.
At some point in testing I have to make trade-offs when you are testing software for a 80m high crane, because there is no QA other than the fully constructed and wired up device.
Where'd you get that strawman? I didn't say you shouldn't be emulating/simulating your hardware. I was saying that your emulation/simulation is itself a production system for your development pointed at it.