|
Anzeige
|
RS485 (Modubus RTU) Bus zur Ethernet (Modbus TCP)Hallo, ich habe einen RS485 Bus, an dem einige Zähler angeschlossen sind. Ich würde gerne über das LAN einige Werte auslesen. Es gibt ja z.B. diese Module hier: https://www.waveshare.com/rs485-to-eth-b.htm Da benötige ich aber für jedes Gerät eins dieser Module. Ist es möglich, mit einem Gerät den ganzen Bus über das LAN anzusprechen?
ModBUS ist ein Bus. Das Problem wird die Adressierung der einzelnen Zähler sein: Wenn die alle dieselbe Modbus-Adresse haben, brauchst du für jeden einen eigenen Umsetzer, der dann eine eigene IP-Adresse bekommt.
Die Adresse ist doch eindeutig im Bus? Oder verstehe ich etwas falsch?
Sollte so sein.
Oder ich. Kannst du die Dinger per serieller Schnittstelle ansprechen und jeden adressieren? Ist das System soweit vorgegeben und schon in betrieb?
Nein. Die Zähler müssen eineindeutige Modbus-Adressen haben. Das kann und muss man an den Zählern selber einstellen - werksseitig sind die alle meist auf 1 voreingestellt. Dann reicht eine Bridge pro Bus. fchk Hallo, nochmal von vorne: Ich habe insgesamt 4 Zähler, alles Eastron sdm72dm-v2 und ein esp32 am Lesekopf des Smartmeter der auch per Modbus RTU sendet und ein weiterer esp32, der Daten von einzelnen Teilnehmern holt. Alle hängen im selben Bus und haben unterschiedliche Adressen (1 bis 6). Ich möchte nun von einem rpi im Netzwerk (mit ioBroker) von den einzelnen Zählern Werte holen. Der rpi hängt im Lan. Ich brauche jetzt eine Gateway/Bridge. Gerne mit Link. Danke Mit libmodbus kannst du dir eine solche Bridge doch direkt auf dem RPi stricken. Allerdings bin ich mir nicht sicher, ob neuere RPi einen UART haben, der von Haus aus die modbus-timings (DTR/RTS-Ansteuerung also nicht per GPIO) per Hardware schafft, per Software brauchte es haessliche und eher aufwendige Klimmzuege, sonst gab es unter gewissen Szenarien alle paar Tage sporadische Fehler...
Ansonsten gibt es von FTDI (und vermutlich auch von anderen) USB-RS485-Konverter (mit Modbus-Modus).
Die Info fehlte. Es gibt auch "doofe" Geräte, die 1:1 per Modbus angesprochen werden, weil man die Adresse nicht einstellen kann (immer nur eins pro Bus möglich). Für die bräuchte man dann jeweils einen Konverter.
Ein Modbus-Slave ohne Hardware-Unterstützung macht keinen Spaß, aber der RPi als Modbus-Master muss doch nur RTS (= Driver Enable) passend einschalten? Ja, ganz trivial ist das auch nicht, aber doch kein spezielles Modbus-Problem? Mit so einem Konverter ist es noch einfacher, der weiß doch dank USB wann er seinen Sender einschalten muss. Jedenfalls, solange man weniger als 63 Byte am Stück sendet.
Hä? DerDatenversand eines Modbus-Slave ist doch Pippifax: Wenn der seine Daten gesendet hat, lauscht er wieder auf dem Bus. Und bevor er irgendwas sendet, muss er erkennen, dass die Anfrage an ihn gerichtet ist (inkl. Broadcast). Der muss nur schnell genug antworten, weil es sonst zu einem Timeout kommt. Beim Master ist es auch nicht anders. Den interessiert eigentlich alles auf dem Bus, solange er es nicht selber gesendet hat. Die Umschaltung wird bei manchen Konvertern automatisch ohne RTS-Erkennung gemacht (z.B. ICPCOM). Maxim hat(te) auch RS485-Transceiver mit automatischer Umschaltung.
Warum nicht gleich so?
Mache ich ohne Gateway. Ich habe mir auf meinem Pi 4 UART4 mit RTS/CTS hinkonfiguriert und einen MAX3483 angeklemmt. Den Rest macht libmodbus, einschließlich der Ansteuerung des RTS-Signals für DE/!RE am Transceiver. Dafür brauchts nur ein modbus_rtu_set_rts(conn->ctx, MODBUS_RTU_RTS_DOWN); Am Bus hängt ein SDM630V3 auf Adresse 1 sowie ein SDM230V2 auf Adresse 2. Funktioniert einwandfrei. fchk
Angehängte Dateien:
Nein, es ist ein Linux-Echtzeitproblem. Wenn explizit ein GPIO angesteuert werden muss, geht der Spass los. Dasselbe trifft auch fuer die FT232-Adapter zu. Nicht alle Geraete kommen mit so jitterigen Timings klar. Ist auch schon vorgekommen, dass sich der ganze Bus aufgehangen hat, und der Sensorenhersteller verwies auf die strikten Timings. Siehe auch hier: https://github.com/stephane/libmodbus/issues/606 Deswegen wurde die Industrievariante eines solchen Gateways auch mit einer CPU eindesignt, deren UART-Kern die harten Timings beherrscht. Wird vor allem dann relevant, wenn man auf hoehere Baudraten geht. Wenn deine Geräte am Modbus RTU sauber adresiert sind. Dann klappt das mit dem von dir vorgeschlagenen Gateway. Ich verwende die vermutlich baugleichen ZLAN 5143D https://www.aliexpress.com/item/1005006310914219.html . Die laufen seit über einem Jahr ohne Neustart und Probleme. Bei denen musst du nur in der Konfiguration aufpassen, dass du sie auf Modbus stellst und nicht als RS485-Konverter verwendest, dann erledigen sie auch die Protokollkonvertierung von RTU auf TCP. Großer Vorteil der Konverter, im Vergleich zur direkt am RPi angestrickten Methode, ist dass du sie einfach per PC debuggen kannst, da sie mehrerer parallele TCP Verbindungen unterstützen.
Das Hauptproblem dabei ist gar nicht mal die Latenz des Multitasking-Betriebssystems, sondern dass man durch den FIFO im UART und sonstiges Buffering nicht weiss, wann das letzte Byte tatsächlich gesendet wurde. Unter Windows habe ich seinerzeit den Empfänger eingeschaltet gelassen und das eigene Echo mitgelesen, das funktionierte recht gut.
Der FT232 entschärft das o.g. Problem, indem er sich selbst um die Umschaltung kümmert. Für einen standardkonformen Modbus-Master reicht das aus, im Slave-Betrieb könnte ein ungeduldiger Master Probleme bereiten. schau mal hier, da hast es quasi fix und fertig: https://espeasy.readthedocs.io/en/latest/Plugin/P078.html Es braucht dann einen ESPxx, einen RS485 Umsetzer, diese ESPEasy-Software Du kannst dann direkt in ESPEasy die gewünschten Werte per Webinterface auswählen iDe Abfrage von IOBroker ist dann sehr einfach, z.B. auch per MQTT Schau Dir auch das mal an: https://www.smarthome-tricks.de/esp8266/espeasy-datenaustausch-mit-iobroker/
Ja, das Timing von Modbus/RTU ist knapp (3.5 Bytezeiten als Minimalpause zwischen zwei Telegrammen. Wenn man nicht mit Waffengewalt dazu gezwungen wird, ungeeignete UARTs zur Ansteuerung zu verwenden, lässt man das besser sein.
Das ist Humbug. Der FT232 enthält Hardwareunterstützung für die Sender-/Empfänger-Umschaltung eines RS485-Treibers und ist /vollkommen/ ausreichend, um als Master-, aber auch als Slave-Device mit Modbus/RTU verwendet zu werden
Wieso? Der Slave gibt vor, wie schnell er antwortet, da darf ein Master nicht "ungeduldig" werden. Sieh Dir mal an, was in https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf zum Thema Timeout steht (z.B. auf S.10/44).
Das ist alles schoen und gut, bringt nur nix, wenn ein USB-Bus dazwischenhaengt. Zuverlaessigen Slave-Betrieb bekommt man damit mit einem Standard-Linux sowieso nicht hin, und knifflige Timings in dichten Netzen werden dann problematisch, wenn mehrere Master und anstaendig viele Knoten (hier 32) vorliegen. Been there...
Theoretisch ja. In der Praxis lässt "long enough for any slave to process the request" Platz für Probleme, wenn man z.B. einen bestehenden Slave durch ein eigenes Gerät ersetzt. Aber abgesehen von solchen Murks-Szenarien sehe ich keinen Fall, wo ein FT232-Adapter mit Hardware-TX/RX-Umschaltung Probleme bereiten sollte. Als Master sowieso nicht.
Aha. Wer ist "man", und warum sollte das so sein? Hast Du das irgendwo gelesen?
Offenbar jemand, der auf wilde Ideen kommt, die eher nach CAN schreien:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
