In part of a recent post, I asked about scripting on a startup.
It was agreed that this isn’t always a good idea .
Could someone please give some pointers as to the most efficient way of using tags, bindings and scripting with regards to the speed and efficiency of the gateway and also the response time of the clients?
I am using UDTs at both PLC and Designer.
I am using indirect bindings and parameters to make generic objects and tags.
I was using Client tags to identify a Client for indirect tag binding. What I was doing here was to use the startup script to get the ip address and thus make a Client tag ’ HMInumber’. I am sure I could do this on another event to avoid any problems due to the scrip not running that single time.
I am also using the page opened event to write a tag path string to a client tag. Again, cause for concern in case it doesn’t run. But again, I am sure it can run on another event.
Along with the above I was hoping for some pointers on what other people have found has worked for them.
Gateway and client settings too.
I pretty much have all of my equipment set at the default settings, plus whatever I had to change to make it work.
Any suggestions and pointers would be graciously received.
Meh. I use startup scripts often, especially when dealing with a decision tree for opening the correct parameterized window for a fixed operator station.
But then, indirect tag bindings are superior to any scripted system.tag.* operations, due to background execution. Same with query bindings. And with named queries, there's no more excuses around parameter passing.
Bindings also keep running when the designer isn't in preview mode. That's convenient, as long as you don't set up circular binding references. /:
So I not sure I'd go along with a hard rule on binding vs. scripting, other than to avoid gateway round trips in any scripts triggered by bindings (runScript is your evil buddy). I avoid gateway round trips in any foreground script that isn't directly triggered by an operator (button actionPerformed, perhaps).
What's the reason you need to write this to a client tag? Can you just use a custom property defined on the Window to hold the value?
Instead of the script, you could use a client tag with an expression binding that uses a case statement to set hmi number based on the ip address. But really, it doesn't matter if this is in a startup script or not, I don't see a benefit either way. One benefit of using the startup script is that it's a single location that everyone knows about, rather than a client tag expression that isn't as obvious.
Other things: as Phil said, don't use runScript in expression bindings in Windows, especially not to count alarms (as seen in the template provided by IA ). It's a performance killer. Use them in expression tag bindings instead.
Well, that's an overstatement of my case. I use runScript (or more often, my own objectScript) all over the place for operations that the expression language sucks at. I just don't let it work on non-local data.
runScript and objectScript are particularly handy for operations I want triggered by a single property (supplied as a dynamic arg in the expression) but needs to pull other properties' current values. Similar to what you might expect from a propertyChange event, but running even in design mode. Or like a transform in Perspective. The expression language can't do that--it'll recalculate on changes to any property in the expression.
). It's a performance killer. Use them in expression tag bindings instead.