Overview
This page has information about This page provides a comprehensive overview of objects and namespaces, explaining its concepts and listing the namespaces that are defined by the fundamental concepts for effective development within the software platform.
The Reference for all classes, methods and properties of the various namespaces in on the page Namespace API.
On this page:
Table of Contents | ||||
---|---|---|---|---|
|
Introduction
to 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 With most systems, you must create custom logic for your projects and create Tags or Variables for all internal properties. Our platform allows your application to directly access all the objects that you created in your project. It means that user-created temporary tags are not required to manage the status of PLC network nodes, the total number of alarms in a group, or the number of rows in a dataset. You can now access runtime objects, business objects (representing a network node), or an alarm group or dataset. Then, you can display the required information or take action directly through the object's built-in properties.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 opFactoryStudio has an underlying .NET object model with an 100% managed code, specifically targeting the development of Real-Time data management applications. The hierarchical object model includes the following top-level objects that correspond to the main modules in the platform:
Namespace | Description |
---|---|
Tags | Real- |
Time Tags defined in Unified Namespace Tags (or AssetTree) | |
Alarm | Alarm Module |
Client | Client Station, local variable to each Client Displays User (WPF or WEB). |
Dataset | Dataset Module |
Device | Device Module |
Display |
Displays Module (holds all displays created) | |
Historian | Historian Module |
Info |
Module Info runtime objects
Info, contains generation information about the Solution | |
Report | Report Module |
Server station runtime object
Script | Script Module |
Security | Security Module |
Server | Server station |
, contains information abbot the Server Computer where the Solution is running |
Toolkit |
Toolkit Classes, additional library of methods for general use. |
The top-level hierarchy is implemented as .NET Namespacesnamespaces. Each Namespace has 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 that is in within an application, and each tag has built-in field properties, such as Quality, TimeStampTimestamp, 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 has features IntelliSense auto-completion for when you build a project, fill building projects, filling in input fields, or create and creating scripts. This functionality guides you to any existing properties that are allowed for the object you are editing and allows enables you to easily "drill down" to a specific property.
When accessing a project's object in the .NET Script Editor, it is necessary to you must prefix the namespace with an at "@" symbol in order to avoid conflict conflicts with the names of the .NET local variables.
Examples:
InScript → Tasks and CodeBehind, you can use:
Code Block | ||
---|---|---|
| ||
@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 FactoryStudio 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, to access the complete organization of the system objectsYou can see the available Namespaces on the platform here.
In this section...
Page Tree | ||||
---|---|---|---|---|
|