Hallo zusammen,
Für ein Projekt möchte ich folgende Komponenten einsetzen (Komponenten bereits vorhanden):
RevPi Connect+
RevPi DIO
RevPi ConCAN
Im wesentlichen wird es eine Art Schnittstellenumsetzer zwischen CAN und Modbus, wobei die Daten am RevPi noch manipuliert werden.
Aktuell beschäftigt mich folgendes:
Ich benötige insgesamt 370 Register die der RevPi als Modbus Slave bereitstellt.
Die Schnittstellenspezifikation des Modbus Masters, der vom Slave (RevPi) lesen soll, definiert genau, welche Daten in welchem Register zu liegen haben. Ich weiß, normalerweise ist es umgekehrt, sodass am Master das eingestellt wird, was der Slave vorgibt, hier ist es aber umgekehrt und der Master kann nicht verändert werden.
Ich habe bereits erfolgreich eine Modbusverbindung herstellen können zwischen dem RevPi und QModBus am PC. Allerdings nur mit einem Virtuellen Modbus Slave. Da beginnen die Register bei Adresse 1 und gehen bis 32.
Meine Fragen:
1.) Über welche Register werden weitere Modbus Slaves angesprochen? Bei 33 und fortfolgend, erhalte ich keine Antwort
2.) Kann ich manuell die Register einstellen? zB Output_1 soll zB Register 101 sein, Output_2 zB 2004, usw.
Vielen Dank
Modbus Register
Hi da gibt es leider in paar Dinge, die so noch nicht implementiert sind.
Zu 1) Du kannst mehrere Modbus Master verwenden aber mit der Einschränkung dass diese immer 32 Register ab Adresse 1 lesen oder schreiben können. Es gibt mit dem Modbus RTU Master 150 Device ein Gerät, welches "aufgebohrt" ist und insgesamt 150 Register zur Verfügung stellt.
Zu 2) Nein, das kannst Du leider nicht einstellen.
Wir sind dabei, im nächsten Release von PiCtory eine abschaltbare Konflikt Prüfung zu implementieren und damit mehr Performance zu erreichen bei der Bearbeitung der Variablennamen.
Zu 1) Du kannst mehrere Modbus Master verwenden aber mit der Einschränkung dass diese immer 32 Register ab Adresse 1 lesen oder schreiben können. Es gibt mit dem Modbus RTU Master 150 Device ein Gerät, welches "aufgebohrt" ist und insgesamt 150 Register zur Verfügung stellt.
Zu 2) Nein, das kannst Du leider nicht einstellen.
Wir sind dabei, im nächsten Release von PiCtory eine abschaltbare Konflikt Prüfung zu implementieren und damit mehr Performance zu erreichen bei der Bearbeitung der Variablennamen.
Hi Dirk,
danke für die Antworten. Leider sind diese unbefriedigend.
Ich möchte an dieser Stelle auf deine Tutorials 22 und 23 (Modbus RTU bzw. TCP Slave) verweisen, und diese sind immerhin schon über 2 Jahre alt, in denen du am Ende sagst: "Wenn du mehr brauchst [als 32], kein Problem, nimmst du einfach nochmal einen Modbus RTU [bzw. TCP] Slave, ziehst ihn rein, und schon hast du mehr Daten zur Verfügung."
Da hab ich mich leider drauf verlassen, als ich für mein Projekt eure Produktlinie gewählt habe und wir reden hier nicht von einem Hobby-Projekt. Jetzt sagst du mir, dass es doch nicht so ist, wie seit über 2 Jahren behauptet. Was soll ich davon halten?
Den Modbus RTU Master 150 habe ich gesehen, hilft mir aber nix, weil ich ja einen Slave bauen muss.
Was mache ich da jetzt? Wie können wir das Problem lösen?
Wo sind die Modbus Slaves (TCP u. RTU) definiert/konfiguriert/programmiert?
Kann ich das ändern? Falls ja, wo/wie?
Könnt ihr das ändern? Falls ja, wie schnell könnt ihr das erledigen?
Übrigens ist mir etwas aufgefallen: Wenn ich mehr als einen virtuellen Modbus Slave hinzufüge, ist nicht garantiert, dass der erste in der Reihe auf die Register 1-32 "hört", kann auch der zweite sein.
Danke,
Marcel
danke für die Antworten. Leider sind diese unbefriedigend.
Ich möchte an dieser Stelle auf deine Tutorials 22 und 23 (Modbus RTU bzw. TCP Slave) verweisen, und diese sind immerhin schon über 2 Jahre alt, in denen du am Ende sagst: "Wenn du mehr brauchst [als 32], kein Problem, nimmst du einfach nochmal einen Modbus RTU [bzw. TCP] Slave, ziehst ihn rein, und schon hast du mehr Daten zur Verfügung."
Da hab ich mich leider drauf verlassen, als ich für mein Projekt eure Produktlinie gewählt habe und wir reden hier nicht von einem Hobby-Projekt. Jetzt sagst du mir, dass es doch nicht so ist, wie seit über 2 Jahren behauptet. Was soll ich davon halten?
Den Modbus RTU Master 150 habe ich gesehen, hilft mir aber nix, weil ich ja einen Slave bauen muss.
Was mache ich da jetzt? Wie können wir das Problem lösen?
Wo sind die Modbus Slaves (TCP u. RTU) definiert/konfiguriert/programmiert?
Kann ich das ändern? Falls ja, wo/wie?
Könnt ihr das ändern? Falls ja, wie schnell könnt ihr das erledigen?
Übrigens ist mir etwas aufgefallen: Wenn ich mehr als einen virtuellen Modbus Slave hinzufüge, ist nicht garantiert, dass der erste in der Reihe auf die Register 1-32 "hört", kann auch der zweite sein.
Danke,
Marcel
Hallo Marcel, erstmal vielen Dank für Deine Analyse der Probleme. Deine Kritik ist berechtigt. Leider haben wir hier versäumt, die Dinge richtig zu testen.
Wir haben soeben einen schnellen Test gemacht mit zwei "aufgebohrten" Modbus RTU Slave und Modbus TCP Slave welche jeweils 512 Input- und Output Register haben.
Beim Test mussten wir leider feststellen, dass der aktuelle Modbus Stack damit nicht startet.
Schlussendlich haben wir im RevPi Team diesen Bug besprochen und dieser wird eingeplant in der Entwicklung.
Der letzte Punkt welcher im Zusammenhang mit mehreren Modbus Slaves in PiCtory steht, hat mich auch erstaunt.
Das ist ebenfalls ein offensichtlicher Fehler, den wir fixen müssen.
Ich habe das getestet und kann Dir als momentanen Workaround nur anbieten, dass Du mehrere Modbus Slaves auf unterschiedlichen TCP Ports lauschen lassen kannst, um mehrere Slaves zu adressieren.
Wir haben soeben einen schnellen Test gemacht mit zwei "aufgebohrten" Modbus RTU Slave und Modbus TCP Slave welche jeweils 512 Input- und Output Register haben.
Beim Test mussten wir leider feststellen, dass der aktuelle Modbus Stack damit nicht startet.
Schlussendlich haben wir im RevPi Team diesen Bug besprochen und dieser wird eingeplant in der Entwicklung.
Der letzte Punkt welcher im Zusammenhang mit mehreren Modbus Slaves in PiCtory steht, hat mich auch erstaunt.
Das ist ebenfalls ein offensichtlicher Fehler, den wir fixen müssen.
Ich habe das getestet und kann Dir als momentanen Workaround nur anbieten, dass Du mehrere Modbus Slaves auf unterschiedlichen TCP Ports lauschen lassen kannst, um mehrere Slaves zu adressieren.
Hallo Marcel, uns ist gerade noch eine Idee gekommen, die wir beim schnellen Test übersehen haben. Wir melden uns morgen nochmals. Danke für Deine Geduld.
Hallo Dirk,
Danke für deine/eure Rückmeldungen und dass ihr euch dessen annehmt.
Der Tipp mit dem Workaround über mehrere TCP-Slaves auf unterschiedlichen Ports hilft mir bei meiner Aufgabenstellung auch nicht weiter, weil
a) immer noch die Funktion fehlt, dass ich die Register manuell zuordnen kann und
b) ich das auch für RTU brauche
In der Zwischenzeit habe ich begonnen meinen eigenen Client zu schreiben.
Hierzu gleich eine Frage: Wenn mein Client über /dev/ttyRS485 kommuniziert, was muss ich tun, damit es hier nicht zu Ressourcen-Konflikten kommt? Reicht es, wenn ich im Webinterface unter "Services" den "Modbus Slave" auf "Disabled" setze?
Eure Korrekturen bzw. Weiterentwicklungen betreffend möchte ich anbieten, euch zumindest mit Testen+Feedback zu helfen.
Ich bin auch schon gespannt, was euch gestern Abend noch eingefallen ist
Ich möchte noch anmerken, dass die RevPI-Linie aus mehreren Gründen in die engere Auswahl gekommen ist, dazu zählt auch die offene Plattform. Auch wenn nicht die komplette Software geöffnet bzw. befreit wurde, im industriellen Vergleich ist zählt es doch zu den offensten
Wenn man so durchs Forum liest, merkt man durchaus euren Einsatz, wenn es um Fehlerbehebungen und Featurewünsche geht. Das war ebenfalls ein wichtiger Grund. Meine Kritik war speziell darauf bezogen, dass eine seit langer Zeit beworbene Funktion nicht implementiert ist. Wie gesagt, ich bin schon gespannt auf den weiteren Verlauf
SG,
Marcel
Danke für deine/eure Rückmeldungen und dass ihr euch dessen annehmt.
Der Tipp mit dem Workaround über mehrere TCP-Slaves auf unterschiedlichen Ports hilft mir bei meiner Aufgabenstellung auch nicht weiter, weil
a) immer noch die Funktion fehlt, dass ich die Register manuell zuordnen kann und
b) ich das auch für RTU brauche
In der Zwischenzeit habe ich begonnen meinen eigenen Client zu schreiben.
Hierzu gleich eine Frage: Wenn mein Client über /dev/ttyRS485 kommuniziert, was muss ich tun, damit es hier nicht zu Ressourcen-Konflikten kommt? Reicht es, wenn ich im Webinterface unter "Services" den "Modbus Slave" auf "Disabled" setze?
Eure Korrekturen bzw. Weiterentwicklungen betreffend möchte ich anbieten, euch zumindest mit Testen+Feedback zu helfen.
Ich bin auch schon gespannt, was euch gestern Abend noch eingefallen ist
Ich möchte noch anmerken, dass die RevPI-Linie aus mehreren Gründen in die engere Auswahl gekommen ist, dazu zählt auch die offene Plattform. Auch wenn nicht die komplette Software geöffnet bzw. befreit wurde, im industriellen Vergleich ist zählt es doch zu den offensten
Wenn man so durchs Forum liest, merkt man durchaus euren Einsatz, wenn es um Fehlerbehebungen und Featurewünsche geht. Das war ebenfalls ein wichtiger Grund. Meine Kritik war speziell darauf bezogen, dass eine seit langer Zeit beworbene Funktion nicht implementiert ist. Wie gesagt, ich bin schon gespannt auf den weiteren Verlauf
SG,
Marcel
Ja, normalerweise müsste das genügen. Du kannst mit "sudo lsof /dev/ttyRS485" prüfen, ob das Device File von einem anderen Prozess geöffnet ist. (Falls nötig kannst du "lsof" mit apt-get nachinstallieren.)
Welche Komponenten würdest du gerne befreit sehen? Dann können wir das intern diskutieren.
Marcel, hier haben wir einen experimentellen Patch für PiCtory. Dadurch erhältst Du zwei neue Geräte mit jeweils 512 Registern für Input und Output:
Wir prüfen, ob wir diese Geräte offiziell zu PiCtory hinzufügen werden.
Wichtig - bitte mache vorher ein Backup Deines Systems. Wie das funktioniert siehe z.B. Video Tutorial 01 – Erstellen eines Image.
Bitte wundere Dich nicht dass der Start von PiCtory beim Benutzen dieser Geräte etwas länger dauert.
Die Installationsanweisungen findest Du in der readme.txt .
Hier werden sie geholfen
- PiCtory
- 2020-05-19 16_34_05-PiCtory - 1.4.2.jpg (15.6 KiB) Viewed 8410 times
Wichtig - bitte mache vorher ein Backup Deines Systems. Wie das funktioniert siehe z.B. Video Tutorial 01 – Erstellen eines Image.
Bitte wundere Dich nicht dass der Start von PiCtory beim Benutzen dieser Geräte etwas länger dauert.
Die Installationsanweisungen findest Du in der readme.txt .
Hier werden sie geholfen
- Attachments
-
- Modbus Slave 512.zip
- (4.15 KiB) Downloaded 750 times
Grüße euch,
Danke für das Update, bin erst jetzt dazu gekommen es zu testen.
Funktioniert ja wunderbar, es stehen jetzt jeweils 512 Register für In-/Output zur Verfügung. Damit würde ich im Prinzip schon auskommen (brauche, wie gesagt, 370).
Was mir noch fehlt, ist die Möglichkeit, den Inputs/Outputs die Register spezifisch zuzuweisen. Ist das schwierig umzusetzen?
Wenn ich einen weiteren Slave hinzufüge, ist der nicht via Modbus ansprechbar, aber das war ja der Sinn der Übung, dass das nicht mehr gebraucht wird.
@lukas: ich habe jetzt nicht so tief ins System geblickt, als dass ich sagen könnte: "Wäre alles frei, hätte ich mir schon selbst helfen können."
Da würde schon ordentlich angeben
Beim Stöbern durch die Foren ist mir irgendwo untergekommen, dass Firmwares (tlw.?) nicht freigegeben sind. Wie gesagt, es betrifft mich nicht direkt und war nur eine Anmerkung und keine Kritik, obwohl ich ein Vertreter/Verfechter freier Software/Hardware bin. Man sieht ja auch beim RevPI schön, was daraus entstehen kann.
Danke für das Update, bin erst jetzt dazu gekommen es zu testen.
Funktioniert ja wunderbar, es stehen jetzt jeweils 512 Register für In-/Output zur Verfügung. Damit würde ich im Prinzip schon auskommen (brauche, wie gesagt, 370).
Was mir noch fehlt, ist die Möglichkeit, den Inputs/Outputs die Register spezifisch zuzuweisen. Ist das schwierig umzusetzen?
Wenn ich einen weiteren Slave hinzufüge, ist der nicht via Modbus ansprechbar, aber das war ja der Sinn der Übung, dass das nicht mehr gebraucht wird.
@lukas: ich habe jetzt nicht so tief ins System geblickt, als dass ich sagen könnte: "Wäre alles frei, hätte ich mir schon selbst helfen können."
Da würde schon ordentlich angeben
Beim Stöbern durch die Foren ist mir irgendwo untergekommen, dass Firmwares (tlw.?) nicht freigegeben sind. Wie gesagt, es betrifft mich nicht direkt und war nur eine Anmerkung und keine Kritik, obwohl ich ein Vertreter/Verfechter freier Software/Hardware bin. Man sieht ja auch beim RevPI schön, was daraus entstehen kann.
Hi Marcel, vielen Dank für Deine positive Rückmeldung. Es freut uns dass Du mit Deinem Projekt weiterkommst und wir ein Show-Stopper entfernen konnten. Das war im übrigen eine Teamleistung aus vielen Einzelteilen.
Deine Frage habe ich nicht so recht verstanden - was meinst Du fehlt Dir noch bezüglich Inputs/Outputs spezifische Register zuzuweisen?
Das Thema weitere Slaves hinzuzufügen ist dann hinfällig, genau.
Deine Frage habe ich nicht so recht verstanden - was meinst Du fehlt Dir noch bezüglich Inputs/Outputs spezifische Register zuzuweisen?
Das Thema weitere Slaves hinzuzufügen ist dann hinfällig, genau.
