How to run asynchronous Scripts in Industrial graphics

Unfortunately not, in InTouch it is possible to modify the global timeout for scripts, but in OMI it is a fixed timeout (5sec), I have not found a way to change this.

So it requires you to use various methods to ensure script execution when it expected to take time, dividing your logic into multiple scripts to ensure that in completes without timeout.

Hi, in Intouch and OMI , if we use OnShow or OnTrue script is that compeltely asynchronous or does it complete within the scan cycle of when its executed ? Eg:  if tag==1 was triggered at 10:AM will it complete within the scan cycle or will it go into the next scan cycle ? Also is there a way to break the script using IF conditions ?

From what I have understood, script execution in Industrial Graphics are not to be compare to the scan based execution of an Automation Object in application server. But it does seem to have an internal execution cycle (sub ms), perhaps someone from Aveva could explain this better.
But the result is that it is OnTrue scripts will be executed without any delay.

And if a script triggers another datachange, it will branch out and trigger this additional script, before returning to the main script and continue execution.

I am not aware of any way to abort a script within execution.

So the problem we are facing is , OMI or Intouch Window viewer is slow because we want to do some client side scripting, now client side scripting cannot be done on Automation Objects or Linked Content. I think OMI or Window viewer uses only one core for its CPU resources and we are not able to run a script on an independent thread.

I wish AVEVA gives us this to run on an independent thread just like App objects so that the ViewEngine runtime can remain fast and not crash. This is a problem on multiple implementations where we would like to do client side scripting

There is no native async scripting in InTouch or in Industrial Graphics today, but it is under consideration for the future.

Some script libraries, such as the SQLData Script Library we supply with InTouch and System Platform, provide the means for an async invocation. In the case of the SQL scripts, this means that one may run async SQL queries in Indistrial Graphics which will execute on a thread that is separate from the UI thread and thereby avoid locking up the UI during lengthy operations or timeouts.

Similar things can be implemented as custom script libraries if/when needed.

Hi Rickard, having native async scripting in Industrial graphics would be extremely useful in making Intouch and System Platform more robust. We are seeing a lot more client based scripting , I previously had an assumption that I could async scripting outside industrial graphics such as App Engine objects , but customer use cases have proven me wrong that the front end user interfaces require async scripting. Custom libraries become difficult to implement and then maintain while upgrading. When you say async SQL queries is that using stored procedures or if by using SQL functions within Quickscript.NET in Industrial graphics are async by default ?

I agree wholeheartedly. Async is important.

In the clients (graphics scripts, layout scripts), the only async option is if the targeted script function supports async invocations so that one script may trigger the invocation and another script (usually periodic) checks for completion of the invocation. The SQLData script library that we ship with System Plaform and InTouch does support this pattern of invocation. See Asynchronous command script for an introduction.

Another example is method calls on objects in external data sources, which are inherently async operations. With Application Server, we support invocation of methods through OPC UA, DNP3, and IEC 60870 through a script library which also supports async invocations from syncrhonous scripts: CallMethodAsync example. 

AppEngines in Application Server are somewhat different given their inherently scan-based execution where scan overruns may cause major issues. Application Server includes a native capability to dispatch script execution to a pool of worker threads that run in parallel to the main scan-based thread. Here too, however, it is perfectly possible to use async invocations with synchronous scripts and this is typically a more efficient pattern since the thread pool for async scripts tends to be limited. Hence the examples shared above are preferable compared to making sync invocations in an async script.