tapping existing serial connection / bestehende serielle Kommunikation anzapfen
Posted: 05 Mar 2021, 18:43
hi there,
(Hallo zusammen, Unterhaltung und Deutsch ist kein Problem)
I was in contact with KUNBUS sales about tapping into an existing serial communication line. It could not be guaranteed that my scenario cannot be realised.
The intention is log (and analyze) additional signals without modifying the existing automation system.
The existing queries from the currently existing master shall be still served. In addition, the new master shall query additional signals. That would require that the device would query all signals and make them available to the existing and added devices.
I'm aware that if the Gateway goes down the entire communication goes down but there is no signal sent by the bus commutation all safety and control related signals are hardwired.
Going through the recommended devices: I would say it is possible but it would require two pairs of Gateways. One Gateway would act as a new intermediate Master and the other Gateway would act as the new intermediate Slave.
The new logger would read the signals to the Ethernet Interface.
Is there anyone around who tried the same or could tell if that approach is reasonable, easy to configure?
Could be there a better approach as getting two pairs of Gateways would raise the price tag, significantly in relations to only one Gateway and one RevPi.
It is not unlikely that my explanations are not that easy to understand, so I will illustrate my challenge with pictures. In the current case, a Modbu RTU connection is to be tapped, but the contribution is to be open to any kind of old-fashioned protocol.
This is the current situation but times six, as the actual project has six S7-400 HF CPU groups, each with two point-to-point connections to a Modbus RTU (RS485) slave.
The challenge is to tap the existing line but keep current communication alive, my thoughts:
(Hallo zusammen, Unterhaltung und Deutsch ist kein Problem)
I was in contact with KUNBUS sales about tapping into an existing serial communication line. It could not be guaranteed that my scenario cannot be realised.
The intention is log (and analyze) additional signals without modifying the existing automation system.
The existing queries from the currently existing master shall be still served. In addition, the new master shall query additional signals. That would require that the device would query all signals and make them available to the existing and added devices.
I'm aware that if the Gateway goes down the entire communication goes down but there is no signal sent by the bus commutation all safety and control related signals are hardwired.
Going through the recommended devices: I would say it is possible but it would require two pairs of Gateways. One Gateway would act as a new intermediate Master and the other Gateway would act as the new intermediate Slave.
The new logger would read the signals to the Ethernet Interface.
Is there anyone around who tried the same or could tell if that approach is reasonable, easy to configure?
Could be there a better approach as getting two pairs of Gateways would raise the price tag, significantly in relations to only one Gateway and one RevPi.
It is not unlikely that my explanations are not that easy to understand, so I will illustrate my challenge with pictures. In the current case, a Modbu RTU connection is to be tapped, but the contribution is to be open to any kind of old-fashioned protocol.
This is the current situation but times six, as the actual project has six S7-400 HF CPU groups, each with two point-to-point connections to a Modbus RTU (RS485) slave.
The challenge is to tap the existing line but keep current communication alive, my thoughts:
- Keep the base protocol, in this case, Modbus.
The device could just forward queries and replies but that would unnecessarily burden the line to the slaves and the slaves themselves.
So, a solution is preferred what queries the slaves and buffers the answers to provide it to the master devices upstream to itself.
- Switch over to a second IP based protocol.
The functionality is as in one “thought one” but the new line would communicate via a common protocol.
- The all-in-one solution
As mentioned earlier, there several point2point communication to be tapped I would like to reduce complexity. This either by a very simple device, outlined in “thought one” or “thought two” or going the other way and integrate all in a single device.
