mehrere ModBus-Geräte über Ethernet-RS485-Wandler ?

[sky64]

Hallo Spezialisten

Ich habe folgendes Problem und finde im Wiki oder den Beiträgen hier nicht die richtige Lösung:

Angefangen habe ich mit einem USB-RS485-Wandler.
Damit klappt es einwandfrei, also einen ModBus-Master an /dev/ttyUSB0 definiert und mehre ModBusAttr-Geräte definiert.
Allerdings möchte ich von dem USB-RS485-Wandler weg, da mein FHEM auf einer ESXi-VM läuft und ich es auch räumlich ändern möchte.
Aus diesem Grund habe ich einen Ethernet-RS485-Wandler aufgebaut (aus einem XP100200S-03R).
Damit ist der RS485-Port also per Ethenet verfügbar.

Laut Wiki und Doku können sowohl das modbus.pm als auch modbusattr.pm damit umgehen.
Allerdings sind die Beschreibungen vor allem beim modbus.pm unvollständig.

Ich kann ein

Code Auswählen Erweitern

define Geraet_Addr2 ModbusAttr 2 30 192.168.30.87:2003 RTU machen.
Das geht aber eben nur für ein Gerät.
ein

Code Auswählen Erweitern

define Geraet_Addr3 ModbusAttr 3 30 192.168.30.87:2003 RTU geht nicht mehr, da der Port ja bereits belegt ist.

Bei einem USB-RS485-Anschluss geht es über den ModBus-Master.
Ich kann zwar einen (weiteren) Modbus-Master mit

Code Auswählen Erweitern

define ModBusMaster_TCP ModBus 192.168.30.87:2003 definieren.
Aber ich kann nicht festlegen das dieser Anschluss RTU spricht.
Wie bringe ich dann die ModbusAttr-Geräte dazu diesen Master zu verwenden ?
Wenn ich versuche diesen TCP-Master als einzigen Master zu definieren gelingt das nicht wirklich.
In der Doku steht aber "This version of the Modbus module supports Modbus RTU and ASCII over serial / RS485 lines as well as Modbus TCP and Modbus RTU or RTU over TCP."
Es wechselt ständig zwischen open/closed wenn Abfragen durchgeführt werden.

Im Log sieht das dann so aus:

Code Auswählen Erweitern

2020.05.08 15:14:08 5: Modbus: ProcessRequestQueue called from QueueRequest returns, device is disconnected, qlen 18, try again in 1 seconds
2020.05.08 15:14:08 5: Modbus: StartQueueTimer called form ProcessRequestQueue sets internal timer to call Modbus_ProcessRequestQueue in 1.000 sec
2020.05.08 15:14:08 5: HttpUtils url=http://192.168.30.87:2003/
2020.05.08 15:14:08 4: IP: 192.168.30.87 -> 192.168.30.87
2020.05.08 15:14:08 5: Modbus: StopQueueTimer called from Open removes internal timer to call Modbus_ProcessRequestQueue
2020.05.08 15:14:08 3: 192.168.30.87:2003 reappeared (Modbus)
2020.05.08 15:14:08 5: Modbus: read buffer: fffb01fffb03
2020.05.08 15:14:08 4: Modbus: ParseFrameStart (RTU) extracted id 255, fCode 251 and data 01ff
2020.05.08 15:14:08 3: Modbus: read got new data while idle, drop buffer fffb01fffb03
2020.05.08 15:14:08 3: 192.168.30.87:2003 disconnected, waiting to reappear (Modbus)
2020.05.08 15:14:08 5: HttpUtils url=http://192.168.30.87:2003/
2020.05.08 15:14:08 4: IP: 192.168.30.87 -> 192.168.30.87
2020.05.08 15:14:08 3: 192.168.30.87:2003 reappeared (Modbus)
2020.05.08 15:14:08 5: Modbus: read buffer: fffb01fffb03
2020.05.08 15:14:08 4: Modbus: ParseFrameStart (RTU) extracted id 255, fCode 251 and data 01ff
2020.05.08 15:14:08 3: Modbus: read got new data while idle, drop buffer fffb01fffb03
2020.05.08 15:14:08 3: 192.168.30.87:2003 disconnected, waiting to reappear (Modbus)
2020.05.08 15:14:08 5: HttpUtils url=http://192.168.30.87:2003/
2020.05.08 15:14:08 4: IP: 192.168.30.87 -> 192.168.30.87
2020.05.08 15:14:08 3: 192.168.30.87:2003 reappeared (Modbus)



Wie muss ich es richtig machen oder geht das so nicht.

Gruß Ron

[Hollo]

...Aus diesem Grund habe ich einen Ethernet-RS485-Wandler aufgebaut (aus einem XP100200S-03R).
Damit ist der RS485-Port also per Ethenet verfügbar...

Wirklich?
Der genannte ,,Netzwerk-Chip" kann erstmal seriell, von RS485 sehe ich da nichts.
Selbst wenn er es könnte und du das passend implementiert hast, hast du aber nur einen RS485 zu Ethernet ,,Wandler".

Wenn du mehrere serielle Devices hast, benötigst du aber ein Modbus-Gateway.
Sonst kannst Du die Geräte dahinter nicht adressieren.
Die einfachen Wandler können das nicht, daher kannst du darüber nur 1 Device ansprechen.

Das FHEM Modul spricht dann ModbusTCP mit dem Gateway und übermittelt mit der unitID die Adresse des (seriellen) RTU-Slaves. Das Gateway wiederum leitet dann die Anfrage an das entsprechende Device weiter, und gibt die Antwort entsprechend zurück.

[sky64]

Wirklich?
Der genannte ,,Netzwerk-Chip" kann erstmal seriell, von RS485 sehe ich da nichts.
Selbst wenn er es könnte und du das passend implementiert hast, hast du aber nur einen RS485 zu Ethernet ,,Wandler".

Wie gesagt ist das wirklich nur ein Ethernet<->RS485 Wandler.
Der Aufbau ist simpel, den es wird ein passendes Steuersignal intern generiert.
Die Schaltung beschränkt sich auf einen Spannungsregler für 3,3V und einen MAX485 o.ä. RS485-Treiber
Die Pins sind 5V tolerant.

Wenn du mehrere serielle Devices hast, benötigst du aber ein Modbus-Gateway.
Sonst kannst Du die Geräte dahinter nicht adressieren.
Die einfachen Wandler können das nicht, daher kannst du darüber nur 1 Device ansprechen.

Das stimmt ja so nicht. Es geht hier im ModBus-RTU auf dem seriellen RS485-Bus.
Jedes Gerät am Modbus hat ja eine Adresse (ID). Und es gibt einen Master, entweder den USB-RS485-Stick oder eben meinen Ethernet-RS485-Wandler.
Das 98_Modbus.pm spricht am serialen Anschluss Modbus RTU und in der Beschreibung steht eben genau das was ich möchte:

Code Auswählen Erweitern

as well as Modbus TCP and Modbus RTU or RTU over TCP.
Hier geht es also um Modbus RTU over TCP.

Das funktioniert aber entweder nicht so wie angegeben oder ich mache einen Fehler den ich nicht sehe.
Warum im log diese Zeilen auftauchen ist mir unklar.

Code Auswählen Erweitern

HttpUtils url=http://192.168.30.87:2003/
Mit http kann man auf dem Port nichts anfangen.
Der Port leitet einfach alle ankomenden Bytes auf das RS485 und revers.

Das 98_ModbusAttr.pm kann nun entweder mit dem 98_Modbus.pm reden und damit können sich mehrere 98_ModbusAttr.pm diesen Anschluss teilen oder direkt "Modbus over RTU" sprechen. Das geht aber eben je Ethernetport nur einmal und hilft mir hier nicht.
Wie ich 98_ModbusAttr.pm dazu bringen kann ein 2. 98_Modbus.pm zu verwenden ist mir auch nicht klar.
Es kann ja durchaus vorkommen das man mehrere ModBus-Buse benötigt, weil sich z.B. die ID der Geräte nicht ändern lässt.

[Hollo]

...Das stimmt ja so nicht. Es geht hier im ModBus-RTU auf dem seriellen RS485-Bus.
Jedes Gerät am Modbus hat ja eine Adresse (ID). Und es gibt einen Master, entweder den USB-RS485-Stick oder eben meinen Ethernet-RS485-Wandler.
Das 98_Modbus.pm spricht am serialen Anschluss Modbus RTU und in der Beschreibung steht eben genau das was ich möchte:

Code Auswählen Erweitern

as well as Modbus TCP and Modbus RTU or RTU over TCP.
Hier geht es also um Modbus RTU over TCP...

Der Master ist aber nicht deine ,,Schnittstelle", sondern in diesem Fall das FHEM-Modul.
Die Frage an den Modulautor wäre vielleicht, was denn das ,,RTU over TCP" genau ist/macht!?
Ich habe da gerade so eine Ahnung, die das Verhalten erklären würde.
Bin da selber auch schon mal mit FHEM drüber gestolpert, habe es aus Zeitmangel dann aber nicht weiter verfolgt (also auch noch den USB-Adapter dran).

Frag doch mal bei @Stefan Strobel nach, ob da evtl. Modbus RTU raw über TCP getunnelt wird!?

...Es kann ja durchaus vorkommen das man mehrere ModBus-Buse benötigt, weil sich z.B. die ID der Geräte nicht ändern lässt.

Nicht wenn es sich um ein Gerät handelt, welches die Modbus RTU Spezifikation einhält.
Dann ist die Adresse in der Regel von 1 bis 247 einstellbar.
Mehrere Busse brauchst du, wenn sich 2 Geräte nicht auf die identische Übertragungsgeschwindigkeit einstellen lassen.

EDIT: Antwort nach nochmaligem Lesen überarbeitet, die Neugier ist geweckt.

[Hollo]

Da sich aufgrund des Titels sicher mal wieder ein Nutzer mit "ähnlichem Problem" in diesen Thread verirrt, sich der TE aber bisher nicht weiter geäußert hat, versuche ich mal noch ein paar zusätzliche Informationen hier abzulegen.

Unbestritten ist ja nur, dass es sich bei dem/den Endgerät(en) um Modbus Slaves mit seriellem Interface handelt; also Modbus RTU.

Für die "Art des Zugriffs" ist aber der zur Verfügung stehende Weg entscheidend...
- welches ist meine Schnittstelle, über die ich auf das Device zugreife
- welche Features/Protokolle bietet es mir an

1.) Zugriff über Modbus RTU
Beim Define des Gerätes wird nur die Geräteadresse und das Abfrageintervall angegeben.
Zusätzlich wird als IODev das "Interface" zugewiesen, welches vorab separat definiert wurde.

Beispiel:

Code Auswählen Erweitern

define myModbus Modbus /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_BZ03BX7G-if00-port0@9600


Code Auswählen Erweitern

define SDM220 ModbusSDM220M 1 300
attr SDM220_1 IODev myModbus


2.) Zugriff über Modbus/TCP
Anschluss RS485-Bus ueber ein echtes "Modbus RTU to TCP Gateway"; das ist ein Gateway mit Protokoll-Konverter.
Es wird also LAN-seitig nun Modbus/TCP gesprochen bzw. erwartet.

Beispiel:

Code Auswählen Erweitern

define Sensor_22 ModbusSHT20 22 120 192.168.0.75:7502 TCP

Ein Beispiel des Kommunikationsablaufes ist im Bild dargestellt.
Dabei ist schön zu sehen, wie ein TCP Request in einen RTU Request konvertiert wird; die Response dann entsprechend umgekehrt.
Zu erkennen ist auch, dass die bei Modbus RTU verwendeten Checksummen (am Ende der jeweiligen Nachricht) bei Modbus/TCP nicht vorkommen.
Das funktioniert auch mit mehreren RTU-Slaves einwandfrei.


3.) Zugriff über Modbus RTU over TCP
Hierbei werden die Daten zwar über TCP gesendet/empfangen, es handelt sich aber trotzdem um Modbus/RTU Daten.

Diese Variante ist erforderlich, wenn das zwischengeschaltete Gerät keine (Modbus-)Protokollkonvertierung vornimmt,
sondern nur eine seriell-zu-Ethernet Umsetzung vornimmt, und die Daten transparent durchleitet.
Diese Variante ist gerade im Low-Cost Bereich häufig vertreten.

Beispiel:

Code Auswählen Erweitern

define Sensor_20 ModbusSHT20 20 120 192.168.0.59:1000 RTU

Dabei ist genau darauf zu achten, was das "Gerät" überhaupt kann.
Einige können gar kein Modbus raw durchleiten, andere können die Slave ID nicht korrekt umsetzen.
Bei manchen Geräten funktioniert 1 Slave problemlos, 2 evtl. auch noch, bei mehreren gibt es ständig Probleme.
Es kann vieles funktionieren, muss es aber nicht. Verfolgt man diverse "Problem-Threads", haben viele irgendwann entnervt aufgegeben und sich ein "professionelles Gateway" geholt. Diese Variante ist daher nur unter Vorbehalt (und eigentlich nur für einzelne Slaves) zu empfehlen.