Hallo Volker,
da ich nun eine weile mit dem Modbus rumspiele ist mir aufgefallen das es in der Konfiguration kein Punkt gibt wo ich ein auto reconnect einstellen kann.
Was ist wenn es zu Problemen kommt und der Master die Netzwerkübertragung beendet? er Startet diese nicht mehr von selber.
Aufgefallen ist das als ich eine aktuelle programmversion aus der LC3 übertragen habe. danach konnte ich den Master nicht mehr ansprechen.
Wie soll ich den Master einstellen so das er automatisch wieder eine Verbindung aufbaut?
Ich musste erst in die Pictory und den Treiber zurücksetzen um den Master wieder in Funktion zu bekommen.
wäre nicht schlecht wenn diese auto reconnect sache noch mit eingebaut wird.
gruß
Virtueller Modbus
Hallo Ingo,
wir versuchen das hier mal nahzustellen und melden uns dann wieder, sobald Ergebnisse vorliegen.
wir versuchen das hier mal nahzustellen und melden uns dann wieder, sobald Ergebnisse vorliegen.
Unser RevPi Motto: Don't just claim it - make it!
-
matthias_k
- Posts: 5
- Joined: 28 May 2019, 12:03
Hallo,
gibt es zu dem Thema evtl. Neuigkeiten? Ich finde mich leider gerade in der unglücklichen Situation, dass mein RevPi Connect (ModBus TCP Master) zwar problemlos mit einer SAIA SPS (ModBus TCP Slave) kommuniziert, im Fall eines neustart des Slave, sich aber nicht mit diesem neu verbindet. Das Systemlog zeigt mir, wie zu erwarten, den Fehlercode 0x10 für alle in PiCtory configurierten Modbus Aktionen, mir fehlt jedoch selbst jegliche handhabe diesen händisch zu beheben. Ich habe die folgenden varianten in dieser Reihenfolge erfolglos probiert:
- ModBus Register Master_Status_Reset auf über piTest auf 1 gesetzt
- piTest -x
- Reset Driver in PiCtory
- sudo /etc/init.d/networking restart
Erst ein neustart des RevPi führt zum reconnect des Masters mit dem Slave. Mache ich hier etwas grundlegends falsch? habe ich eine offensichtliche Einstellung übersehen? Ein solches Verhalten wiederspricht ja jedem produktiv Einsatz.
Das gleiche Verhalten sehe ich auch mit dem Tool MOD_RSSIM, wollte gleich auch noch mit dem QModBus Testen.
Ach ja der RevPi ist frisch geupdated
Über eine Hilfestellung wäre ich sehr Dankbar.
Beste Grüße
Matthias
gibt es zu dem Thema evtl. Neuigkeiten? Ich finde mich leider gerade in der unglücklichen Situation, dass mein RevPi Connect (ModBus TCP Master) zwar problemlos mit einer SAIA SPS (ModBus TCP Slave) kommuniziert, im Fall eines neustart des Slave, sich aber nicht mit diesem neu verbindet. Das Systemlog zeigt mir, wie zu erwarten, den Fehlercode 0x10 für alle in PiCtory configurierten Modbus Aktionen, mir fehlt jedoch selbst jegliche handhabe diesen händisch zu beheben. Ich habe die folgenden varianten in dieser Reihenfolge erfolglos probiert:
- ModBus Register Master_Status_Reset auf über piTest auf 1 gesetzt
- piTest -x
- Reset Driver in PiCtory
- sudo /etc/init.d/networking restart
Erst ein neustart des RevPi führt zum reconnect des Masters mit dem Slave. Mache ich hier etwas grundlegends falsch? habe ich eine offensichtliche Einstellung übersehen? Ein solches Verhalten wiederspricht ja jedem produktiv Einsatz.
Das gleiche Verhalten sehe ich auch mit dem Tool MOD_RSSIM, wollte gleich auch noch mit dem QModBus Testen.
Ach ja der RevPi ist frisch geupdated
Über eine Hilfestellung wäre ich sehr Dankbar.
Beste Grüße
Matthias
Hallo Matthias,
über welches Interface läuft das Modbus TCP (eth0, eth1). Kannst du den RevPi über dieses Interface noch erreichen (ping)?
Ich hatte so ähnliches Problem.
Nach dem ich die IP Adresse über die Grafische Oberfläche (startx) vergeben habe.
Hat beim mir der Modbus TCP Master nach Kabel entfernen und wieder einstecken nicht mehr funktioniert.
Das Problem war, dass der DHCP die route (route -n) gelöscht hat und nicht mehr eingetragen hat.
Die lösung war die Änderung der dhcpcd.conf Datei.
Durch den Eintrag der IP Adresse über die Grafische Oberfläche, stand in der dhcpcd.conf Datei (inform 192.168.0.20).
Durch Änderung auf static ip_address=192.168.0.20/24 läuft mein Modbus TCP Master auch nach dem abstecken und wieder einstecken des Kabels.
Gruß,
Eduard
über welches Interface läuft das Modbus TCP (eth0, eth1). Kannst du den RevPi über dieses Interface noch erreichen (ping)?
Ich hatte so ähnliches Problem.
Nach dem ich die IP Adresse über die Grafische Oberfläche (startx) vergeben habe.
Hat beim mir der Modbus TCP Master nach Kabel entfernen und wieder einstecken nicht mehr funktioniert.
Das Problem war, dass der DHCP die route (route -n) gelöscht hat und nicht mehr eingetragen hat.
Die lösung war die Änderung der dhcpcd.conf Datei.
Durch den Eintrag der IP Adresse über die Grafische Oberfläche, stand in der dhcpcd.conf Datei (inform 192.168.0.20).
Durch Änderung auf static ip_address=192.168.0.20/24 läuft mein Modbus TCP Master auch nach dem abstecken und wieder einstecken des Kabels.
Gruß,
Eduard
-
matthias_k
- Posts: 5
- Joined: 28 May 2019, 12:03
Eduard you made my day!
Tatsächlich lag genau darin auch mein Fehler. Ich hatte bis dato RevPi und SAIA Steuerung in einem Subnetz, wobei der RevPi seine Adresse (auf eth0) über DHCP erhalten hat, und die Steuerung mit einer Statischen-IP konfiguriert war. Nachdem ich dem RevPi auch eine Statische-IP vergeben habe, lief der Reconnect einwandfrei.
Ich werd mal schauen, ob ich dem eigentlichen Fehler noch mal auf den Grund gehen kann. Die Netzwerkkonfiguration eines ModBus TCP Master über DHCP ist vielleicht nicht optimal, aber sollte ja aber trotzdem zulässig sein.
Vielen Dank Eduard und beste Grüße
Matthias
Tatsächlich lag genau darin auch mein Fehler. Ich hatte bis dato RevPi und SAIA Steuerung in einem Subnetz, wobei der RevPi seine Adresse (auf eth0) über DHCP erhalten hat, und die Steuerung mit einer Statischen-IP konfiguriert war. Nachdem ich dem RevPi auch eine Statische-IP vergeben habe, lief der Reconnect einwandfrei.
Ich werd mal schauen, ob ich dem eigentlichen Fehler noch mal auf den Grund gehen kann. Die Netzwerkkonfiguration eines ModBus TCP Master über DHCP ist vielleicht nicht optimal, aber sollte ja aber trotzdem zulässig sein.
Vielen Dank Eduard und beste Grüße
Matthias
