Page History

Real-time communication and data exchange with field equipment using native protocols.

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

Image Added

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

• Protocols: list the various connectors available to the Device Module
• Device Channel: Add a protocol to use by Device Module, definition configuration settings as needed. 
• Device Node: a physical device, or external system, the Device Module will communicate using the Channel configuration for the protocol 
• Device Point: individual items that are read from or written tp address in the Nodes, bound to a specific tag.
• Device AccessType: to each Point, the AccessType define it that address is read only, write only, or read-write.: 

• *Channel*: Protocol instance with specific configuration settings (IP, port, timeout)
• *Node*: Physical device or external system connected through a channel
• *Point*: Individual data item (tag) mapped to a device address
• *AccessType*: Read/write permissions and scan rates for points
• *Protocol*: Communication driver for specific device types or standards

---

What It Does

• Communicates with PLCs, RTUs, and field devices using native protocols
• Manages real-time data exchange without external OPC servers
• Provides automatic tag synchronization with device addresses
• Handles multiple simultaneous protocol connections
• Monitors communication health and diagnostics
• Supports both polling and event-driven communication

Configuration Workflow

Runtime Behavior

Communication Processing

The module maintains background connections to all configured devices. Write-enabled points subscribe to tag changes and update devices automatically. Read points update based on their configured scan rates.

Diagnostics and Monitoring

• *PropertyWatch*: Verify tag values are updating correctly
• *TraceWindow*: View raw protocol communication data
• *ModuleInformation*: Monitor connection status and statistics

Native Drivers vs OPC Servers

Why Native Protocols Matter

FrameworX provides native protocol interfaces to PLCs alongside OPC client capabilities. While some PLCs use OPC UA as their built-in protocol, many scenarios benefit from direct native driver connections.

Native Driver Advantages

Higher Performance Adding an OPC server as middleware introduces additional lag time. The AccessTypes and parallel execution (multi-threading) capabilities in the Device Module enable optimized configurations not available in most OPC servers.

Extended Functionality Native Drivers provide additional capabilities. For ControlLogix and CodeSys connections, discovery methods go beyond what's available through third-party OPC gateways.

Cost Reduction Most native drivers are included at no charge. When there is a cost, it's typically much smaller than OPC server licensing.

Simplified Architecture OPC servers still require native protocol addresses for configuration - you're essentially duplicating work. The exception is when an OPC server is already installed and serving multiple applications.

Easier Field Maintenance Without an unnecessary "middle-man," deployment and maintenance procedures are simpler. A single environment with centralized support beats managing two potential failure points with independent suppliers.

When to Use OPC

• Existing OPC server infrastructure serving multiple applications
• Standardized enterprise OPC architecture requirements
• Legacy systems where OPC is the only available interface

Hybrid Approach

FrameworX can connect to field devices using native protocols while enabling its built-in OPC server functionality, allowing other applications to access data through the platform's OPC server.

Features Highlights

• Built-in MQTT Broker and OPC UA Server included
• MQTT Sparkplug B simulator for testing
• No middleware required - direct protocol implementation
• Supports edge, on-premise, and cloud deployments
• Driver Toolkit for custom protocol development
• Automatic failover and redundancy support

In this section...

Runtime Execution

When the Module Device is execution, it will start a process to keep a background communication with devices defined. All Device Points that are to be written to the devices, the device module will subscribe to be notified when that tag has a new value, to write it on the device. 

In order to understand what is happing with the communication, there are various diagnostics tools to assist in monitoring if he communication is working as expected, even that tag is not being used in any displays yet.

The PropertyWatch allows ot inspect if the values in the UNS are arriving as expected. 

The TraceWindow and ModuleInformation tool allows to all the network layer data with the device, for advanced diagnostics.

Features Highlights