Overview
Our software platform isn't merely a robust facilitator for multitasking and security features; it also serves as a strategic bridge between client and server domains, ensuring effective distributed application management. The fundamental features of this platform lie in its ability to create customized applications that directly access project objects, simplifying the management tasks of PLC nodes, alarms, and datasets.
This platform distinctly delineates between client and server domains, fostering more efficient distributed application management. Here, the interaction between client and server processes is optimized for superior performance, with dedicated features facilitating flexible data manipulation and storage.
On this page:
Object Model and Namespaces
The platform allows your application to directly access all the objects created in your project without the necessity for temporary tags. This direct access not only eliminates unnecessary steps but also promotes a more fluid interaction with elements such as PLC nodes, alarm groups, and datasets.
It organizes the properties and methods used during application creation, dividing them into various divisions or grouping them using technical names, all housed within distinct namespaces. These namespaces, which correspond to the main modules of a project, contain unique objects, preventing duplications and ensuring a clear and concise structure.
For instance, the Tag namespace contains all the tags in the application, and each tag has built-in field properties (Quality, TimeStamp, Min, Max, Units, and many others). Examples include: Tag.tagname1.bit0, tag.tagname2.timestamp.
This concept applies to all namespaces.
Some of those built-in properties (like tag values from the PLCs) are the same on the server and client computers connected to that server, while some properties (like the currently logged user name) are specific to one client computer.
This brings us to the concept of Client-Server Domains, which is explained in the next section.
About Server-Client Namespaces
The platform has the concept of namespaces that encapsulate a set of real-time variables and methods. Two of those namespaces are @Server and @Client.
The @Server namespace holds all the information about the server computer, while the @Client namespace contains the properties of each client computer connected to the server. The properties of @Server are accessible to all project modules and to all remote computers. The values and methods for @Client are only accessible locally on that computer.
For example, @Server.Date can be used in a FactoryStudio module or display, and it will have the same value across all computers using that value. @Client.Username can be used only on displays and scripts that are local to each computer. The value of @Client.Username is local and different for each computer.
When you are running FactoryStudio on only one computer, the concept still applies, as there is one Windows process that is the SERVER process (running the Data Acquisition, Alarms, Historian, and server-side scripts) and the Windows CLIENT process (running the displays and client-side scripts).
Server and Client Tag Domains
When creating distributed applications, a TAG can have a Domain of Client or Server. A tag with a Server Domain, which is the default, will have the same value across all the modules and all client computers (some systems refer to it as a Global or Shared value for the project).
Typically, tags used to read from PLCs, communication protocols, alarm management, or a historian should be defined as Domain Server.
Tags used for temporary operator input, reference variables for dynamic user interfaces, report or query parameters, or local display data should be defined as Domain Client.
Accessing Server or Client Tags from FactoryStudio Modules
Some of the platform's modules always run on the server, some always run on the client side, and some can run on both domains.
The modules that always run on the server side are the Alarms, Historian, and Devices. This means that you should use only Server tags when defining Alarms, Historian, and Device Communication points.
Graphical Displays always run on the client domain, which means they can access both the Server Tags and the Client Tags. The difference is that the Server tags are automatically synchronized between the display and the server process (both when reading or writing to the tag). The Client tags are local to the computer running that display and are not written back to the server computer. Since it is connected with the display, the CodeBehind follows the same rule.
The SCRIPT TASKS can run on either the server side or the client side, depending on the user's choice. As expected, the script tasks assigned to run on the server computer will access only the tags that are of the Server Domain. The script tasks assigned to run on each client computer will have access to both Server and Local Tags (Global and Local data).
The SCRIPT CLASSES are methods and class libraries. You can also specify the Server or Client domain for the classes to indicate which processes can use that library.
Finally, the SCRIPT EXPRESSIONS will automatically run on the server computer or the client computer according to the tags they use. If the expression uses only Server Tags, the system will allocate it to run on the server computer. If the expression includes one or more Client Tags, it will run on each client process.
Accessing Datasets (SQL tables and Queries) from Server and Client processes
The DATASET module is accessible from both the Client and Server modules. When calling a METHOD (such as the SelectCommand()), the method is executed by the entity that calls it. Therefore, if the call is from a Display or ScriptTask of type Client, it will be executed and evaluated on the client side. If it is from a Script-Server, it will be evaluated on the server computer.
One important feature of the platform is that only the server computer needs to have the connection and security to access the SQL database, even when starting queries from the client computer. When a client-side script calls the SelectCommand(), the command is requested by a service on the server that runs the command, but the results of the query are processed on the client side.
The DATASET module also allows a command to be executed asynchronously on the server computer. Asynchronous calls are always executed on the server computer. In order to start an asynchronous action, you need to toggle (change) the value of the property, such as the Select property.
Here are the two options to run a query compared:
@Dataset.Table.table1.SelectCommand(): Will run synchronously, on the server or client domain, using the tags and results according to where they were called.
@Dataset.Table.table.Select += 1: Will run asynchronously, always on the server computer.
When configuring the Dataset Module, you must call the queries from the CLIENT process using the synchronous method to allow the system to properly evaluate the tags. This must be done when you use the mapping feature with tags of type client, or when you embed tag values in the SQL or Where conditions using the {tag.tag1} syntax with tags that are the Client type.
Using Reports from Server and Client Processes
The Report Module follows a logic similar to Datasets that are accessible from both the Server and Client processes, which resolve the tag values according to where they were activated and have an asynchronous operation that always runs on the server side.
When calling a method, such as the SaveCommand(), the method is executed by the entity that calls it. Therefore, if the call is from a Display or ScriptTask of the Client type, it will be executed and evaluated on the client side. If it is from a Script-Server, it will be evaluated on the server computer.
Saving files will always occur on the server computer, and the filename path will always be resolved on the server side, even if the command to save was initiated from the client computer.
The Report module also allows a command to be executed asynchronously on the server computer. Asynchronous calls are always executed on the server computer. In order to start an asynchronous action, you need to toggle (change) the value of the property. Here are the two options compared:
@Report.Report1.SaveCommand(): Will run synchronously, on the server or client domain, using the tags according to where they were called.
@Report.Report1.Save += 1: Will run asynchronously, always on the server computer.
You can start an asynchronous call to save a report using the SaveTrigger column and mapping it to a tag.
When configuring the Report module: If you use local tags or symbols mapping to local tags, you must call the queries from the CLIENT process using the synchronous method so the system will be able to do the proper evaluations of those tags.
Script Module and Client-Server Domains
The Script Module, despite being called scripts, consists of full-featured compiled Microsoft .NET Framework application domains.
We chose to name it "script" since all of the compiling and linking of DLLs, along with all of the .NET application domain generations, are transparently executed in the background while the user is creating the application.
Since it is a complete .NET system, it allows the paltform to automatically embed many features for performance, distributed processing, multitasking, and security when using scripts. Here are some of those features:
All scripts marked with the DOMAIN SERVER will run in their own Windows process (.NET AppDomain), which can be located on the same computer where TServer.exe is running, or they can be allocated to run on a remote computer. They can also be designated to run as threads in the same TServer.exe process.
Scripts marked with the DOMAIN CLIENT will run as independent threads in the Client process (either RichClient, SmartClient, or Web).
For enterprise projects, each script task will run in its own execution thread. Therefore, a task that requires more time to complete its execution will not block the execution of other tasks.
The system has a set of built-in protections, such as:
- All scripts created by a user have added TRY-CATCH protection. Even if code is created by the user, the script engine remains intact.
- The system prevents a task from reentrancy. If a task is still running and it is requested to run again, the execution will start only after the previous one finishes.
- The system has advanced configurations to allow creating a queue of tasks for later execution, so you do not miss any critical events.
- The system automatically creates a thread pool, which means that it controls how many parallel execution threads are optimal for the system based on the number of CPU cores available.
- Real-time data synchronization among tasks is performed by the platform's engine. Each task can use global shared variables as if they were local to its own execution thread.
Calling Server Methods from Client domains
When calling Script Class Server method from Client scripts (Script Class Client or Display CodeBehind) should add "await" (C#) "Await" (VB.NET) for HTML5 works successfully.
Examples:
C#:
public async Task DisplayOpening()
{
await @Script.Class.ServerMain.Method1();
}
VB.NET:
Public Async Function DisplayOpening() As Task
Await @Script.Class.ServerMain.Method1()
End Function
In this section...