Hallo,
wie bereits schon telefonisch eingeleitet hier die Support-Anfrage bzgl. Modbus RTU Masterfähigkeit des RevPi:
Das Inbetriebnehmen scheint nicht zu greifen. Vorgeschichte / ausgeführte Aktivitäten:
* Der RevPi Core 3 wurde ca. im Dezember geliefert (mit Jessie drauf). Zuallererst mal habe ich dann bei erstmaliger Befassung damit alles mittels apt-get update / upgrade auf den neuesten Stand gebracht (am 5.3.2018). Da wurde einiges heruntergeladen, wohl auch an Kernel-updates u. RevPi firmware-updates?
* Danach habe ich noch mal explizit mit "sudo apt-get install revpi-firmware" nachgelegt. Da kam dann (erwartbar) nichts mehr nach.
* Dann erstmal Herunterfahren u. Anschluss der Hardware: Über den einfachen USB-RS485 Dongle aus dem Shop per 2-Draht Leitung (AB nicht vertauscht). Der Modbus slave ist eine Eigenentwicklung, die mit Holding Registers arbeitet. Bei Austesten per QModbusMaster in Windows läuft alles einwandfrei, der slave hat auch eine LED, die erfolgreiche Modbus-Aktivität anzeigt. Genau derselbe dongle samt Verdrahtung u. slave dann in den RevPi. Ground des RevPi u. der slave-Maschine sind eine Quelle, Funktionserde des RevPi unbelegt.
* Als nächstes wollte ich dann im browser-UI -> Services den Modbus Master enablen (Google Chrome). Das funktionierte nicht, der "save all" button blieb tot, Verlassen des Tab-Reiters brachte die Warnung ungesicherter Daten u. ein Zurückgehen darauf ergab dann auch, das dem so war: Modbus Master immer noch als inaktiv angezeigt.
* Im Tutorial "Master-Fähigkeit bei Modbus RTU" war der Tip, das stattdessen auf Linux-Kommandozeile zu machen mittels "sudo revpi-config enable pimodbus-master“. Der Befehl brachte keine verdächtige Rückmeldung (da wurden intern ev. symlinks gesetzt?). Anschließend zeigte das UI die Aktivierung auch an. Wenn man nun im UI seinerseits wieder deaktivieren wollte das gleiche Verhalten grad umgekehrt.
* Im device-Pfad ist (und bleibt) der dongle auch als "/dev/ttyUSB0" vorhanden.
* Dann habe ich in pictory lt. angehängter screen-shots eine Demo-config getätigt u. nach abspeichern als start-cfg dann auch mittels tools -> reset driver angewendet. Die rote Signal-Led am RevPi hat auch aufgeleuchtet.
* Nun sollte ja der RevPi alle Sekunde am slave pollen: Jedoch ist keine Aktivität im slave zu beobachten, auch kommen keine Daten rüber: Die Variable "test" kann zwar mittels pitest angesprochen werden, hat aber nur Null als Inhalt. Die erstmalige Modbus-typische off-by-one Verwirrung bei den Registern ist mittels der gewählten Adresse entschärft, da sich beim slave davor / dahinter auch lesbare Register befinden.
* Auslesen von "piTest -r Modbus_Master_Status gibt konstant 0
jetzt fällt mir nichts mehr ein .... muß entweder was ganz Kompliziertes (oder was Saudummes) sein...
Vielen Dank schon mal für Eure Hilfe!
Viele Grüße, Karl-Heinz
Modbus RTU Master scheint inaktiv
Modbus RTU Master scheint inaktiv
- Attachments
-
- pictory3.JPG (131.76 KiB) Viewed 11804 times
-
- pictory2.JPG (171.26 KiB) Viewed 11804 times
-
- pictory1.JPG (160.86 KiB) Viewed 11804 times
Re: Modbus RTU Master scheint inaktiv
Hallo Karl-Heinz,
vielen Dank für die sehr ausführliche Beschreibung. Ich gehe mal davon aus, dass Dein Slave definitiv die Slaveadresse 1 hat, die Übertragungsparameter (Bitrate etc.) stimmen und die Register 1011, 1012 und 1013 Werte ungleich Null enthalten. jetzt wäre dann wichtig zu wissen, was die beiden Statusregister im Master für Inhalte haben (Action und Master). Wenn Du an dem Slave keine Aktivität siehst, dann sollte auch keine Verbindung aufgebaut worden sein oder wegen zu vieler Fehler der Master inaktiv im Fail-Status sein. Daher müssen dann in den Fehlerregistern andere Werte als 0 stehen. Voraussetzung ist aber definitiv, dass der Masterservice enabled sein muss.
Wegen der Probleme mit der GUI: Das könnte ein Kompatibilitätsproblem mit Deinem Browser sein. bitte mail mal welche Version und welchen Typ von Browser Du einsetzt.
vielen Dank für die sehr ausführliche Beschreibung. Ich gehe mal davon aus, dass Dein Slave definitiv die Slaveadresse 1 hat, die Übertragungsparameter (Bitrate etc.) stimmen und die Register 1011, 1012 und 1013 Werte ungleich Null enthalten. jetzt wäre dann wichtig zu wissen, was die beiden Statusregister im Master für Inhalte haben (Action und Master). Wenn Du an dem Slave keine Aktivität siehst, dann sollte auch keine Verbindung aufgebaut worden sein oder wegen zu vieler Fehler der Master inaktiv im Fail-Status sein. Daher müssen dann in den Fehlerregistern andere Werte als 0 stehen. Voraussetzung ist aber definitiv, dass der Masterservice enabled sein muss.
Wegen der Probleme mit der GUI: Das könnte ein Kompatibilitätsproblem mit Deinem Browser sein. bitte mail mal welche Version und welchen Typ von Browser Du einsetzt.
Unser RevPi Motto: Don't just claim it - make it!
Re: Modbus RTU Master scheint inaktiv
Hallo Volker,
vielen Dank erst mal für die schnelle Rückmeldung!
Erst mal als Antwort auf Deine Fragen:
* Wäre das Auslesen eines dieser Register mittels "piTest -r Modbus_Master_Status"? Das gibt konstant 0 aus.
* In puncto Browser habe ich den (sich aktualisiert haltenden) Chrome auf Windows 10 in Verwendung, aber Microsoft Edge zeigt ein identisches Verhalten.
Jedoch habe ich mittlerweile einen starken Verdacht, denn eine Beobachtung vergaß ich zu erwähnen u. sie ist auch nicht im angehängten screenshot von Pictory zu sehen, und dieser erhärtet sich mittlerweile auch durch weitere Nutzung von Pictory (V 1.3.1):
Sobald man die Konfiguration als Start-Konfiguration abspeichert u. anschließend entweder wieder explizit die start-config lädt oder aber das tool zwischenzeitlich verläßt u. wider-betritt, so werden dem Wert des keys "device_path" jeweils zwei underscores vorne und hinten spendiert. Wenn man diese Aktivitäten wiederholt, so wird das beliebig weiter so gemacht.
Nun nehme ich an, das diese underscores irgendwo (client/serverside) beim Speichervorgang mit dazu kommen und nicht erst beim Lesen:
Denn dann würde nach erstmaligem Anwenden der config der Kernel-Treiber im besten Fall "__/dev/ttyUSB0__" präsentiert bekommen, um den USB Dongle zu öffnen. Und was die libc open() Funktion dabei macht kann ich mir lebhaft vorstellen. Das würde erklären, warum USB/RS485 seitig scheinbar alles tot ist, der Kernel-Treiber aber die config bekommt u. auch die entsprechenden eingestellten memory-Variablen kennt: Der Treiber bekommt bei seiner Arbeit dann schlichtweg das RS485 device file nicht auf u. kann daher damit nicht kommunizieren.
Daher könnte es interessant sein, wo man denn diese Konfiguration auf Linux-Ebene editieren kann, um die dort zu erwartenden underscores rauszuwerfen.
Viele Grüße,
Karl-Heinz
vielen Dank erst mal für die schnelle Rückmeldung!
Erst mal als Antwort auf Deine Fragen:
* Wäre das Auslesen eines dieser Register mittels "piTest -r Modbus_Master_Status"? Das gibt konstant 0 aus.
* In puncto Browser habe ich den (sich aktualisiert haltenden) Chrome auf Windows 10 in Verwendung, aber Microsoft Edge zeigt ein identisches Verhalten.
Jedoch habe ich mittlerweile einen starken Verdacht, denn eine Beobachtung vergaß ich zu erwähnen u. sie ist auch nicht im angehängten screenshot von Pictory zu sehen, und dieser erhärtet sich mittlerweile auch durch weitere Nutzung von Pictory (V 1.3.1):
Sobald man die Konfiguration als Start-Konfiguration abspeichert u. anschließend entweder wieder explizit die start-config lädt oder aber das tool zwischenzeitlich verläßt u. wider-betritt, so werden dem Wert des keys "device_path" jeweils zwei underscores vorne und hinten spendiert. Wenn man diese Aktivitäten wiederholt, so wird das beliebig weiter so gemacht.
Nun nehme ich an, das diese underscores irgendwo (client/serverside) beim Speichervorgang mit dazu kommen und nicht erst beim Lesen:
Denn dann würde nach erstmaligem Anwenden der config der Kernel-Treiber im besten Fall "__/dev/ttyUSB0__" präsentiert bekommen, um den USB Dongle zu öffnen. Und was die libc open() Funktion dabei macht kann ich mir lebhaft vorstellen. Das würde erklären, warum USB/RS485 seitig scheinbar alles tot ist, der Kernel-Treiber aber die config bekommt u. auch die entsprechenden eingestellten memory-Variablen kennt: Der Treiber bekommt bei seiner Arbeit dann schlichtweg das RS485 device file nicht auf u. kann daher damit nicht kommunizieren.
Daher könnte es interessant sein, wo man denn diese Konfiguration auf Linux-Ebene editieren kann, um die dort zu erwartenden underscores rauszuwerfen.
Viele Grüße,
Karl-Heinz
Re: Modbus RTU Master scheint inaktiv
Hallo Karl-Heinz,
vielen Dank, für die wertvollen Hinweise. Wir werden das hier umgehend prüfen. Da ich selber bislang noch nicht mit der "Speichern als Startkonfiguration" gearbeitet habe (das ging bis vor Kurzem noch anders), habe ich dieses Verhalten noch nicht bemerkt. In einer Vorgängerversion gab es glaube ich mal einen Fehler, der in die Richtung der von dir geschilderten Probleme ging, aber eigentlich sollte der inzwischen behoben sein. Wie gesagt, wir suchen mal danach, ob wir das nachvollziehen können. In der Zwischenzeit ist ein Update auf die neueste Version vom PiCtory sicherlich nicht falsch...
Wir melden uns dann...
vielen Dank, für die wertvollen Hinweise. Wir werden das hier umgehend prüfen. Da ich selber bislang noch nicht mit der "Speichern als Startkonfiguration" gearbeitet habe (das ging bis vor Kurzem noch anders), habe ich dieses Verhalten noch nicht bemerkt. In einer Vorgängerversion gab es glaube ich mal einen Fehler, der in die Richtung der von dir geschilderten Probleme ging, aber eigentlich sollte der inzwischen behoben sein. Wie gesagt, wir suchen mal danach, ob wir das nachvollziehen können. In der Zwischenzeit ist ein Update auf die neueste Version vom PiCtory sicherlich nicht falsch...
Wir melden uns dann...
Unser RevPi Motto: Don't just claim it - make it!
Re: Modbus RTU Master scheint inaktiv
Hallo Volker,
vielen Dank für die Rückmeldung; wie ich gesehen habe scheint ihr ja Pictory die letzten Tage auf V 1.3.2 upgedatet zu haben, und diese neueste Version habe ich jetzt auch installiert:
Doch leider keine Veränderung zu 1.3.1: Die sukzessiv beigesteuerten underscores bei "device_path" kommen weiterhin u. im Web-Status lassen sich Modbus Master / Slave weiterhin nicht (de-)aktivieren.
Aber die neueste(n) Version(en) könnten vielleicht das Problem sein: In den tutorials sieht man, das Vorgänger-Versionen von Pictory mal ein wenig anders aussahen; vielleicht ist ja mal jüngst eine regression reingerutscht (wir kennen diese leidige Thema nur zu gut).
Viele Grüße,
Karl-Heinz
vielen Dank für die Rückmeldung; wie ich gesehen habe scheint ihr ja Pictory die letzten Tage auf V 1.3.2 upgedatet zu haben, und diese neueste Version habe ich jetzt auch installiert:
Doch leider keine Veränderung zu 1.3.1: Die sukzessiv beigesteuerten underscores bei "device_path" kommen weiterhin u. im Web-Status lassen sich Modbus Master / Slave weiterhin nicht (de-)aktivieren.
Aber die neueste(n) Version(en) könnten vielleicht das Problem sein: In den tutorials sieht man, das Vorgänger-Versionen von Pictory mal ein wenig anders aussahen; vielleicht ist ja mal jüngst eine regression reingerutscht (wir kennen diese leidige Thema nur zu gut).
Viele Grüße,
Karl-Heinz
Re: Modbus RTU Master scheint inaktiv
Hallo Volker,
ich bin dem Problem mittlerweile auf die Schliche gekommen und habe einen workaround gefunden und das Bauchgefühl, das es bald ein Pictory V 1.3.3 geben wird:
Nach googeln bzgl. Prozessabbild / picontrol kerne-driver bin ich auf die github-sourcen u. dabei picontrol.h gestoßen:
Da sieht man gleich am Anfang, wo der kernel-driver effektiv sein (per pictory gepflegtes) config-file herholt (/var/www/pictory/projects/_config.rsc).
Da reingeschaut finden sich die erwarteten underscores. Diese entfernt, dann in Pictory "reset driver", und alles funktioniert!
Der workaround ist also das ich nach Modifikation der start config in pictory erstmal mit dem editor auf _config.rsc gehe und die wieder reingekommenen underscores beseitige, danach ein driver reset. Da es hiebei (mit nano) nur darum geht ein paar Zeichen rauszuwerfen werde ich mir damit auch nicht die JSON-Struktur kaputtmachen.
Viele Grüße,
Karl-Heinz
ich bin dem Problem mittlerweile auf die Schliche gekommen und habe einen workaround gefunden und das Bauchgefühl, das es bald ein Pictory V 1.3.3 geben wird:
Nach googeln bzgl. Prozessabbild / picontrol kerne-driver bin ich auf die github-sourcen u. dabei picontrol.h gestoßen:
Da sieht man gleich am Anfang, wo der kernel-driver effektiv sein (per pictory gepflegtes) config-file herholt (/var/www/pictory/projects/_config.rsc).
Da reingeschaut finden sich die erwarteten underscores. Diese entfernt, dann in Pictory "reset driver", und alles funktioniert!
Der workaround ist also das ich nach Modifikation der start config in pictory erstmal mit dem editor auf _config.rsc gehe und die wieder reingekommenen underscores beseitige, danach ein driver reset. Da es hiebei (mit nano) nur darum geht ein paar Zeichen rauszuwerfen werde ich mir damit auch nicht die JSON-Struktur kaputtmachen.
Viele Grüße,
Karl-Heinz
Re: Modbus RTU Master scheint inaktiv
Hallo Karl-Heinz,
deine Einschätzung ist vollkommen richtig. Ich habe den Fehler mit den beiden '_' gerade behoben. Die Version 1.3.3 kannst du jetzt installieren.
Der Fehler der dazu führt, dass die Config und Services Seite nicht funktionieren, sitzt leider etwas tiefer. Den werden wir erst am Montag beheben.
Zu deinen anderne Fragen:
Master_Status_Reset enthält den allgemeinen Status, also z.B. wenn sich das Device nicht öffnen lässt.
Um herauszufinden, ob eine Action nicht funktioniert, musst du dir zusätzlich noch Action_Status_Reset_1 ansehen.
Bei uns beginnen die Registeradressen wie bei Modbus üblich bei 1. In den Daten die über die Leitung gehen beginnen die Adressen aber bei 0. QModbus zeigt das, was über die Leitung geht. Wenn du mit QModbus als z.B. Register 5 lesen kannst, musst du in Pictory die Adresse 6 eintragen.
Gruß
Mathias
deine Einschätzung ist vollkommen richtig. Ich habe den Fehler mit den beiden '_' gerade behoben. Die Version 1.3.3 kannst du jetzt installieren.
Der Fehler der dazu führt, dass die Config und Services Seite nicht funktionieren, sitzt leider etwas tiefer. Den werden wir erst am Montag beheben.
Zu deinen anderne Fragen:
Master_Status_Reset enthält den allgemeinen Status, also z.B. wenn sich das Device nicht öffnen lässt.
Um herauszufinden, ob eine Action nicht funktioniert, musst du dir zusätzlich noch Action_Status_Reset_1 ansehen.
Bei uns beginnen die Registeradressen wie bei Modbus üblich bei 1. In den Daten die über die Leitung gehen beginnen die Adressen aber bei 0. QModbus zeigt das, was über die Leitung geht. Wenn du mit QModbus als z.B. Register 5 lesen kannst, musst du in Pictory die Adresse 6 eintragen.
Gruß
Mathias
Re: Modbus RTU Master scheint inaktiv
Hallo Mathias, Volker,
vielen Dank, hab's gerade eingespielt, funktioniert prima!
Und das mit der Config-Seite ist überhaupt nicht eilig.
Vielen Dank nochmal u. schönes Wochenende,
Karl-Heinz
vielen Dank, hab's gerade eingespielt, funktioniert prima!
Und das mit der Config-Seite ist überhaupt nicht eilig.
Vielen Dank nochmal u. schönes Wochenende,
Karl-Heinz
Re: Modbus RTU Master scheint inaktiv
Kurze Korrektur von den Angaben zu den Prozessvariablen: Die Bamen mit "Reset" hinten dran sind nicht die Status, sondern die ohne dem "Reset" hinten dran sind die Status, die man lesen kann. In die Prozessvariablen mit "Reset" hinten dran schreibst Du eine 1, um den zugehörigen Status zurückzusetzen.
Unser RevPi Motto: Don't just claim it - make it!
