Page History

Devices → Tutorial | Concept | How-to Guide | Reference

Configuration Workflow

Module Configuration

Image RemovedConfiguration UI

→ Solution / Alarms / Items - tags and conditions to generate alarm. Include AlarmGroup for Ack/Log settings and AlarmArea for hierarchy.

→ Solution / Alarms / Groups - Collection of AlarmItems sharing properties such as AckRequired and LogEvents.

→ Solution / Alarms / Areas - Hierarchical grouping of AlarmGroups for better organization.

→ Solution / Alarms / Audit Trail - Logs changes and events when executing the solution, tracking who made changes and when. Useful for troubleshooting, analysis, and compliance.

Configuration Workflow

Connectivity Hub 

Native Communication 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 highly advantageous to use the native communication driver.

→ See more on 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. 

However, if you 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.

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

Configuring the Devices Module

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

Architecture Components

Channels

Protocol definitions with communication settings:

• Interface configuration (Serial/TCP/UDP)
• Timeout settings
• Remote execution options
• Connection parameters

Nodes

Physical devices on the network:

• Primary/backup station addresses
• Channel assignment
• Import synchronization
• Device-specific settings

Points

Data addresses within devices:

• Tag mapping
• Data type configuration
• Scaling/modifiers
• Access control

Communication Drivers

Native Drivers

Direct protocol implementation advantages:

• Better performance
• Advanced diagnostics
• No middleware required
• Full feature access

See → Communication Drivers for available protocols

Simulator Drivers

For testing and validation:

• TSimulator - Random value generation
• ValueSimulator - Internal driver
• OPC UA Simulator - External
• MQTTspB Simulator - External
• Modbus Simulator - External

Runtime Operation

Execution Model

The module creates optimized communication groups:

1. Groups by operand type and access pattern
2. Process per channel
3. Multiple threads per node
4. 20ms queue scanning
5. Parallel execution

Read/Write Events

AccessType controls trigger conditions:

• Timer-based polling
• Event-driven updates
• On-change writes
• Display activation

Quality Feedback

Monitor communication status:

csharp

// Tag quality (192 = good)
int quality = @Tag.Temperature.Quality;

// Node status
bool isOnline = @Device.Node.PLC1.IsOnline;

// Channel status
int status = @Device.Channel.Channel1.Status;

Monitoring and Diagnostics

Runtime Control

Control module execution:

• Run - Start communication
• Pause - Suspend temporarily
• Stop - Halt all operations

Access via Runtime → Runtime Diagnostics

Device Monitor

Real-time status at Devices → Monitor:

• Node connectivity
• Error codes
• Activity counters
• Invalid addresses

Built-in Tools

• PropertyWatch - Monitor values
• TraceWindow - Debug messages
• ModuleInformation - System status

Best Practices

System Design

• Plan modular architecture
• Separate device responsibilities
• Document configurations
• Scale appropriately

Performance Optimization

• Use OnDisplayOrServer for HMI data
• Group similar polling rates
• Optimize block sizes
• Monitor cycle times

Maintenance

• Regular software updates
• Hardware inspections
• Performance assessments
• Operator training

Common Issues

ControlLogix Configuration

PLC Type Selection:

• Default "Model OTHERS" may fail
• Select specific model (1756-L8X)
• Test communication after change

Micro850 Import:

• Use "From Filename" option
• Convert to L5K format
• Check slot configuration
• Typically requires slot 2

L5K Import Issues:

• Verify path and filename
• Try "From Filename" if device fails
• Check file format compatibility

Performance Issues

• Optimize polling rates
• Use appropriate AccessTypes
• Monitor data traffic
• Check network latency

Advanced Topics

Device Module vs TagProviders

Protocol Development

For custom drivers or advanced diagnostics:

• Understand protocol implementation
• Review driver architecture
• Test thoroughly
• Document thoroughly

See → Protocol Implementation Concepts

Troubleshooting Guide

Communication Failures:

• Check channel configuration
• Verify node addresses
• Test network connectivity
• Review error codes

Data Not Updating:

• Verify AccessType settings
• Check point configuration
• Monitor tag quality
• Review polling rates

Import Problems:

• Validate file format
• Check address syntax
• Review slot settings
• Test with simple import

Performance Degradation:

• Analyze polling rates
• Check network load
• Review group sizes
• Monitor CPU usage

In this section...

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.

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.

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.

In this section: