You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 162 Next »

Introduction to Devices module

The Devices module implements real-item data communication with a wide variety of field devices and industrial protocols.

The Devices module supports standard interfaces like OPC-UA, OPC-DA and MQTT, Hart, and many proprietary protocols to various PLCs manufacturers.

The connectivity also includes IT protocols, like SNMP and Ping, and connection with Historian tools, such as OSIsoft PI, GE Historian, InfluxDB and Canary.

Currently around 50 drivers are included at no extra charge in the platform, and our development team has experience with more than 200 communication protocols.

On this page:


Purpose and Key Concepts

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, Channels, Nodes, Points, and AccessType.

Protocols

Protocols are the rules governing the communication between devices. Our software supports a variety of communication protocols, both native and OPC-based. The selection of Protocols to use in your specific Project is on the Project Explorer, at Devices → Protocols.

Channels

The Devices module uses Channels to establish connections with field devices. 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 Project 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 Project 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 Project configuration.

AccessType

Each Point is associated with an AccessType, which defines the rules for reading and writing values for that Point, such as the polling rate, whether a read is performed on startup, and whether you write values to that Point. The AccessType allows users to configure how clients can access data points in the system.


Understanding the Devices module 

This section expelling the execution and features of the Devices module, organize in the the following topics:

Features 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

Our software supports numerous communication protocols for HMI and industrial device interaction. The platform also supports open communication standards, like OPC, but there are various benefits in having the native protocol implementation.

When using plataform, you don't need to understand the details of the protocol implementation, because you just can easily just map the devices and the information you want to read or write from the device. But, you want to have the deleted understating on what is a communication protocol, and how they are implemented in the system, you can refer to the page access Protocol Implementation Concepts.

When using the Devices module, you can use multiple protocols simultaneously. The selection of the protocols is explained on the section Communication Protocol Selection.

Organizing Devices in Channels and Nodes

To maintain an organized and efficient communication structure, devices are grouped into channels based on their communication protocol and settings, and further organized into nodes representing individual devices or stations.

Channels are responsible for managing communication protocols and drivers, while Nodes handle multiple threads pointing to the configured Channels. Understanding the relationship between Channels and Nodes is essential for efficient data exchange.

  • Channels: execute processes based on communication protocols and drivers, configuring the required protocol or driver for a specific device.
  • Nodes: perform multiple threads pointing to the Channels, ensuring efficient data exchange and minimizing latency.


Channels

Channels are created and configured to handle specific communication protocols and drivers. Nodes, in turn, manage multiple threads pointing to these Channels. This multi-threaded approach ensures efficient data exchange and reduces latency, allowing the system to scale and handle numerous devices simultaneously.

Nodes

Nodes are the devices or PLCs on the network that you communicate with. You can enter the settings for your nodes as usual through the Engineering Workspace. You can also import settings from an OPC server or from another data source. For more information on importing PLC addresses, go to:  Importing PLC Addresses.

Organizing Data Blocks with AccessTypes

AccessTypes are used to group data points with similar communication requirements, optimizing the data exchange process between platform and field devices.

Points are groups that point to Nodes and are responsible for transferring information between configured devices and our software. AccessTypes are used to define the specific methods for reading and writing data point values at specific moments using polling. The number of data points you can configure is related to both the ProductModel that is configured for the project and your software license. This approach allows for optimized data exchange and minimizes latency.

  • Points: groups pointing to Nodes, responsible for transferring information between configured devices and our software.
  • AccessTypes: define specific methods for reading and writing data point values at specific moments using polling

Handling Read and Write Events

In a SCADA system, handling read and write events is crucial for the efficient exchange of data between the HMI, PLCs, and other devices. 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 Configuration has a detailed explanation on the concepts of development and execution of communication drivers.

Devices module and LinkedTag Distinctions

While both Devices module and LinkedTag manage data points and their communication, the Devices module focuses on field device communication, whereas LinkedTag focuses on the overall management of tags within the platform environment.

Devices represent the physical equipment in the system, while LinkedTags 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, our software promotes modularity, simplifies configuration, and enables users to build scalable and maintainable solutions.


Configuring the Devices module

In this section, we'll guide you through FactoryStudio's Devices module configuration, including management of channels, nodes, and points, protocol gateway setup, and AccessType customization. Additionally, we'll reference practical tutorials for a more detailed understanding of specific topics like Modbus and OPC interfaces.

Configuration Workflow

  • Select a communication protocol

  • Define device channels and their settings

  • Define nodes and stations

  • Add and edit device points

  • Customize pre-defined AccessTypes (if necessary)

Managing Channels, Nodes and Points

In FactoryStudio, managing channels, nodes, and points is crucial for establishing communication between the HMI and the system devices. This section briefly covers how to create and manage device channels, nodes, and points:

  • Device Channels: Create and manage channels by navigating to Devices → Channels and providing the required information.
  • Nodes: Configure nodes by going to Devices → Nodes and entering or selecting the necessary details. You can also import settings from an OPC server or another data source.
  • Points: Configure data points by going to Devices → Points and entering or selecting the appropriate information.

For the Device Configuration, take a look at the Device Configuration page.

Creating and Managing Channels

In FactoryStudio, device channels facilitate communication between the HMI and system devices. To efficiently create and manage these channels, adhere to the following process:

  • To create a new channel, navigate to Devices → Channels and click on "New Channel" Fill in the necessary information in the "Create New Channel" window and confirm by clicking "OK." The new channel will appear as a row in the table.
  • To edit existing channels, return to Devices → Channels. Customize the table by adding or removing columns through right-clicking the column heading area and selecting the desired columns. Modify the appropriate fields in the corresponding row to make adjustments to the channel.

To learn more about remote execution, see Remote Execution.

To learn more about Simulator Driver, explore TSimulator Auto Generated Values.

Defining Nodes and Stations

In FactoryStudio, configuring nodes involves defining devices or PLCs for network communication. To configure nodes, go to Devices → Nodes and input the required information. Columns can be added or removed by right-clicking the column heading area. Device node configuration properties include Name, Channel, PrimaryStation, BackupStation, SyncDate, SyncStation, SyncSettings, TemplateID and Description, each serving a specific purpose. For protocol-specific settings, consult the documentation Creating Nodes.

Adding and Editing Device Points

Adding and editing points in FactoryStudio involves configuring data points linked to nodes, which are accessible through tags. To configure data points, navigate to Devices → Points and input the required information. Columns can be added or removed by right-clicking the column heading area. Key device points configuration properties include TagName, Node, Address, DataType, Modifiers, AccessType, Scaling, TemplateID and Label. For protocol-specific settings, consult the documentation Adding and Editing Points.

Customizing Pre-defined AccessTypes

Customizing predefined AccessTypes in FactoryStudio allows users to optimize data exchange methods for reading and writing data point values. To configure AccessTypes, go to Devices → AccessTypes and either edit an existing access type by double-clicking a field or create a new one by clicking "New Item..." Input the required information. The OnDisplayOrServer AccessType efficiently reads data when used by the application. For more information, visit the OnDisplayOrServer AccessType section.

Protocol Gateway Configuration

Configure Protocol Gateways to enable communication between different devices using different protocols, or to bridge between different networks.

Tutorials

The Device Configuration Tutorial provides a detailed guide to configuring the Modbus and OPC interfaces, 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 FactoryStudio. 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 in FactoryStudio, 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 project. 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 Device Configuration Tutorials page.

The page covers various topics such as Modbus Master, Modbus with multi-serial interfaces, Modbus on TCP/IP networks, OPC Client, importing settings from an OPC Server, importing PLC addresses and external tag definitions, and using diagnostic tools like Property Watch, Trace Window, and Module Information. This comprehensive guide will help you to effectively configure devices in your industrial automation projects, resulting in safe and efficient operations.


Working with the Devices module

The Devices module in FactoryStudio 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.

Runtime Execution

During runtime execution, the Devices module manages all aspects of communication between the HMI and the devices in the industrial automation system. This includes establishing and maintaining connections, handling read and write requests, and processing data quality and device status information. Proper configuration and optimization of the Devices module are critical for ensuring seamless data exchange, minimal latency, and optimal system performance. The Devices module supports a wide range of communication protocols, making it adaptable to diverse devices and systems.

Executable Process, ports, Diagram, data flow

The Devices module, once in execution, enables an event-driven data exchange between the HMI and the connected devices, facilitating seamless communication.

The section Execute offers detailed guidance on initiating and halting the execution of the project.

The Runtime Environment section provides comprehensive information on all the processes and aspects when the solution is running. This includes the use of ports for communication, the diagram representing the system's configuration and connections, and the flow of data between the HMI and the devices.

For in-depth details on the Devices module's executable processes, please refer to the Devices module Execution page.

OPC Server and Client Tools

OPC (OLE for Process Control) is a well-established communication standard in the industrial automation sector that enables the exchange of data between different software applications and hardware devices. This standard provides a cohesive and platform-independent interface, simplifying the integration process and promoting interoperability. The OPC Foundation is responsible for the development and maintenance of this technology. For more information about OPC, access the detailed content at: OPC Integration.

FactoryStudio and OPC Technology

FactoryStudio natively supports OPC technology, allowing users to establish communication with a multitude of OPC servers and clients, thus simplifying the process of integration with different systems.

Native Communication Drivers

Connectivity is a critical feature. FactoryStudio includes a wide range of industry-standard protocols, allowing integrated communications with PLCs, historians, databases, and other devices. New drivers are continually being added, and our SDK makes it easy to add any additional driver not included.

To learn more about the Native Communication Drivers vs OPC, access Native Driver vs OPC Server.

Support for OPC Clients and Servers

The FactoryStudio platform is fully compliant with the specifications of the OPC Server and Client. The OPC client provides all the necessary integrations for any protocol not included with the product.

Remote Data Servers: Drivers, whether native or OPC, and data acquisition can be run on remote computers to perform tasks such as retrieving data from RS-232 devices or eliminating the need for OPC DCOM configuration.

OPC Data Server FactoryStudio Station

FactoryStudio can be deployed as a standalone OPC Data Server that uses native protocols and provides data to other systems via its OPC Server interface.

Automatic Synchronization: FactoryStudio provides a Tag Import Wizard and automatic synchronization of definitions for OPC Servers, making it easier to manage and maintain your settings.

To learn about the Import Tag Wizards, visit Import Tag Wizards.

OPC Server in FactoryStudio

FactoryStudio has an integrated OPC server that allows continuous communication with OPC clients. To configure the OPC server, follow the device configuration guidelines at: Setup the OPC Server. You can monitor the execution and status of the OPC server through the Data Explorer tool, ensuring appropriate communication with the connected OPC clients.

To learn more about how to import from an OPC Server, visit: Importing from an OPC Server.

OPC Client in FactoryStudio

FactoryStudio offers several drivers for OPC clients, allowing communication with different OPC servers. The available drivers include OPC UA, OPC HDA UA, OPC HD, and OPC Xml/DA. To configure these drivers, follow the specific documentation of device connection settings and address syntax for each driver, available at Communication Drivers. This will allow you to establish and monitor communication with the desired OPC servers. To read more about OPC UA access OPC.

MQTT Tools

Introducing MQTT Integration and Simulation for IIoT Applications

In today's increasingly connected world, the Industrial Internet of Things (IIoT) plays a critical role in streamlining communication between devices, systems, and networks. To facilitate seamless data transmission, our software platform integrates MQTT (Message Queuing Telemetry Transport), a lightweight messaging protocol designed for resource-constrained environments. This section offers a comprehensive guide to implementing MQTT, including setting up the HiveMQ Broker, using the MQTTspB Simulator, and accessing elements in the Engineering Environment with the Unified Namespace.

The HiveMQ Broker is a powerful MQTT broker designed for IIoT applications, enabling reliable and scalable business-critical IIoT systems, fast data delivery, efficient use of resources, and secure integration of IIoT data into enterprise systems. The integration of HiveMQ with Tatsoft's FrameworX offers a robust and scalable solution for your IIoT needs. For more information on HiveMQ Broker, please visit: HiveMQ Broker.

The MQTTspB Simulator allows users to simulate MQTT devices and publish messages to a broker for testing and development purposes. It supports connecting to both local and remote brokers and enables customization of Topic parameters, NodeIDs, and DeviceIDs. Furthermore, the simulator provides options for creating multiple NodeIDs and DeviceIDs, as well as modifying their attributes using a configuration file. For more information on the application requirements, supported features, configuration file management, and application settings, please visit MQTTspB Simulator.

The Unified Namespace, a centralized data repository, enables users to access elements from an MQTT Broker data model in any area of the Engineering Environment. This advanced feature allows for seamless integration of MQTT variables directly into your displays, alarms, or historian tables without the need to create separate tags and communication points. For more information on system requirements, device configuration, and accessing elements in the Engineering Environment using MQTT variables, as well as asset modeling to import Data Structures into your project, please visit: MQTT and Unified Namespace.

In summary, FrameworX is a comprehensive resource for implementing and utilizing MQTT integration in IIoT applications. It covers setting up the HiveMQ Broker, simulating MQTT devices with the MQTTspB Simulator, and leveraging the Unified Namespace to access elements from an MQTT Broker data model. For detailed information, please refer to the corresponding sections within the document and on the pages MQTT and Built-in MQTT Broker.

For detailed information on how to install and use the MQTTspB Client URCap for real Universal Robots or Universal Robots Simulator applications (URSim), please visit Universal Robots - MQTTspB URCaps.

Simulation Drivers

The TSimulator simulation 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 FactoryStudio 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 FactoryStudio. 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 read access TSimulator Auto Generated Values.

For read more access Tutorial: Modbus Configuration.

Using Data Quality on Displays

Monitor and visualize data quality on displays to ensure accurate and reliable information is being presented to operators.

Data quality is a critical aspect of any HMI/SCADA system, as it ensures that operators receive reliable and accurate information about the process. FactoryStudio allows users to incorporate data quality on displays to provide a visual representation of data reliability, enabling operators to make well-informed decisions. This allows operators to identify potential issues and take appropriate action to maintain system performance and safety. (Add dica to Tooltip options)


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 Using Diagnostics Tools with Devices.

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. FactoryStudio 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 Project 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, LinkedTags, 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 FactoryStudio 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:

Example
tag.tagName.DevicePointDevice point address connected with this tag.

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


In this section...

The root page @parent could not be found in space v10.



  • No labels