Introduction
ctrlX OS, the operating system of ctrlX CORE, is the most complete, flexible and open system in the industry. The openness and flexibility lead to many different ways to exchange data between controls (C2C). This how to blog provides an overview on the various possibilities and the respective properties.
Tip: Open this article in the full screen mode to see the table on one page.
Quick overview on the different possibilities
Type
Latency / cycle time
Connection type
Proprietary or standard
Use case
Data Layer Remote
No reliable cycle time
Depending on application on ctrlX CORE and Network traffic
1:1
Proprietary
For NRT Data Communication
Between ctrlX OS Devices
Easy to setup
OPC UA Server - Client
No reliable cycle time
See sampling and publish interval here
1:1
Standard
For NRT Data Communication
Standardized Communication (vendor independent)
OPC UA Pub/Sub
Configurable cycle time (since V2.02)
Minimal cycle time: 2ms
1:n and n:1
Standard
For RT Data and NRT Data Communication
Standardized Communication (vendor independent)
OPC UA over TSN
still to come
CODESYS Network Variable
No real time
Configurable transmission interval
1:1
Proprietary
NRT Data exchange between CODESYS based PLCs
PROFINET Controller - PROFINET Device
Configurable cycle time
1:1
Standard
Fieldbus Communication
Standardized Communication (vendor independent)
Modbus TCP
Soft real time
1:1
Standard
NRT Data exchange
Standardized Communication (vendor independent)
Bosch - DeviceBridge App
No real time communication
Transmission time depending on application, network traffic and chosen protocol
1:1
Depends on the chosen protocol
NRT Data exchange
To collect data from different sources, process it and send it further
MQTT
No real time communication
1:n
n:1
Standard
NRT Data exchange
Standardized Communication (vendor independent)
Ethernet/IP
Soft real time
1:1
Standard
NRT Data exchange
Standardized Communication (vendor independent)
TCP or UDP communication from PLC or own Snap
Depends on your own implementation
TCP: 1:1
UDP: 1:n
Self defined protocol
If you want to do everything on your own
More details and useful links
Data Layer Remote
Map the entire Data Layer into the Data Layer of another ctrlX OS
Data Layer NRT Communication via TCP
Very easy to setup
No additional App or License needed
Documentation
How To
OPC UA Server - Client
The ctrlX OPC UA Server App offers standardized and secure communication in accordance with the OPC Unified Architecture (OPC UA) standard. As an OPC UA server, the ctrlX CORE provides all connected OPC UA clients with all data from the Data Layer.
The communication is based on TCP
With the ctrlX OPC UA Client App the ctrlX CORE can access each connected OPC UA server and retrieve the provided data. The data which the OPC UA Client reads are made available in the ctrlX CORE Data Layer.
A standardized control-to-control (C2C) communication is possible. Also with 3rd party controls
OPC UA Client App [Docu] [ctrlX Store]
OPC UA Server App [Docu] [ctrlX Store]
OPC UA Pub/Sub
OPC UA Pub/Sub is the solution for efficient, with high performance and vendor independent standardized control to control (C2C) communication
The communication is based on UDP
OPC UA Pub/Sub App can publish data from the ctrlX CORE real-time Data Layer and write subscribed data to the real-time Data Layer
OPC UA Pub/Sub App [Docu] [ctrlX Store]
How to: OPC UA Pub/Sub between ctrlX CORE and S7
CODESYS Network Variable
CODESYS PLC functionality (possible for all CODESYS based PLCs)
Works via UDP Broadcast.
CODESYS online Help
(How To: still to come)
PROFINET Controller - PROFINET Device
The ctrlX CORE can act as PN-Controller with the CODESYS fieldbus libraries. This is configured in the ctrlX PLC Engineering
The ctrlX CORE plus variants can be a PN-Device with the ctrlX PROFINET Device App
PROFINET Device App [Docu] [ctrlX Store]
CODESYS Fieldbus Libraries in the ctrlX Store
How To: Connect ctrlX CORE X3 with ctrlX CORE X3 plus
Modbus TCP
Communication protocol based on Server/Client architecture
Data can be exchanged between a master and multiple slaves
Modbus can coexist simultaneously with Ethernet TCP/IP at the sam physical interface. The data are sent via TCP/IP packets.
This functionality can be implemented with codesys libraries already present in our stack
Modubs TCP App in ctrlX Store
How To: Setup Modbus TCP Communication
Bosch DeviceBridge App
The DeviceBridge can connect to a wide variety of legacy and new industrial controls (see full list in the ctrlX Store page)
In addition all major industrial communication protocols are supported (Ethernet/IP, S7, Modbus, Serial, OPC, etc.)
The DeviceBridge can not only acquire data but also manufacture data, process it and deliver it further (e.g. databases or clouds)
Bosch DeviceBridge App in the ctrlX Store
Manual of the DeviceBridge App
How To: Video
MQTT
MQTT is based on a Broker - Client architecture and commonly used in the IoT community
The communication is based on TCP
ctrlX World Apps offer MQTT Brokers for ctrlX OS
A MQTT Client can be created with a custom high programming language snap or with NodeRed
Cedalo - Eclipse Mosquitto MQTT Broker in ctrlX Store
How Tos About MQTT (Miscellaneous - 9.)
Ethernet/IP
The ctrlX CORE can act as a Ethernet/IP Scanner or Adapter device with the CODESYS fieldbus libraries.
The configuration is done in the ctrlX PLC Engineering
CODESYS Fieldbus Libraries in the ctrlX Store
TCP or UDP communication from PLC or own snap
Its also possible to setup your self defined TCP or UDP communication
... View more
