Control to Control Communication - Overview

[nickH]

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