Page History

Object Model and Namespaces

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

Organizes 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 has 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 tags tag values from the PLCs) are the same in on the server and client computers that are connected with to that server, but while some properties (like the current 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

In FactoryStudio, we have The platform has the concept of namespaces that encapsulates encapsulate a set of real-time variables and methods. Two of those namespaces are @Server and @Client@Client.

The @Server namespace holds all the information about the server computer, while the @Client namespace has contains the properties of each client computer connected with to the server. The properties of @Server properties are accessible to all project modules and to all remote computers. The values and methods for the @Client are only accessible locally at on that computer.

For Exampleexample, @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 a DISPLAY displays and Scripts scripts that are local to each computer. The value of @Client.Username is local and different to for each computer.

When you are running FactoryStudio on only a one computer, the concept still applies, as there is one Windows process that is the SERVER Process process (running the DataAcquisitionData Acquisition, Alarms, Historian, and Server server-side scripts) and the Windows CLIENT process (running the displays and client-side scripts).

Server and Client Tag Domains

When creating distributed applications, FactoryStudio has the concept that a TAG can have a Domain of Client or Server. A Tag 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 to for the project).

Typically, tags you are using used to read from PLCs, Communication communication protocols, Alarm Managementalarm management, or a Historian historian should be defined as Domain Server.

Tags you are using used for temporary operator Inputinput, reference variables to for dynamic user interfaceinterfaces, reports report or queries query parameters, or local display data should be defined as Domain Client.

Accessing Server or Client Tags from FactoryStudio Modules

FactoryStudio has some modules that Some of the platform's modules always run on the Serverserver, some that always run on the client side, and some that can run on both domains.

The Modules modules that always are run on the Server server side are the Alarms, Historian, and Devices. This means that you should use only Server tags when you are defining Alarms, Historian, and Device Communication points.

Graphical Displays always run on the client domain, which means they can access BOTH both the Server Tags and the Client Tags. The difference is that the Server tags are automatically synchronized between the Display display and the server process (both when reading or writing to the tag). The Client Tags tags are local to the computer running that display . The Client tags 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 server side or the Client side according to client side, depending on the user's choice. As expected, the Script-Tasks that are script tasks assigned to run on the Server server computer will access only the Tags tags that are of the Server Domain Server. The Script-Tasks that are 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 to for the classes to specify indicate which processes can use that library.

Finally, the SCRIPT EXPRESSIONS will automatically run in on the Server server computer or in the Client client computer according to the Tags it usestags they use. If the expression is using uses only Server Tags, the system will allocate it automatically to run it in on the server computer. If the Expression had expression includes one or more Client tagTags, it would will run at 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 who calls the methodthe 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 server computer needs to have the connection and security to access the SQL database, even when starting queries on from the client computer. When a client-side script calls the SelectCommand(), the command is requested by a FactoryStudio 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 executed on the Server server computer. Asynchronously 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.

Using Reports from

Server and

Client Processes

The Report module Module follows a logic similar do to Datasets that are accessible form from both the Server and Client processprocesses, which resolve the tag values according to where they were activated and have an asynchronous operation that always run runs on the server side.

When calling a Methodmethod, such as the SaveCommand(), the method is executed by who calls the methodthe 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 save occur on the server computer, or and the filename path will always be resolved on the server side, even if the command to save was started initiated from the client computer.

The Report module also allows a command to be executed asynchronously executed on the Server server computer. Asynchronously 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.

Script Module and Client-Server Domains

FactoryStudio The Script Module, despite being called scripts, are consists of full-featured complied compiled Microsoft .NET Framework Application application domains.

We elected chose to name it "script" since all of the compiling and linking of DLLs and , along with all of the .NET application domain generations, are transparently executed to the user in the background while the user is creating the application.

Since it is a complete .NET system, it allowed FactoryStudio 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 of the Scripts scripts created by a user have an added TRY-CATCH protection. Even if code is created by the user, the script engine remains intact.
• The system prevents a Task task from reentrancy. If a Task 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 eventevents.
• The system automatically creates a tread-pollthread pool, which means that it automatically controls how many parallel execution threads is are optimal on for the system , based on how many the number of CPU cores your system hasavailable.
• Real-time data synchronization among tasks is performed by the FactoryStudio platform's engine. Each task can use global shared variables , as if it was they were local to its own execution thread.

In this section...