Hello, I have a charging station with two charging points. Each charging point has its own udt in the tag browser with a charging status. I have created a view that visualises the status of the charging station (one large square and a line). These change colour together when one of the charging points is in use or both (status A1 or A2), in which case I colour them green. Why: because people plug in to the wrong socket sometimes (yeah i know). When both of them are NOT in use i color them white (free). I have written a script for this. My question is: I can only link the script to one udt, so if the charging point changes from status, my script is not executed and the color doenst change. How can I ensure that my script is executed the statuses in both udts change?
Please see Wiki - how to post code on this forum.
Anyone wanting to test or modify your code would have to type it all out again.
it seems like you are trying to bind a property using an indirect tag. Use the property binding, that should fix your issue
Make 2 custom internal template properties, and add indirect bindings to bind them to the desired udt tags/members. Make an expression binding on the label that references those two internal template properties to return the desired color for the background.
You are using readBlocking() in a script. You will only get values for the corresponding tags when the script runs. The script will only run when your tag path changes.
You should add view custom properties that receive these tag values via indirect tag binding. Those properties will then be "live" instead of snapshotted at view startup.
Make a suitable expression binding to compute the coloring from the propery values, not from any readBlocking calls.
Rephrased a third time, to make the point extra explicit:
Don't use scripting if you don't have to.
Prefer direct bindings when possible. If you must use a transform, prefer 'native' transform types, followed by expression transforms, only using script transforms as a 'last resort' where their expressiveness is truly required.
In this case, two custom properties with indirect tag bindings and a third with an expression binding is the way to go. It's easier to maintain, less code to go wrong, and significantly more performant.
If you must write a script transform:
- Do not read or write anything outside of your transform scope. Use an expression structure binding if you need to deliver additional values into your transform, rather than running a blocking operation like a tag read or database write in the transform. Do not use any side effects to operate to anything else - only use the
returnvalue as output. - Never
import system(or anything from your project library) - it's unnecessary and can lead to other issues.
Thank you for this clarification. I have replaced my script with an expression for this case, and it works. Could you tell me how I can read two or more variables with updates via a script, in case this should ever be necessary in the future? Could you possibly demonstrate this with this example, even though it is NOT the correct method?
You simply cannot. Essentially all scripts in Ignition are event driven - they are run at a particular time by some mechanism out of your direct control. There's no way to set up a "watch" for another tag, especially not within your example here of a transform.
The only way to 'watch' multiple tags is to set up bindings, because 'under the hood' those bindings set up subscriptions to automatically monitor the tags for value changes. If you want to do what you were doing within a binding with no intermediate custom properties, then the way to do that would be an expressions structure binding. You could set up two outer expressions using the tag function, and then use subscripting inside the script transform to get the values at the time the transform was reevaluated. No system function would be required.
However, before Phil gets my goat -
- Don't use the
tagexpression function in an UI related context. Pretend it doesn't exist. - There's no good reason to avoid custom properties and prefer scripting here.