Modbus RTU over TCP Protokollkonverter gesucht

[J. V. (janvi)]

Habe hier einen ABB Stromzähler mit RS485 Ausgang und Modbus Protokoll. 
Diesen Stromzähler kann ich hier über ein USB Kabel mit FTDI Chip am PC 
anschliessen. Der PC macht nach Enumerierung ein /dev/ttyUSB0 auf, wo 
eine (fremde) Visualisierung dann auf die Zählerdaten zugreifen kann.

Nun liegt zwischen Stromzähler und PC Anwendung aber leider eine 
öffentliche Straße wo ich keine RS485 Leitung drüberlegen kann. 
Stattdesen gibt es aber ein Glasfaserkabel wo ich eine stabile und 
schnelle TCP/IP Verbindung hätte.

Leider macht ABB die Zähler aber nicht mit Modbus TCP Ausführung weshalb 
ich auf die Idee gekommen bin, hier eines der wundersamen 
Konverterkästchen einzusetzen. Allderings muß ich auf der Gegenseite 
wieder von Modbus TCP auf Modbus RTU zurück um die Daten dann über das 
USB Kabel wieder auf /dev/ttyUSB0 zu kriegen.

Hierzu irgendwelche Produktvorschläge oder Ideen ?

[Harald K. (kirnbichler)]

Mach's anders und verwende einen Ethernet-Deviceserver.
(tcp-to-serial)

Das ist erheblich günstiger und unproblematischer als eine 
Modbus-Konvertierung, nur siehst Du dann auf Deinem PC statt 
/dev/ttyUSB0 halt ein anderes serielles Device, mit dem Deine Software 
reden muss.

https://eckstein-shop.de/WaveShare-Industrial-RS232-RS485-to-Ethernet-Converter-EN

https://www.waveshare.com/rs232-485-to-eth-for-eu.htm

Alternativ kannst Du die Umsetzung auf eine serielle Schnittstelle auch 
sein lassen, und einfach einen Socket aufmachen, und über den mit dem 
Umsetzer reden.

[J. V. (janvi)]

Das ist leider nicht meine Software sondern es ist die Venus Oberfläche 
von Victron die auf einem Cerbo GX (=Raspberry Pi) läuft.

Über SSH hätte ich zwar einen Root Zugang, aber an /dev/ttyUSB0 ist ohne 
Quellen für die Anwendung vermutlich nichts zu drehen.

Einen WaveShare Converter hätte ich sogar rumliegen, aber eben kein 
Gegenstück und ich weis auch nicht wie ich das im System anpacken 
müsste.

[Christian K. (christian_rx7)]

Such bei Ali mal nach "ZLAN 5143D" laufen problemlos bei mir und 
günstiger kannst du sie selbst nicht bauen.

[Harald K. (kirnbichler)]

J. V. schrieb:
> aber an /dev/ttyUSB0 ist ohne
> Quellen für die Anwendung vermutlich nichts zu drehen


Kannst Du denn auf dem Raspberry Pi wenigstens noch eigene Software 
laufen lassen?

Dann kannst Du auch einen USB-Device-Server verwenden, der eine Art 
"virtuelle Netzwerkkarte" ist.

Das geht z.B. mit https://www.virtualhere.com/

Auf Deinem Gerät installierst Du den Client, und auf einem weiteren 
Raspberry Pi, der dann am anderen Ende der Netzwerkverbindung hängt, den 
Server.

Und dann steckst Du Deinen USB-Seriell-Adapter in den anderen Raspberry 
Pi.

[Hannes W. (hannes_w129)]

J. V. schrieb:
> Über SSH hätte ich zwar einen Root Zugang, aber an /dev/ttyUSB0 ist ohne
> Quellen für die Anwendung vermutlich nichts zu drehen.

Mit LD_PRELOAD den open() call hooken und durch ein device deiner Wahl 
ersetzen.

[J. V. (janvi)]

Bitte etwas langsamer für Dummies. Zuerst muß ich das Teil wohl zu 50 
Euro kaufen oder die Demo nehmen. Dann installieren. Vermutlich brauche 
ich dazu ein deb Paket ?

jv@JamesWebb:~$ ssh root@10.10.20.157
root@10.10.20.157's password: 
Last login: Wed Aug  9 08:33:27 2023 from 10.10.20.186
root@einstein:~# lsb_release -d
-sh: lsb_release: command not found
root@einstein:~# cat /etc/*release
cat: can't open '/etc/*release': No such file or directory
root@einstein:~# cat /etc/issue
Victron Energy v3.00 \n \l
root@einstein:~#

[Harald K. (kirnbichler)]

J. V. schrieb:
> Zuerst muß ich das Teil wohl zu 50 Euro kaufen oder die Demo nehmen.

Die Demo reicht, die kann ein USB-Gerät ansteuern, und mehr brauchst Du 
ja nicht.

Das ist das hier:
"VirtualHere USB Server for Linux (ARM) <-- Raspberry Pi, pi2, 
pi3,pi4,BeagleBone, Odroid, Angstrom, & any ARM 32-bit based Linux"

Und als Client auf Deinem Victron-Ding installierst Du den "console 
mode".

https://www.virtualhere.com/usb_client_software (weit nach unten 
scrollen).

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Sehr hochwertig aufgebaute Protokollkonverter gibt es bei Wachendorff 
Prozesstechnik bzw. ADF. Diese haben wir schon für etliche Projekte 
eingesetzt:

https://www.wachendorff-prozesstechnik.de/produktgruppen/gateways-und-protokollwandler/produkte/modbus/rtu-nach-tcp/

Die EIA-485-Schnittstelle ist hierbei auch von der Stromversorgung 
galvanisch getrennt. Der Aufbau ist sehr robust und mit einiger 
Sicherheitsbeschaltung. Technisch sind die Geräte aber nicht der 
allerneuste Schrei, sondern etwa zehn Jahre alt. Dementsprechend 
ausgereift sind sie.

Leider haben sie für die Konfiguration keine Webfrontend o.ä., sondern 
es gibt eine sehr angestaubte PC-Software, die wahlweise per EIA-232 
oder Ethernet auf den Protokollkonverter zugreifen kann.

Von Waveshare gibt es deutlich modernere ähnliche Ausführungen, aber 
eben nicht so hochwertig verarbeitet. Für eine einfache private 
Anwendung würde ich sie durchaus einsetzen. Ich habe auch einige davon 
herumliegen, die ich bezüglich ihrer Robustheit für den industriellen 
Einsatz auch noch evaluieren will.

[J. V. (janvi)]

Von Wachendorf hatte ich schon mal einen RS485 Temperaturregler auf 
Hutschiene eingesetzt. Teuer aber gut. Trotzdem gefällt mir die Software 
Lösung besser weil man da auf einer Seite keine zusätzliche Hardware 
benötigt. Ein Waveshare Teil aus Amazon habe ich hier auch rumliegen, 
weis aber nicht ob es da eine passende SW auf der Gegenseite gibt.

Um den Virtualhere Ansatz mal mit eigenen Worten zu beschreiben soweit 
ich das vertanden habe was zu tun ist: Das Paket erlaubt es, ein 
beliebiges USB Gerät auf einem anderen Rechner einzustecken und tut dann 
gegenüber der Anwendung so als ob es lokal stecken würde. In meinem Fall 
ist das USB Gerät das FTDI Kabel und vom Modbus Protokoll braucht die 
ganze Sache gar nix zu wissen.

Weil das nicht nur auf Linux läuft und ich auch gerade keine Raspi 
rumliegen habe, kann ich auf der Seite des Stromzählers zum Ausprobieren 
auch die ganz normale Windows Version auf einem beliebigen PC 
installieren und schon ist der Zähler im Ethernet mit irgendeinem 
Protokoll das mich gar nicht zu interessieren braucht. Diese Seite wird 
bei Virtualhere als Server bezeichnet.

Auf der anderen Seite (Victron) muß ich jetzt den Consol-Client 
installieren. Eine Version mit GUI ist nicht möglich, weil der 
Bildschirm exklusiv von der Venus Anwendung belegt wird. Als Download 
benötige ich Datei vhclientarmhf weil der Raspi eine ARM Prozessor hat. 
Die lege ich irgendwo in ein Verzeichnis und kann sie dort ausführbar 
machen und von der Konsole aus aufrufen.

Um erst mal sicher zu gehen, daß die Gegenseite korrekt funktioniert, 
werde ich auf jeden Fall erst mal die GUI Versionen installieren und 
ausprobieren.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

J. V. schrieb:
> und vom Modbus Protokoll braucht die
> ganze Sache gar nix zu wissen.

Doch, Modbus RTU ist etwas speziell, weil die wichtigen Informationen 
nicht nur in den übertragenen Zeichen, sondern vor allem in den 
Übertragungspausen (3,5 Zeichen) zu finden sind.

[Harald K. (kirnbichler)]

Andreas S. schrieb:
> sondern vor allem in den
> Übertragungspausen (3,5 Zeichen) zu finden sind.

Das ist die mindestens einzuhaltende Pause zwischen zwei Telegrammen. 
An längeren Pausen stört sich kein Modbusgerät. Und wenn die bisherige 
Lösung mit USB-Seriell-Wandler funktioniert, dann hat auch die 
Verlagerung des USB-Hosts keine Auswirkung, die das Einhalten dieses 
Timings beeinträchtigen würde.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Harald K. schrieb:
> Andreas S. schrieb:
>> sondern vor allem in den
>> Übertragungspausen (3,5 Zeichen) zu finden sind.
>
> Das ist die mindestens einzuhaltende Pause zwischen zwei Telegrammen.
> An längeren Pausen stört sich kein Modbusgerät.

Es stört sich aber an solchen Pausen innerhalb eines Telegrams und sieht 
diese ggf. als Telegrammende an.

Es gibt übrigens auch Geräte, die beim Mitlauschen auf dem Bus knapp 
bemessene, aber definitiv ausreichende Pausen bei der Kommunikation 
anderer Geräte mit dem Master nicht korrekt erkennen und dann selbst 
einen Fehlerstatus generieren. Das hat uns schon tagelange Fehlersuche 
eingebracht. Glücklicherweise gab es bei den entsprechenden Geräten 
(BLDC-Steuerungen von Orientalmotor) eine Möglichkeit, diese 
"Fehlererkennung" zu deaktivieren.

[Harald K. (kirnbichler)]

Andreas S. schrieb:
> Es stört sich aber an solchen Pausen innerhalb eines Telegrams und sieht
> diese ggf. als Telegrammende an.

Gut, aber so etwas wird sehr, sehr sicher nicht dadurch provoziert, daß 
die USB-Seriell-Bridge über einen Netzwerk-Device-Server angesprochen 
wird.

[J. V. (janvi)]

Habe jetzt mal versucht, hier den Server Teil zu installieren. 
Vielleicht kann mir irgend ein Linuxer sagen was ich falsch gemacht habe 
bzw. dazu machen muss um vielleicht sogar eine Bedienoberfläche zu sehen 
?

jv@JamesWebb:~$ curl https://raw.githubusercontent.com/virtualhere/script/main/install_server | sudo sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0[s100  1112  100  1112    0     0   3407      0 --:--:-- --:--:-- --:--:--  3411

Sorry, try again.
[sudo] password for jv: 
--2023-08-11 07:27:23--  https://www.virtualhere.com/sites/default/files/usbserver/vhusbdx86_64
Resolving www.virtualhere.com (www.virtualhere.com)... 143.198.145.150, 2604:a880:4:1d0::63d:5000
Connecting to www.virtualhere.com (www.virtualhere.com)|143.198.145.150|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 400612 (391K) [application/octet-stream]
Saving to: ‘vhusbdx86_64’

vhusbdx86_64                                100%[==========================================================================================>] 391,22K   545KB/s    in 0,7s    

2023-08-11 07:27:24 (545 KB/s) - ‘vhusbdx86_64’ saved [400612/400612]

Created symlink /etc/systemd/system/multi-user.target.wants/virtualhere.service → /etc/systemd/system/virtualhere.service.
jv@JamesWebb:~$ /etc/systemd/system/multi-user.target.wants/virtualhere.service
bash: /etc/systemd/system/multi-user.target.wants/virtualhere.service: Permission denied
jv@JamesWebb:~$ sudo chmod +x /etc/systemd/system/multi-user.target.wants/virtualhere.service
jv@JamesWebb:~$ /etc/systemd/system/multi-user.target.wants/virtualhere.service
/etc/systemd/system/multi-user.target.wants/virtualhere.service: line 1: [Unit]: command not found
/etc/systemd/system/multi-user.target.wants/virtualhere.service: line 2: Server: command not found
/etc/systemd/system/multi-user.target.wants/virtualhere.service: line 5: [Service]: command not found
/etc/systemd/system/multi-user.target.wants/virtualhere.service: line 7: -b: command not found
/etc/systemd/system/multi-user.target.wants/virtualhere.service: line 9: [Install]: command not found
jv@JamesWebb:~$ 
jv@JamesWebb:~$ cat /etc/systemd/system/multi-user.target.wants/virtualhere.service
[Unit]
Description=VirtualHere Server
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/sbin/vhusbdx86_64 -b -c /usr/local/etc/virtualhere/config.ini

[Install]
WantedBy=multi-user.target
jv@JamesWebb:~$ locate vhusbdx86_64
/home/jv/Downloads/vhusbdx86_64
/usr/local/sbin/vhusbdx86_64

[J. V. (janvi)]

Der Server scheint trotz aller Fehlermeldungen auf Linux zu laufen. 
Jedenfalls sehe ich auf einem Windows Client dessen USB Geräte. Man kann 
es auch einfach über die Bedienoberfläche zur Benutzung freigeben. Die 
Enumeration läuft dann so ab, also ob das Kabel am einen Rechner 
ausgesteckt und am anderen Rechner wieder eingesteckt wird und das Gerät 
funktioniert einfach entfernt.

Um es wieder am pyhsikalisch gesteckten Gerät zurück zu kriegen, muß man 
nach dem Stoppen aber das Kabel einmal abziehen und wieder einstecken.

Wie das mit dem Console Client auf Victrons Venus gehen soll muß ich 
noch rausfinden.

[J. V. (janvi)]

Die Sache mit dem Console Client scheint momentan an einem fehlenden 
Kernel Modul meiner Linux Version zu scheitern:

root@einstein:~# ./vhclientarmhf
modprobe: FATAL: Module vhci-hcd not found in directory /lib/modules/5.10.109-venus-10
Error 2 modprobing vhci, No such file or directory
root@einstein:/lib/modules/5.10.109-venus-10/kernel# modprobe vhci.hcd
modprobe: FATAL: Module vhci.hcd not found in directory /lib/modules/5.10.109-venus-10
root@einstein:/lib/modules/5.10.109-venus-10/kernel#

Habe leider keine Ahnung was das ist und wie man das herkriegt

root@einstein:/lib/modules/5.10.109-venus-10# ls
kernel                   modules.builtin.bin      modules.devname          modules.symbols.bin
modules.alias            modules.builtin.modinfo  modules.order            rtl8192eu
modules.alias.bin        modules.dep              modules.softdep          rtl8723bu
modules.builtin          modules.dep.bin          modules.symbols          rtl8723du
root@einstein:/lib/modules/5.10.109-venus-10# cd kernel
root@einstein:/lib/modules/5.10.109-venus-10/kernel# ls
crypto   drivers  fs       lib      net
root@einstein:/lib/modules/5.10.109-venus-10/kernel#

Die Quellen für die Linux Version sind hier.

https://github.com/victronenergy/venus

Ich befürchte daß ich dazu einen eigenen Kernel compilieren muß ?

[Bauform B. (bauformb)]

J. V. schrieb:
> Ich befürchte daß ich dazu einen eigenen Kernel compilieren muß ?

Nicht unbedingt den kompletten Kernel, angeblich kann man irgendwie auch 
einzelne Module kompilieren. "grep USBIP /boot/config*" liefert die 
aktuelle Konfiguration, bei einem Standard-Debian-Kernel sieht das so 
aus:

CONFIG_USBIP_CORE=m
CONFIG_USBIP_VHCI_HCD=m
CONFIG_USBIP_VHCI_HC_PORTS=15
CONFIG_USBIP_VHCI_NR_HCS=8
CONFIG_USBIP_HOST=m
CONFIG_USBIP_VUDC=m
# CONFIG_USBIP_DEBUG is not set

Aber vielleicht geht es mit Hardware doch einfacher:

J. V. schrieb:
> Ein Waveshare Teil aus Amazon habe ich hier auch rumliegen,
> weis aber nicht ob es da eine passende SW auf der Gegenseite gibt.

Hier hat jemand eine ähnliche Verbindung mit socat (aka netcat, nc, 
netcat-openbsd, netcat-traditional) aufgebaut. Theoretisch musst du nur 
sein '/dev/ttyS0' durch '/dev/ttyUSB0' ersetzen.

https://gist.github.com/Soph/cc34c539d62771b1f1cb0de3e6288f63

[J. V. (janvi)]

>Aber vielleicht geht es mit Hardware doch einfacher:

J. V. schrieb:
>> Ein Waveshare Teil aus Amazon habe ich hier auch rumliegen,
>> weis aber nicht ob es da eine passende SW auf der Gegenseite gibt.

Gibt es nicht, aber eine passende HW auf der Gegenseite. Das hat mich 
jetzt vor dem compilieren des Kernels gerettet.

Ich hatte die Teile mal zum Ausprobieren von MQTT bei 
Eckstein-Komponente bestellt. Der Shop klingt zwar deutsch, ist aber aus 
Shenzen und wird von Kung Xiang betrieben. Die Methoden zur 
Eindeutschung haben sich in China bereits großflächig rumgesprochen. Es 
ist jetzt nicht nur bei Klavieren und Schliessanlagen in Mode gekommen 
einen ausserordentlich deutsch klingenden Namen draufzuschreiben. 
(Schliessanlagen Laudmann, Klaviere Zimmermann, Linden usw. ) Entgegen 
aller Befürchtungen war sogar eine ordentliche Rechnung mit 
ausgewiesener Mwst dabei und der Preis von 29 Euro ist mehr als fair.

Das Zeugs blieb während Corona aber in den Containern stecken und konnte 
nicht geliefert werden. Als es dann doch gekommen ist, wurde es in der 
untersten Schublade eingelagert. Es handelt sich um die 
Hutschienenversion im Plastikgehäuse. Davon gibt es auch eine Version 
ohne POE. Zwischenzeitlich habe ich das Teil auch unter dem Label 
„Luckfox“ gesehen. Ob es dabei einen Unterschied gibt weis ich nicht.

https://eckstein-shop.de/WaveShare-Industrial-Serial-Server-with-POE

Das PDF Manuel ist auf der Waveshare Webseite gut versteckt. Ebenso die 
zur Inbetriebnahme benötige Konfigurationssoftware  vircom_en.exe. Die 
gibt es leider nur für Windows aber man muß froh sein daß es sie auch 
auf Englisch gibt. Es gibt zudem ein serielles Terminal sscom.exe zum 
Debuggen.

Tatsächlich hat das Teil auch einen Webserver mit Oberfläche zum 
Einstellen. Die IP Adresse wird aber in der Auslieferungseinstellung 
nicht über DHCP bezogen und ist im PDF Manual falsch beschrieben. Bei 
mir stand sie auf 192.168.1.201 und der Default nach Reset ist 
192.168.1.200. Bei der Installation von chinesischer Software die dann 
unter Windows auch noch einen Firewall Port aufmachen möchte ist mir 
grundsätzlich nicht wirklich wohl.

Hat man die IP Adresse aber mal erfolgreich erraten, geht der Zugriff 
auch über http, aber nicht https. Die chinesische Oberfläche vom 
Webserver kann man auf Englisch umschalten. Das Ändern des Device-Name 
ist mir nicht gelungen. DHCP hat aber sofort funktioniert und im Router 
erscheint als „Active Host Name“ die MAC Adresse.

Es gibt einen „Virtual Serial Port Mode“ wozu man allerdings (Windows) 
Treiber installieren muß. Somit hat sich diese Betriebsart bei Linux 
auch  erledigt. Das exe der vircom Einstellumgebung kann man ohne 
Installation direkt starten.

Außer der eigenen IP muß man mindestens eine „Destination IP“ 
einrichten. Das ist das die Gegenstelle am Ethernet, wobei serielle 
Daten hier offensichtlich auch an mehrere Gegenstellen verteilt werden 
können. Zu einer transparenten Kopplung braucht man jedenfalls nichts 
anderes tun, als die IP Adressen kreuzweise einzutragen und auszuwählen 
ob man die Übertragung per TCP oder UDP haben möchte. Bei einer 
erfolgreichen Ethernet Paarung ändern sich die Link LEDs beider Partner 
von grün auf blau. Das Teil hat außerdem eine Bootzeit von gefühlten 0 
Sekunden.

Ein weiteres Schmankerl ist die native Unterstützung des Modbus 
Protokolls was ich aber trotz Modbus nicht ausgewählt habe. In diesem 
Fall tut die Ethernet Seite so, als ob sie ein Modbus TCP Client wäre. 
Man kann dann als Anwendung einen Modbus TCP Server laufen lassen und 
direkt auf die serielle Hardware zugreifen. Leider kann das mein Venus 
nicht, zumal ABB ja auch nur Zähler mit Modbus RTU und nicht Modbus TCP 
baut.

Die Hardware zeigt auch überraschend ordentliche Merkmale. Im Innern 
werkelt ein STM32. Die galvanische Trennung ist mit gefrästem Schlitz 
als Luftstrecke realisiert. Als Überspannungsschutz zur RS485 sieht man 
sogar eine Gasentladungsstrecke. Das PoE Board hat ebenfalls einen DC/DC 
Wandler und ist senkrecht draufgesteckt. Die fast gleiche Version mit 
gleichzeitig betreibbarem zusätzlichem RS232 gibts auch noch als 
Blechgehäuse im Industrial Stil zum doppelten Preis. Bislang stabiler 
Betrieb und rundum zu empfehlen.