Page History

Purpose and Key Concepts

Below is a list of key concepts essential to understanding the Devices Module.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 on the sections:

Protocols

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

Channels

Channels are created and configured to handle specific communication protocols and drivers. Each channel is defined by a specific protocol driver and connection type, such as RS-232 or TCP/IP. Channels allow the module to access multiple devices , (such as PLCs, ) using the defined protocol and interface. The configuration of Channels is on the Solution Explorer, at Devices → Channels.

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. The configuration of Nodes is on the Solution Explorer, at Devices → Nodes.

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 Solution configuration.

AccessType

Each Point is associated with an Access TypeAccessType, which defines the rules for reading and/or writing values for that Point. The , such as the polling rate value, whether a read is performed on startup, and whether you write values 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.

Devices Functionality

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

Feature Highlights

• Simplify

• your architecture by removing the

• needing for additional communication products.

• Easily

• setup a communications hub to support

• comms and logic between practically any device, any database, any historian,

• anywhere.

• On-Premise, Edge or enterprise level, and to/from the cloud

• – we have you covered!

• MQTT Broker and OPC Server are both built-in

• !

• MQTT SparkPlug B and OPC-UA simulators expedite demos and prototyping.

• Driver Toolkit allows our team, or any third-party, to easily add new interfaces

• .

Implementing Communication Protocols

The Our software supports numerous communication protocols for Human Machine Interface ( HMI ) and industrial device interaction. The platform also promotes supports open communication standards, like OPC, but there are various benefits to in 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. However, if you want to understand have a deeper understanding of what a communication protocol is and how it is they are implemented in the system. In that case, you can refer to the page page Protocols.

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

Handling Read And Write Events

Handling In a SCADA system, handling read and write events in a SCADA system is crucial for efficiently exchanging the efficient exchange of data between the HMI, PLCs, and other devices. The platform Our software 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 page Access Types page Configuration has a detailed explanation of the concepts of development and execution of communication drivers.

Devices Module And

ExternalTags Distinctions

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

Devices represent the physical equipment in the system. At the same time, External Tags , while ExternalTags 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 our software promotes modularity, simplifies setupconfiguration, and enables users to build scalable and maintainable solutions.

You can see see External Tag ProvidersTagProviders for more information.

Configuring the Devices

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

module

The Device Modules collects data from the field and feeds that into into the solution tags. The typical workflow has the following sequence: 

Tutorials

The Device Configuration Tutorial provides a detailed guide to configuring the Modbus interface, along with the essential concepts that apply to all communication drivers. This tutorial demonstrates how to define multiple protocol interfaces using the abstraction layers, such as Channels and Nodes, provided by the platform. You will learn the differences in syntax for the STATION and ADDRESS fields when using various protocols, as well as the configuration and testing procedures that remain consistent across all communication interfaces.

The tutorial includes an overview of device configuration features, which enable users to configure and manage industrial automation devices such as PLCs, HMIs, sensors, actuators, and others. It offers a user-friendly graphical interface for adding, removing, and configuring these devices in an automation solution. You will also explore how to configure communication parameters and tags for each device, ensuring reliable and accurate communication between devices and the automation control system.

For the Device Configuration Tutorial, take a look at the Tutorial: Modbus Configuration page.

Working with the Devices module

The Devices module is an essential component that enables seamless communication between the HMI and various devices in the industrial automation system, such as PLCs and other equipment. To maximize the potential of this module, it is crucial to understand its features and capabilities in-depth.

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 allow 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 value that the simulation value can reach, as well as other options such as string length for the STRING type or ramp step for the RAMP type.

The TSimulator is an internal driver developed by Tatsoft, designed to work seamlessly with our software. In addition to the TSimulator, there are three external simulators available for integration with the platform. This makes a total of four simulators at your disposal:

1. TSimulator (internal Tatsoft driver)

2. OPC UA Simulator (external simulator)

3. MQTTspB Simulator (external simulator)

4. Modbus Protocol Simulator (external simulator)

For more information, see TSimulator Auto Generated Values.

Using Data Quality on Displays

Monitors can display and use the data quality on communication tags to ensure accurate and reliable information is being presented to operators.

Anchor
BestPractices BestPractices

Troubleshooting and Best Practices

Built-in Diagnostics tools

There are three built-in Tools for diagnostics on software framework: PropertyWatch, TraceWindow and ModuleInformation.

For information on those tools in general go to Diagnostics Tools, for specific information on levering its usage on Devices module diagnostics go to Devices Monitor.

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.

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, ExternalTagss, 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.

#Recommendation -Training

Ensure that operators and maintenance personnel are well-trained in using 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.

Device Runtime Attributes

Configure security attributes to protect critical data and ensure system integrity.

The Device namespace  is the entry point for all objects related to the Devices module. For general information on namespace and object concepts, go to the section Objects and Attributes.

The Device.Channel object lists all of the configured channels and their runtime properties.

The Device.Node object lists all of the configured nodes and their runtime properties.

The Device.AccessType object lists the defined access types and has options to execute synchronous calls on reading and writing to the device. 

The following tag properties are updated based on the Devices module:

See Namespaces Reference for the complete list of properties and available methods

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

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: