Versions Compared

Old Version 298

changes.mady.by.user admin

Saved on

compared with

New Version Current

changes.mady.by.user Paulo Tsuchiya

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


HTML
<style>
.text-span-6 {
    background-image: linear-gradient(99deg, rgba(170, 163, 239, .5), rgba(125, 203, 207, .5));
    border-radius: 50px;
    padding-left: 15px;
    padding-right: 15px;
}

#title-text {
display: none;
}

.panelgradient {
    background-image: linear-gradient(180deg, #d5def0, whitesmoke);
    border-radius: 8px;
    flex-direction: column;
    justify-content: center;
    align-items: center;
    padding: 4rem;
    display: flex;
    position: relative;
}

</style>


<div class ="panelgradient">

<h1 style="text-align: center;">Devices <br> (Field Communication)</h1>

</div>



Introduction to the Devices Module

The Devices module facilitates seamless real-time communication and data exchange with various field devices and industrial protocols, supporting including standard interfaces like OPC-UA, MQTT,  MQTT and Modbus, and vendor protocols like Rockwell , and CODESYS., and an open extension toolkit created with experience is dealing with more than 200 protocols, among many others.

Included in the Devices Module:

  • IT Protocols (SNMP and Ping)
  • Connections with Historian Tools Systems (e.g., Canary, OSIsoft PI, GE Historian, InfluxDB, and and various others) 
  • 70+ Communications Communication Drivers for Industrial protocols

Image Added

On this page:

Table of Contents
maxLevel3
minLevel2
stylenone

Key Concepts 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 on in the following sections:

PanelbgColor#ffffff

Protocols

Protocols are the rules

Rules for communication between devices.

Our

The software supports

a variety of

various communication protocols.

PanelbgColor#ffffff

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

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

Panel
bgColor#ffffff

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 in the Solution Explorer, at Devices → Nodes.

Panel
bgColor#ffffff

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.

PanelbgColor#ffffff

AccessTypes

Each Point is associated with an AccessType, which defines the rules for reading and/or writing values for that Point. Some rules that can be set

are Polling

include the polling rate, whether a read is performed on startup, and whether

you write

values can be written to that Point. The AccessType allows users to configure

the way in which

how clients can access data points in the system.

Understanding the Devices Module

The Device Module collects data from the field and feeds that data it into the solution's solution’s tags. 

Module Features

  • Simplify your

    Simplifies architecture by removing the

    needing

    need 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!

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

  • Includes a built-in MQTT Broker and OPC Server

    are both built-in!

    .

  • 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 easily add

    for adding new interfaces.


Native Communication

Protocols

Drivers

Our software supports numerous communication native communication protocols for 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 very highly advantageous to have use the native communication driver.

Learn → See more on the page Native vs OPC drivers.


Driver Development and Advanced Diagnostics

When using the platform, you don't need to understand the details of the protocol implementation because you can easily map the devices and the information you want to read or write from the device with our standard tools. 

InfoIf

However, if you need to

Implement

implement new

Protocols,

protocols or

requires

require a deeper understanding of

its

their inner

working,

workings for diagnostics or optimization purposes,

see the page

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. 

• Channels: Define the protocol to Each Channel defined which protocol will be executed , and specific the settings to that select Protocols  Multiple Channels can be defined for the same Protocols (except when they need to share a common resource, such as a serial port).

To each Channel, you can define many Nodes. the Nodes are the various stations in the Field Network that will connect using the established protocol.

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 NodeFinally, to Each Node, you can define many addresses (Points) that shall be read or written to that specific device.

When the system is running, ir organize it organizes the requests maximizing for 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 of on the protocol characteristics.


Handling Read And Write Events

The AccessType configuration allows the definition if each Point (Tag and connected PLC memory Address) shall, be written or read. It allow allows to define, if the write event will happen when the tag has a new value, or based on an external trigger. The Read events are typically based on a timer (polling rate) or also triggered by the change of another variable.  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 select selected protocols.

The Communication feedback of that communication attempted is availed available on the tag Quality Property, property or in system status variables, such as Device.Node.Node1.Status

 

Devices Module vs External TagProviders

While both Devices module and ExternalTags exchange data points and their communication, the Devices module focuses on mapping local created variables with the external devices, allowing great control on define the read and write events, and diagnostics information to each address.

The External TagProvider doesn't use local tags, it establishes a dynamic communication with a remote source, allowing to browse or write directly on top of the remote data definition.

There are valid application scenarios for both approaches. In order to evaluate which option is the best for you solution requirements, as a general guideline:

Best Usage for Devices Module:

Tags are defined locally in the Solution

.

  • You want to use various Tag fields for attributes and metadata
  • You need to have clear validation if an address is no longer valid, or not available on the field. 
  • Control of the Communication, for performance of flexible, like cycle times, read and write events is important. 

    • Best Usage for TagProviders

    • You just to access (read and write) data already defined in other Systems.
    • You don't need the usage for Tag Fields and Extended Tag Properties, just the value of the variables.
    • The definition of the Data (adding new parameters, or devices, or removing) is dynamic, and the Solution must adapt without modifications to the external sources. 
    • You don't need detailed control of the communication messages or status of specific addresses.

    → Read more about External TagProviders

     

    Configuring the Devices Module

    Configuration Workflow

    The

    Device

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

    Device Module Configuration Workflow

    Action

    Where 

    Comments

    Create Channels

    Devices → / Protocols

    Select the Protocol from the List list that supports your devices and use the Create Channel Button.

    Create Channels

    Devices → / Channels

    Alternatively, you can create channels directly in the Channels table. Learn more at Devices Channels.

    Create Nodes

    Devices → / Nodes

    The nodes Nodes are the various Devices using the protocols defined at the Channel, its . Their main configuration settings is the PrimaryStation that Identifies identifies the Network address. Learn more at Devices Nodes.

    Map Tags to Point addresses

    Devices → / Points

    Map Tags or AssetTree elements to the Addresses on each field Device (Nodes). Learn more at Device Points.

    Import Addresses Definitions


    Optionally, you can Copy Tags from Excel/CSV from Excel or execute Tag Import Wizards. Learn more at Importing PLC Addresses.

    Create or Customize AccessTypes

    Devices → / AccessTypes

    Optionally, you can optimize the communication, grouping Points with similar requirements to the same AccessType. Learn more at AccessType.


    Tip

    For a typical Device configuration tutorial, Go to  Modbus Tutorial.


    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 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 value values 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. 

    Simulators 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 on 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 RemovedImage Added

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

    Using Data Quality on Displays

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

    Tip

    Data quality is a critical aspect of any HMI/SCADA system, our . Our platform allows users to incorporate data quality on into displays to provide , providing a visual representation of data reliability , and enabling operators to make well-informed decisions. This allows feature helps operators to identify potential issues and take appropriate action to maintain system performance and safety.

    At Displays ? / Client Settings, you can setup to automatically use the Quality on text outputs on displays.

     


    Devices Advanced Topics 

    Importing PLC Addresses 

    Simplify the creation of communication Nodes 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 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, intend intended to those who develop communication drivers, or requires  advanced 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.

    Info

    Read information specific to Devices Diagnostics in 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  (MATT - SHOULD WE ITALIZIE OPTIONS?) "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 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. 

    In this section:

    Page Tree
    root@self
    spacesV10

    ...