Page History

Key Concepts

Below is a list of key concepts essential to understanding the Devices Module.

Protocols

and Terms

The Devices module facilitates seamless communication and data exchange with various field devices and industrial protocols, simplifying system architecture and enhancing connectivity. The configuration of the Devices module is performed in the following sections:

Protocols

Rules for Protocols are the rules governing the communication between devices. Our The software supports a variety of various communication protocols.

Channels

Channels are created and configured Configured to handle specific communication protocols and drivers. Each channel is , defined by a specific protocol driver and connection type (e.g., such as RS-232 or , TCP/IP. Channels allow the module to access multiple devices, such as PLCs, using the defined protocol and interface.

Nodes

Each device connected to the system through channels is called a Node. Nodes can be individual devices or groups of devices. Each node contains one or more Points.

Points

Points are individual items that can be read or written from/to nodes. They can be registers, I/O values, or variables residing in field devices (nodes). Each Point is bound to a specific Tag in the solution configuration.

). Multiple channels can be defined for the same protocol.

Nodes

A Node is the Device Module object that defines the settings for physical devices, using the protocol specified in the DeviceChannel. Each Node contains one or more DevicePoints.

Points

Individual items that are read from or written to Nodes, bound to a specific tag.

AccessTypes

Each Point is associated with an Access TypeAccessType, which defines the rules for reading and/or writing values for that Point. The Some rules that can be set include the polling rate value, whether a read is performed on startup, and whether you write values can be written to a specific Point are examples of rules you can specifythat Point. The Access Type AccessType allows users to configure how clients can access data points in the system.

Understanding the Devices

Module

The Device Module collects The Devices module facilitates seamless communication and data exchange with various field devices and industrial protocols, simplifying system architecture and enhancing connectivity, collecting data from the field , and feeding that data feeds it into the solution's solution’s tags.

Feature Highlights

Module Features

• Simplifies

Simplify the solution

• architecture by removing the need for additional communication products.

• Easily set up a communications hub to support communications and logic between practically any device, database, historian, or anywhere.
• The Devices Module covers On-Premise, Edge or enterprise level, and to/from the cloud.

• Supports on-premise, edge, enterprise-level, and cloud communication.

• Includes a built-in MQTT Broker and OPC Server

are both built-in to the Device module

• .

• Provides MQTT SparkPlug B and OPC-UA simulators

expedite

• for demos and prototyping.

• Features a Driver Toolkit

allows our team, or any third party, to add

• for adding new interfaces

easily

• .

Native Communication

Drivers

The Our software supports numerous communication native communication protocols for Human Machine Interface ( HMI ) and industrial device interaction.

→ See the list of available Communication Drivers.

Standard protocols, such as OPC-UA, are also included, but for many devices, it's highly advantageous to use the native communication driver.

→ See more on Native vs OPC drivers.

Driver Development and Advanced Diagnostics

. The platform also promotes open communication standards, like OPC, but there are various benefits to having the native protocol implementation. When using the platform, you don't need to understand the details of the protocol implementation details because you can easily map the devices and the information you want to read or write from the device with our standard tools. 

However, if you want to understand a communication protocol and how it is implemented in the system. In that case, you can refer to the page Protocols.need to implement new protocols or require a deeper understanding of their inner workings for diagnostics or optimization purposes, it is necessary to understand the details of protocol implementation.

→ See more at Protocol Implementation Concepts. 

Channels. Nodes and Points

When using the Devices module, you can use multiple protocols simultaneously. The selection of the protocols is explained in Device Channels.

Handling Read And Write Events

Handling read and write events in a SCADA system is crucial for efficiently exchanging data between the HMI, PLCs, and other devices. The platform facilitates these events by allowing users to configure access types, which define the specific methods for reading and writing the values of each data point. The access types can be configured to determine the polling rate, specify whether a read is performed on startup, and decide whether unsolicited input is accepted.

The Access Types page has a detailed explanation of the concepts of development and execution of communication drivers.

Devices Module And External Tags Distinctions

While the Devices module and External Tags manage data points and their communication, the Devices module focuses on field device communication. In contrast, External Tags concentrate on the overall management of tags within the platform environment.

Devices represent the physical equipment in the system. At the same time, External Tags are the logical entities that store and manage tag information. Understanding the distinction between these two components is essential for effective system configuration and management. By clearly separating the responsibilities of these components, the software promotes modularity, simplifies setup, and enables users to build scalable and maintainable solutions.

You can see External Tag Providers for more information.

Configuring the Devices Module

The basic process to configure the Device module follows the sequence below:

1. First, create channels to handle the protocols and drivers used when accessing the devices. Learn more at Device Channels.
2. Create Nodes according to the devices you will be transmitting to and receiving data from. Access the Device Nodes page to learn more about it.
3. Once your Nodes are ready, you can set Device Points bound to a specific Tag to read or write data on the Nodes. Learn more at Device Points.
4. Then, create Access Types bound to Points to set the rules for writing or reading the data. Vists the Access Types page to read more details.
5. Use the Device Monitor to supervise your Devices on Runtime. Check the Devices Monitor page for more information.

The above steps are a simplified explanation of the configuration process. For additional information on configuring the Historian module, access Configuring The Devices Module.

• Channels: Define the protocol to be executed and the settings for that protocol.

• Nodes: Stations in the field network connected via the protocol. The Node configuration selects the Channel to define the protocol and its settings. Each Node will have the mapping for one or more Points.

• Points: Addresses within Nodes that are read from or written to on each Node.

When the system is running, it organizes the requests to maximize performance by creating groups when possible or opening a process for each Channel and multiple threads for each Node.

The exact behavior is dependent on the protocol characteristics.

Handling Read And Write Events

AccessType defines the read/write rules for each point, including when write events occur (on tag value change or external trigger) and when read events occur (typically timer-based).

When a Read or Write event occurs, the platform will verify all affected Tags and Addresses, and send out the protocol messages, optimized according to the specifications of the selected protocols.

Communication feedback is available on the tag Quality property or system status variables, such as Device.Node.Node1.Status.

Configuring the Devices Module

Configuration Workflow

Simulator Drivers

The TSimulator driver is a communication protocol that allows users to generate random values in a variety of data types for testing and validation purposes. It is designed to be used with the Devices module and provides a set of flexible options that enable users to create accurate and customized simulations for their systems. TSimulator supports multiple data types, including BOOL, INTEGER, FLOAT, STRING, RAMP, and SINE. For each data type, the user can configure the minimum and maximum values that the simulation can reach, as well as other options such as string length for the STRING type or ramp step for the RAMP type.

Other simulators available:

1. ValueSimulator (internal driver)
2. OPC UA Simulator (external simulator)
3. MQTTspB Simulator (external simulator)
4. Modbus Protocol Simulator (external simulator)

Working with the Devices Module

Monitor Runtime Execution

You can control and monitor the Devices Module execution while running your solution in the Designer tool.

You can Run, Pause, or Stop the Historian module directly from the platform. Navigate to Runtime / Runtime Diagnostics to find the three buttons that you can use to control the module.

Image Added

Navigate to Devices / Monitor, to see a table with current status of all Device Nodes.

Using Data Quality on Displays

Monitors can display and utilize the data quality of communication tags to ensure that accurate and reliable information is presented to operators.

Devices Advanced Topics 

Importing PLC Addresses 

Simplify the creation of communication Nodes and Point Addresses with various methods for automatic data configuration import. Users can copy and paste tables from Excel, import data from CSV files, and employ various Import Wizards for diverse data sources. 

→ Read more about Importing PLC Addresses.

Native Driver vs OPC Server

Presents the additional set of features when using the native protocol for the Devices, instead of a third-party vendor OPC Server.

→ Read more about  Native Driver vs OPC Server

Protocol Implementation Concepts

Deeper discussion on Protocols, intended to those who develop communication drivers, or require advanced diagnostics in existing protocols. 

→ Read more about  Protocol Implementation Concepts

Devices Module vs TagProvider Connections

While both the Devices module and TagProvider Connections facilitate data exchange, they have different focuses and are applied to distinct types of interaction with data, aiming to meet different requirements.

→ Read more about Devices Module and TagProviders

Devices Runtime Attributes

The Devices Namespace exposes properties and methods from the .NET objects used by the Device Module execution. 

→ Read more on the page Devices Advanced Topics.

Anchor
BestPractices BestPractices

Best Practices and Troubleshooting 

Best Practices and Recommendations

System Design

Plan and design your industrial automation system with scalability and maintainability in mind. Use a modular approach, separating responsibilities between devices, ExternalTags, and other modules. This promotes efficient workflows and simplifies system management.

Documentation

Keep thorough documentation of your system, including device configurations, communication settings, and customizations. This will help with troubleshooting, maintenance, and future system upgrades.

Training

Ensure that operators and maintenance personnel are well-trained in using the platform and understand the specific configurations of your system. This will enable them to identify and resolve issues efficiently, minimizing system downtime.

Regular Maintenance and Updates

Schedule regular maintenance for your system, including software updates, hardware inspections, and performance assessments. This proactive approach will help to identify potential issues before they escalate, ensuring the reliability and performance of your industrial automation system.

Built-in Diagnostics tools

There are three built-in tools for diagnostics of the software solution and runtime: PropertyWatch, TraceWindow and ModuleInformation.

Common Issues and Solutions

ControlLogix PLC Type

In the PLC Address Import section under Devices / Points, it is important to ensure that the correct protocol option is selected when connecting ControlLogix PLCs. In some cases, the default option "Model OTHERS" may not work correctly, and it may be necessary to select a specific model, such as "Model 1756-L8X". If you encounter issues with a ControlLogix Channel not sending or receiving values, try changing the protocol option to the specific model and test the communication.

ControlLogix Micro850

In the current version of the driver, specifically the Micro850 model (accessed in Devices / Channels / ProtocolOptions / Model), an error occurs when importing tags into the device node using the "From Device" option, which is expected due to the way the driver's API was implemented. We have a solution for this, which involves importing using the "From Filename" option. Our platform only accepts files in the .L5K format, in the case of .xlsx files or similar, it is necessary to open them in a table editor, make the necessary modifications, and export as .CSV, which can then be imported in Solution Settings / Import Tags / CSV File.

It's important to pay attention to the slots of the nodes because, depending on the configurations, it may only work with a specific slot depending on the physical architecture of how the PLC is set up, for example slot 2.

From there, simply configure to synchronize using the "From Filename" option, and the connection will function correctly.

Importing L5K from ControlLogix

In the PLC Address Import section under Devices / Points, it is important to ensure that the path and file name are correct when importing L5K files using the "From Filename" or "From Device" options. In some cases, the "From Device" option may fail, and it may be necessary to use the "From Filename" option with the L5K file to make it work correctly.

Performance

Optimize the polling rates and access types for data points to reduce unnecessary data traffic and improve system performance. Use the OnDisplayOrServer, AccessType for efficient data reading when the application is using the data

More on the Devices Module

To learn more about the Devices module, you can use the additional documentation pages that are available.

• Learn how to use the Devices module and others by accessing the Working with the Devices Module page.

The Advanced Devices Topics page presents complementary information about the following:

• Importing PLC Addresses
• Devices Runtime attributes

Use the Devices Best Practices and Common Issues pages to our recommendation for best practices and troubleshooting guides.

In this section: