Page History

ScriptTasks

Each FactoryStudio Script Task ScriptTask is a thread running the typed code content. It can be executed by Trigger (when a Tag tag value changedchanges) or Period (configured scheduled 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 Taskis 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 Script Task ScriptTask is monitored by FactoryStudio, then it is 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

FactoryStudio is a distributed software, i.e., there is a Server and the modules can run distributed in many computers.

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, reportsSo, there is a connection between the modules (Scripts, Datasets, Report, UI clients, etc.) and there is 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 server and those modules. There is various modules, maintaining an internal queue with the data to be synchronized. The tags can be in this queue only once.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 If a module updates a tag value that is already in the queue, only the value is updated, then this is a queue of last values of tags to be synchronized between Server and modules. When a tag changes values too fast, oftentimes it does not mean that all the values will be synchronized with the Server, but for sure the last value will be. This way, we can guarantee that the queue does not blow out or there is not a memory leak, because the queue will have a maximum amount of tags in a project.. 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

There are a few cases where the project must synchronize all the tag changes.

In this case, the Tag property RaiseAllChanges must be enabled. However, you need to pay attention: if there are more value changes that the system can synchronize, it will increase the synchronization queue and may cause excessive use of memory in the computer. If you create a Script Task or CodeBehind using a For / While and change the tag value inside of it and use the RaiseAllChanges property enabled, it may have this behavior.

Timeout

As explained before, there is a connection between the Server and modules, then there is a timeout of 2min in this connection. In case there is a large object as a Datatable tag to be synchronized and it takes more than 2min to synchronize this timeout will be exceeded and will have an issue in the connection/synchronization of the modules.

Project Shutdown

When a project is shutdown, each module waits for all executions to be finished. Then, there is a flush in the synchronization queue to make sure no tag value will be lost. After finishing all the executions, the queue is empty and the module is closed, closing the connection with the Server. At the Server side, only after all modules are disconnected that it is shutdown.

Pre-Loading Objects

When an object is used for the first time, it is added to the synchronization list. Then, the server is notified and sends this object to the client, performing the data synchronization. The pre-load aims to insert the object into the synchronization list before its first use. Thus, when used in contexts that require synchronization, such as scripts, execution is faster since synchronization has already occurred. There are two ways of pre-loading: the automatic one, performed by the system, and the TK.PreloadObject, where the user can force synchronization.

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 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 cacheCache: 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 startupstartups, 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 anticipationAnticipation: 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-loadloading. Here, the user can trigger pre-load methods to force the addition of an object to the list, even if it 's 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 preload's goal isn't 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 's is a higher chance of achieving better performance during the first execution of certain tasks or scripts.

In this section

: