Page History

Script Task

Each FactoryStudio Script Task is a thread running the typed content. It can be executed by Trigger (when a Tag value changed) or Period (configured time to run cyclically).

The whole management of execution must be done by FactoryStudio so it can do the correct management of used CPU to not allow excessive use of it. Like that, you do not compromise other modules. Also, it will do the correct control of exceptions that may happen inside of the Script Task.

Diagnostic Information

Each execution of Script Task is monitored by FactoryStudio, then it is 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.

Data Synchronization

When a script task is created utilizing certain functionalities or expressions, data synchronization may be implemented to ensure data integrity and consistency between the server and various modules. FrameworkX, functioning as a distributed software, maintains connections between different modules (scripts, datasets, reports, UI clients, etc.), orchestrating data synchronization and preventing bottlenecks, thereby guaranteeing that the most recent tag values are synchronized correctly.

In the distributed setup of FrameworkX, 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 in the computer, especially when scripting tasks or CodeBehind utilize loops to alter tag values repeatedly.

Timeout

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

Project Shutdown

During a project 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, signalling the server to initiate the shutdown process.

Pre-Loading Objects

Pre-loading objects serve as a facilitating mechanism in data synchronization, assuring 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 gets 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.

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, on 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 a subsequent startup, 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-load. Here, the user can trigger pre-load methods to force the addition of an object to the list, even if it's not in the cache or hasn't been detected by the system. This method is only executed after completing the cache-based pre-load, 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 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 preload's goal isn't 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's a higher chance of achieving better performance during the first execution of certain tasks or scripts.

In this section...