Scripts Module Execution

ScriptTasks

Each ScriptTask is a thread running the code content. It can be executed by Trigger (when a tag value changes) or Period (scheduled time to run cyclically).

The management of execution is handled by the Runtime engine. As there is no limitation on the quantity or complexity of the scripts, verifying the CPU allocation is necessary when deploying a solution.

Even if you do not include .NET Exception control in your code, each ScriptTask has a Try/Catch protection automatically added around it, ensuring that no script created within the solution may compromise the system.

Diagnostic Information

Each execution of ScriptTask is monitored by the Runtime. Iis possible to know:

• Last execution (datetime).
• Last CPU time (duration to execute the Script Task).
• Peak of Last CPU time.
• Execution count.
• State (Task running or idle).
• Code exceptions.

Those properties are exposed in the object model, like Script.Task.Task1.State. Refer to the Namespace API for the list of all properties.
Some of those properties are automatically show on the Scripts Monitor page.

Data Synchronization

When a ScriptTask is created utilizing certain functionalities or expressions, data synchronization may be implemented to ensure data integrity and consistency between the server and various modules and processes that may be running on remote computers.

Our platform, designed to enable distributed applications, maintains connections between different modules (scripts, datasets, reports, UI clients, etc.) and remote client computers, orchestrating data synchronization and preventing bottlenecks, thereby guaranteeing that the most recent tag values are synchronized correctly.

In the distributed setup, there exists a server-module connection that operates across multiple computers. This connection facilitates data synchronization between the server and various modules, maintaining an internal queue that holds data pending synchronization. Each tag can occupy a single position within this queue.

In instances where a module modifies a tag value already present in the queue, only the value is updated. This system ensures the efficient management of rapidly changing tag values by prioritizing the synchronization of the latest values, thus preventing queue overflow and memory leaks.

However, specific situations necessitate the synchronization of all tag changes. In such cases, the 'RaiseAllChanges' property must be activated. It is essential to exercise caution with this function, as it might increase the synchronization queue, potentially leading to significant memory usage on the computer, especially when scripting tasks or CodeBehind utilize loops to alter tag values repeatedly.

In some advanced and large applications, when starting a remote client process, you may want to synchronize all data before starting your Operator Displays. This is accomplished by the Preload method in the Toolkit, which is described in the next topic.

Timeout

As previously noted, a 2-minute timeout exists within the server-module connection. If the synchronization of a large object, like a DataTable tag, exceeds this period, connection and synchronization issues may arise, affecting the stability of the module connections.

Solution Shutdown

During a solution shutdown, each module pauses to complete all ongoing executions. This process includes clearing the synchronization queue to prevent data loss. Following the completion of all executions and queue clearance, modules disconnect, signaling the server to initiate the shutdown process.

Pre-Loading Objects

Pre-loading objects serves as a facilitating mechanism in data synchronization, ensuring that objects are synchronized before their initial utilization in scripts or screens. This pre-loading can occur automatically or can be customized, enabling faster script execution and mitigating potential delays due to real-time data synchronization.

Upon the first usage of an object, it is enlisted in the synchronization list, triggering server notifications to facilitate client data synchronization. The pre-loading process aims to incorporate objects into the synchronization list prior to their initial usage, enhancing execution speed in synchronization-dependent contexts, such as scripts. Manual intervention can use the Toolkit Preload() method, but it is important to emphasize that it is very rare for this scenario to be necessary. For most solutions, including large ones, the automatic pre-loads executed by the platform handle the requirements.

Now, let's delve into the functioning of the automatic pre-load:

There are two contexts of use: scripts and screens. Only after finishing the pre-load in scripts are the "Script Startup" and other scripts released. In screens, the pre-load occurs simultaneously with the display. Unlike scripts, in screens, it's acceptable to show an initial value that can later be updated after receiving the synchronized value from the server.

There are two types of automatic pre-loads:

1. Based on Cache: During the first execution, since there is no cache, the pre-load is swift. Upon closing the module, the cache of the used objects is saved. On subsequent startups, the pre-load occurs from this cache. Hence, depending on interactions, the number of objects in the cache can vary, stabilizing as the objects are used more often. For example, if a module has three different scripts with three distinct tags, the maximum cache consists of these three tags. However, if only two scripts were executed upon closing the module, only two tags will be in the cache. It's crucial to note that changes in the project or module invalidate the cache, starting from scratch. The completion of the pre-load is indicated by a "marker" at the end of the list.

2. By Anticipation: During the module's execution, the system tries to anticipate the use of objects, increasing the likelihood that they are already in memory when needed. However, there are unpredictable situations, such as the use of Tk.GetObjectValue or dynamic references. If a script attempts to access a tag not yet synchronized, it pauses until synchronization occurs. For this reason, the cache-based method is often more effective after the first execution, as even dynamic objects enter the cache.

Additionally, there's customized pre-loading. Here, the user can trigger pre-load methods to force the addition of an object to the list, even if it is not in the cache or hasn't been detected by the system. This method is only executed after completing the cache-based pre-load, and it is commonly added in the Task.Startup.

Therefore, the system should be capable of pre-loading in the long run for a completed project that doesn't change by itself, which should be sufficient. However, the user can input a pre-load of objects that they insist should always be loaded, regardless of whether it's the system's first time running or not. The goal of the pre-load is not to improve the startup time; on the contrary, the more objects in the cache and pre-load, the slower the startup will be. Conversely, after initialization, there is a higher chance of achieving better performance during the first execution of certain tasks or scripts.

In this section: