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

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

So, there is a connection between the modules (Scripts, Datasets, Report, UI clients, etc) and there is data synchronization between the Server and those modules. There is an internal queue with the data to be synchronized. The tags can be in this queue only once.

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.

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 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...