Using runScript in Perspective

Hello All,

I was looking for some feedback on any implications of using runScript with a set poll rate in a Perspective session. I know this was problematic in a Vision client as it required a round trip to the gateway on each execution. Will this execute efficiently in a perspective session since it is running on the gateway itself?

Thanks,

Frank

Yes, it’s a little more efficient because you don’t have the roundtrip over the network, but you still need to be careful that you don’t end up with long-running scripts being executed. It will inflate the Perspective worker thread count and delay other things from happening in that session until it completes.

No, runScript itself doesn’t require a round trip. But numerous popular system.* functions do. That is/was the hazard in Vision. Also, some of those functions can have very long run times. That is still a hazard for Perspective.

1 Like

I am specifically interested in using it to call a project script that accepts a source path string and returns whether an acked or unacked alarm is active in that path. Using this to show alarm conditions around the hmi.

Thanks,

Frank

A naive implementation is going to use a system function that recurses through the tag tree to find active alarms. That’s fine for shallow trees and small systems, but won’t scale well. If you want to scale, you’ll arrange one or more alarm pipelines that call out to a project script module that caches status in a persistent jython data structure (dictionaries and nested dictionaries, in particular). That eliminates the recursion, but does require careful initialization of the caching hierarchy.

I very much like this idea but when you want to pass a source that either contains many alarms or alarms associated with a single piece of equipment it would get quite cumbersome. Unless you knew ahead of time the exact structure to which you would want to determine alarm status, unfortunately I do not have that luxury on the project I am involved with.

No, caching can be used without any prior structure setup. I would build the hierarchy from the alarm events passed from the pipeline.