Built-in Namespaces Reference

Objects and Namespaces

Accessing Objects Directly in Your Solution

In most other systems, custom logic using the status of the modules or extending properties for tags requires the use of APIs and some programming.

However, our platform allows your application to directly access all the objects you created and their properties, using .NET class extensions without any configuration or programming required.

For example, if you create an Alarm Group named ProductionAlerts, it is immediately available to the solution as the property Alarm.Group.ProductionAlerts.TotalCount, which holds the number of active alarms within that group.

Another example: if you need to find the day of the year for a DateTime value, you can use the .NET class directly in the extension for the solution tags, like in Tag.StartDateTime.Value.DayOfYear.

The DayOfYear property wasn't created or programmed by our software platform, but since our tags are .NET objects, their values can naturally utilize all the .NET functionality right away.

Not only are tags .NET objects, but everything created with the solution, including alarms and database connections, are all .NET objects extending the feature.

Modules Namespaces

The platform namespaces are organized following exactly the names and organization of the Designer configuration tools. Those are the op-level objects that correspond to the main modules in the platform:

The top-level hierarchy is implemented as .NET namespaces. Each namespace includes .NET classes and objects that are created when building projects. These objects have runtime properties, methods, statuses, and configuration settings.

For instance, the Tag namespace contains every tag within an application, and each tag has built-in field properties, such as Quality, Timestamp, Min, Max, Units, etc.

Examples:

Tag.tagname1.bit0,

tag.tagname2.timestamp

The same concept of tag fields applies to all namespaces, for instance:

Alarm.TotalCount

Alarm.Group.Warning.Disable

Our platform features IntelliSense auto-completion for building projects, filling in input fields, and creating scripts. This functionality guides you to any existing properties allowed for the object you are editing and enables you to easily "drill down" to a specific property.

When accessing a project's object in the .NET Script Editor, you must prefix the namespace with an "@" symbol to avoid conflicts with the names of .NET local variables.

Examples:

In Script → Tasks and CodeBehind, you can use:

@Device.Node.Node1.Status

The at "@" symbol is not necessary on Grids and Dialogs. Some input fields may require objects of only one type, such as Tag or Display. For these, IntelliSense will automatically guide you to the required objects. 

These concepts may seem abstract for users that do not have experience in .NET or similar object-oriented systems. However, the power of these concepts will become clearer when users learn the engineering configuration tools and the platform's modules. When users get used to working with object models and Intellisense, they realize that there is a huge increase in productivity so they no longer want to work with systems that lack these features.

Namespaces API Reference

For each module, examples of the properties or methods used by that module may have been already presented, at the section "Runtime Attributes" for that module.

The complete reference of Namespaces, Classes and its Methods and properties, in a documentation environment that follows the typical organization for programming API.

Follow the link to the Namespace API Reference, to access the complete organization of the system objects.

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

In this section...