Hallo
Ich habe für ein Projekt ein RevPiCore mit dem Modbus RTU Gateway auf dem Tisch, scheine aber gerade etwas auf dem Schlauch zu stehen.
Gibt es für den Modbus RTU Gateway eine Liste der Speicherbereiche? Analog seines TCP-Bruders:
https://revolution.kunbus.de/revpi-gate ... igurieren/
Ich kriege leider aktuell kein Byte aus ihm raus. Nach dem Pictory Update konnte ich ihn mal konfigurieren - jedoch ist mir rätselhaft, welche Adressen ich konfigurieren müsste. Ich habs dann mal mit denen des Modbus-TCP Gateways versucht, leider ohne Erfolg.
PiTest.c sagt beim scan "unknown module", das hat mich aber nach einem kurzen Blick in den Sourcecode nicht weiter stutzig gemacht, das Modul scheint einfach noch nicht eingetragen zu sein.
Anwendungsfall wäre, das Lesen von Registern aus einem angeschlossenen Stromzähler (den haben wir, inkl. Verdrahtung, Baudrate, Parity, etc. mit einem anderen Gerät getestet - da scheint alles OK).
Beste Grüsse,
Silvan
Modbus RTU Gateway
Hallo,
Oh das trifft sich gut. Denn da habe ich auch gleich noch eine Frage dazu. Da ich ja nun auch mit Modbus versuche zu hantieren frage ich mich, wie bekomme ich die übergabe der Variablen aus den DIO.
Müsste ich nun für jede Variable die ich nutzen möchte eine neue Zuweisung in dem Modbus modul machen? Oder kann ich einfach nur die Adressen die in der Variablenliste hinterlegt sind im Pictory, in dem Modbus eintragen?
Ist halt noch neues Gebit das es ersteinmal heißt zu verstehen.
gruß
Oh das trifft sich gut. Denn da habe ich auch gleich noch eine Frage dazu. Da ich ja nun auch mit Modbus versuche zu hantieren frage ich mich, wie bekomme ich die übergabe der Variablen aus den DIO.
Müsste ich nun für jede Variable die ich nutzen möchte eine neue Zuweisung in dem Modbus modul machen? Oder kann ich einfach nur die Adressen die in der Variablenliste hinterlegt sind im Pictory, in dem Modbus eintragen?
Ist halt noch neues Gebit das es ersteinmal heißt zu verstehen.
gruß
Hallo Silvan,
ich denke, wir haben hier ein Missverständnis in Bezug auf die von Dir zitierte Doku vom TCP Gateway. Dies möchte ich daher erst einmal ausräumen und versuchen das Konzept der Gateways allgemein zu erklären:
Historisch sind diese Module von KUNBUS für die Übersetzung eines Protokolls bzw. eines Feldbusses in ein anderes Protokoll oder einen anderen Feldbus entwickelt worden. Wenn ich also ein Modbus-Slave Gateway zusammen mit einem Profibus-Gateway betreibe (die beiden werden über den "PiBridge" Stecker dann miteinander gekoppelt), dann habe ich ja keinen programmierbaren Rechner dazwischen. Die beiden Gateways müssen irgendwie einen Weg finden, die Prozessdaten von einem Bus/Protokoll in Prozessdtaen für einen anderen Bus/Protokoll zu übersetzen. Dabei wird so verfahren, dass die Nutzdaten (Prozessdaten oder auch Payload) zyklisch aus einem Protokoll extrahiert werden und in einem großen RAM-Bereich als unstrukturierter Block abgelegt werden. Die Firmware des Gateways kopiert nun so einen RAM-Bereich eines Gateways in den des Partnergateways und umgekehrt. Daten, die ein Master (eine SPS) also zu dem Slave (also das Gateway) schreibt, gelanden vom Feldbus in den Speicherblock des Gateways und von dort in den Speicherblock des Partnergateways. Von dort werden sie in das Protokoll des Parterngateways verpackt und von einem zweiten Master (z.B. einer weiteren SPS) über den Feldbus abgeholt. In der gegenrichtung geht das dann analog.
Ein Modbus Master schreibt seine Prozessdaten entweder in "Coils" (also 1 Bit große Zielregister) oder in Output-Register (16 bit breite Zielregister) des Slaves. Für diese Register gibt der Master beim Schreiben eine Modbus Registernummer an. Welche Slaveadressen er dabei verwenden darf gibt der Slave in der Regel vor. Die Gateways haben 256 solche 16 bit breiten Register zum Beschreiben und ebenso viele zum Auslesen zur Verfügung. Ihre Modbus Registernummern sind in der von Dir zitierten Tabelle aufgeführt. Um also an eine bestimmte Stelle des RAM-Bereichs zu schreiben, der für den Datenaustausch zwischen zwei Gateways kopiert wird, muss der Modbus Master eine ganz bestimmte Modbus Registernummer verwenden. Beim Lesen muss er eine gültige Modbus Registernummer aus dem Pool der für die 256 Inputregister zur Verfügung stehenden Nummern auswählen. Die Coilss bzw Contacts (also die 1 bit breiten Zugriffsregister) sind bei den Gatways auf denselben Speicherbereich "gemapped", wo auch die 16 Bit breiten register liegen. Also die Coils 1 bis 16 liegen auf den Bits des Outputregisters 1, die Coils 17 bis 32 auf dem Outputregister 2 und so weiter. Die Modbus Registernummern sind dann entsprechend 256 x 16 Stück für die Inputs und ebensoviele für die Outputs.
Ein Profibus Gateway würde dann also das Outputregister 1 vom Modbusgateway dem Profibus Master (z.B. einer S7) als erstes Byte der Prozessdaten zur Verfügung stellen. Was der Profibus Master damit anfängt und wie er seine Daten strukturiert, ist Sache vom Profibus und wird zum Beispiel durch die GSD-Datei und die Konfiguration des Systems im TIA-Portal festgelegt.
Soviel zu der hsitorischen Herkunft der KUNBUS Gateways. Wenn nun ein solcher Gateway an unserem RevPi Core betrieben wird, dann verhält sich der Core dem Gateway gegenüber wie ein Partenrgateway. Das bedeutet, er tauscht diese 512 Byte Prozessdaten jeweils für In- und Outputs zyklisch mit dem Modbus Gatwayüber die PiBridge aus. Ein Modbus Master schreibt oder liest sie über die Registerzugriffe mit den entsprechenden Registernummern aus oder in diesen RAM-Block. IM RevPi Core gelangen die Daten dann in das zentrale Prozessabbild. Im Falle der Gateways liegen die Bytes des Datenaustauschblocks alle hintereinander. An welcher Adresse dieser Datenblock anfängt, hängt von der PiCtory Konfiguration ab und kann netweder über eine PiTestabfrage mit symbolischen Namen des ersten Bytes aus diesem Block abgefragt werden oder aber durch einen Export der Offsetliste. keinesfalls darf man aber diese Offsets bzw. Adressen des Prozessabbildes mit Modbus registeradressen verwechseln. Ich habe daher im voranstehenden Text bewusst vermieden von "Modbus Registeradressen" zu reden, sondern das Wort "Modbus Registernummer" verwendet.
Nun zu Deinem konkreten Anliegen:
Regsiternummern 1 bis 256 sind Inputregister und Registernummer 1025 bis 1280 sind Outputregister, also genau wie beim TCP Gateway. Inputregister eines Slaves sind Register, die von einem Master am Modbus gelesen werden! Das bedeutet, dass die zugehörigen Adressen im Prozessabbild vom PiCore beschrieben werden, also Outputs im Sinne einer Software wie logi.CAD sind. Das ist ein wenig verwirrend, liegt aber daran, dass die Begriffe Input und Output traditionell immmer aus Sicht einer Steuerung (typischer weise auch der Master in einem Bus) gesehen werden. Wenn Du also zum Beispiel nur ein Gateway konfigurierst, dann liegen typischerweise die RevPi Prozessabbildadressen für die Input-Bytes bei 2 bis 513 und ab 514 würden die Ausgänge anfangen. EIn Modbus-Master würde also mit read input registers auf Modbus Registernummer 1 die Byte 514/515 vom PA einlesen. Würde der Modbusmaster ein write output registers auf Modbus Registernummer 513 durchführen, dann würde er in die Adressen 2 und 3 vom PA des revPi Core schreiben.
Bitte lies auch Deine private Mail hier im Forum, Dort melde ich mich auch noch zusätzlich.
ich denke, wir haben hier ein Missverständnis in Bezug auf die von Dir zitierte Doku vom TCP Gateway. Dies möchte ich daher erst einmal ausräumen und versuchen das Konzept der Gateways allgemein zu erklären:
Historisch sind diese Module von KUNBUS für die Übersetzung eines Protokolls bzw. eines Feldbusses in ein anderes Protokoll oder einen anderen Feldbus entwickelt worden. Wenn ich also ein Modbus-Slave Gateway zusammen mit einem Profibus-Gateway betreibe (die beiden werden über den "PiBridge" Stecker dann miteinander gekoppelt), dann habe ich ja keinen programmierbaren Rechner dazwischen. Die beiden Gateways müssen irgendwie einen Weg finden, die Prozessdaten von einem Bus/Protokoll in Prozessdtaen für einen anderen Bus/Protokoll zu übersetzen. Dabei wird so verfahren, dass die Nutzdaten (Prozessdaten oder auch Payload) zyklisch aus einem Protokoll extrahiert werden und in einem großen RAM-Bereich als unstrukturierter Block abgelegt werden. Die Firmware des Gateways kopiert nun so einen RAM-Bereich eines Gateways in den des Partnergateways und umgekehrt. Daten, die ein Master (eine SPS) also zu dem Slave (also das Gateway) schreibt, gelanden vom Feldbus in den Speicherblock des Gateways und von dort in den Speicherblock des Partnergateways. Von dort werden sie in das Protokoll des Parterngateways verpackt und von einem zweiten Master (z.B. einer weiteren SPS) über den Feldbus abgeholt. In der gegenrichtung geht das dann analog.
Ein Modbus Master schreibt seine Prozessdaten entweder in "Coils" (also 1 Bit große Zielregister) oder in Output-Register (16 bit breite Zielregister) des Slaves. Für diese Register gibt der Master beim Schreiben eine Modbus Registernummer an. Welche Slaveadressen er dabei verwenden darf gibt der Slave in der Regel vor. Die Gateways haben 256 solche 16 bit breiten Register zum Beschreiben und ebenso viele zum Auslesen zur Verfügung. Ihre Modbus Registernummern sind in der von Dir zitierten Tabelle aufgeführt. Um also an eine bestimmte Stelle des RAM-Bereichs zu schreiben, der für den Datenaustausch zwischen zwei Gateways kopiert wird, muss der Modbus Master eine ganz bestimmte Modbus Registernummer verwenden. Beim Lesen muss er eine gültige Modbus Registernummer aus dem Pool der für die 256 Inputregister zur Verfügung stehenden Nummern auswählen. Die Coilss bzw Contacts (also die 1 bit breiten Zugriffsregister) sind bei den Gatways auf denselben Speicherbereich "gemapped", wo auch die 16 Bit breiten register liegen. Also die Coils 1 bis 16 liegen auf den Bits des Outputregisters 1, die Coils 17 bis 32 auf dem Outputregister 2 und so weiter. Die Modbus Registernummern sind dann entsprechend 256 x 16 Stück für die Inputs und ebensoviele für die Outputs.
Ein Profibus Gateway würde dann also das Outputregister 1 vom Modbusgateway dem Profibus Master (z.B. einer S7) als erstes Byte der Prozessdaten zur Verfügung stellen. Was der Profibus Master damit anfängt und wie er seine Daten strukturiert, ist Sache vom Profibus und wird zum Beispiel durch die GSD-Datei und die Konfiguration des Systems im TIA-Portal festgelegt.
Soviel zu der hsitorischen Herkunft der KUNBUS Gateways. Wenn nun ein solcher Gateway an unserem RevPi Core betrieben wird, dann verhält sich der Core dem Gateway gegenüber wie ein Partenrgateway. Das bedeutet, er tauscht diese 512 Byte Prozessdaten jeweils für In- und Outputs zyklisch mit dem Modbus Gatwayüber die PiBridge aus. Ein Modbus Master schreibt oder liest sie über die Registerzugriffe mit den entsprechenden Registernummern aus oder in diesen RAM-Block. IM RevPi Core gelangen die Daten dann in das zentrale Prozessabbild. Im Falle der Gateways liegen die Bytes des Datenaustauschblocks alle hintereinander. An welcher Adresse dieser Datenblock anfängt, hängt von der PiCtory Konfiguration ab und kann netweder über eine PiTestabfrage mit symbolischen Namen des ersten Bytes aus diesem Block abgefragt werden oder aber durch einen Export der Offsetliste. keinesfalls darf man aber diese Offsets bzw. Adressen des Prozessabbildes mit Modbus registeradressen verwechseln. Ich habe daher im voranstehenden Text bewusst vermieden von "Modbus Registeradressen" zu reden, sondern das Wort "Modbus Registernummer" verwendet.
Nun zu Deinem konkreten Anliegen:
Ich kann mit dieser Angabe leider nicht sagen, ob ein und welcher Konfigurationsfehler vorliegt. Wenn Du mal einen Screendump vom PiCtory machst und dann vielleicht noch die Exportdatei mal generierst und mit ans Forum schickst (vielleicht auch noch eine Kopie der PiTest Ausgabe) dann könnten wir eventuell konkreter weiterhelfen. Was versteht Du unter "Sourcecode" in diesem Zusammenhang? Welche Datei hast Du dan angesehen?PiTest.c sagt beim scan "unknown module", das hat mich aber nach einem kurzen Blick in den Sourcecode nicht weiter stutzig gemacht, das Modul scheint einfach noch nicht eingetragen zu sein.
Uis, das hört sich jetzt eher nach einem großen Missverständnis an: Wenn Du aus dem Zähler register auslesen willst, dann ist der Zähler ein Modbus Slave (=Server) und Du brauchst einen Modbus Master (Client) um seine Regsiter auslesen zu können. Unsere Gateways sind aber Modbus Slave Geräte und können das definitiv nicht.Anwendungsfall wäre, das Lesen von Registern aus einem angeschlossenen Stromzähler
Gibt es für den Modbus RTU Gateway eine Liste der Speicherbereiche?
Regsiternummern 1 bis 256 sind Inputregister und Registernummer 1025 bis 1280 sind Outputregister, also genau wie beim TCP Gateway. Inputregister eines Slaves sind Register, die von einem Master am Modbus gelesen werden! Das bedeutet, dass die zugehörigen Adressen im Prozessabbild vom PiCore beschrieben werden, also Outputs im Sinne einer Software wie logi.CAD sind. Das ist ein wenig verwirrend, liegt aber daran, dass die Begriffe Input und Output traditionell immmer aus Sicht einer Steuerung (typischer weise auch der Master in einem Bus) gesehen werden. Wenn Du also zum Beispiel nur ein Gateway konfigurierst, dann liegen typischerweise die RevPi Prozessabbildadressen für die Input-Bytes bei 2 bis 513 und ab 514 würden die Ausgänge anfangen. EIn Modbus-Master würde also mit read input registers auf Modbus Registernummer 1 die Byte 514/515 vom PA einlesen. Würde der Modbusmaster ein write output registers auf Modbus Registernummer 513 durchführen, dann würde er in die Adressen 2 und 3 vom PA des revPi Core schreiben.
Bitte lies auch Deine private Mail hier im Forum, Dort melde ich mich auch noch zusätzlich.
Unser RevPi Motto: Don't just claim it - make it!
Hallo Ingo,
ich habe nicht wirklich verstanden, was Du da vor hast. Bitte fang mal ganz von vorne an und beschreibe, welche Module Du in Deinem System hast und welche Daten vom DIo kommen oder dort hin sollen und welche Daten Du mit einem Modbus Gateway (RTU, TCP?) austauschen willst. Vielleicht kommen wir dann besser mit Deiner Frage klar. Ich dachte Du würdest gar kein Gateway Modul in Deinem System einsetzen, sondern übewr USB Daten austauschen?
ich habe nicht wirklich verstanden, was Du da vor hast. Bitte fang mal ganz von vorne an und beschreibe, welche Module Du in Deinem System hast und welche Daten vom DIo kommen oder dort hin sollen und welche Daten Du mit einem Modbus Gateway (RTU, TCP?) austauschen willst. Vielleicht kommen wir dann besser mit Deiner Frage klar. Ich dachte Du würdest gar kein Gateway Modul in Deinem System einsetzen, sondern übewr USB Daten austauschen?
Unser RevPi Motto: Don't just claim it - make it!
Hallo Volker.
nein ich habe kein Physisches Gerät, ich habe dies Virtuell. Was auch so Funktioniert, ich kann daten Senden und auch Empfangen. Aber eben leider nur die Adressen von dem Virtuellen gerät.
Ich habe da wo etwas Falsch gedacht das es so einfach wäre.
Eigendlich Dachte ich, naja wenn das mit dem Modbus geht kannst du ja ganz Esay über den Modbus eine verbindung zum Pi herstellen und über HTML und JAVA script, was auch so geht, wo ich dann eine Visualisierung habe in der meine Ein und Ausgänge die ich sehen und schalten möchte (DIO) ganz einfach ansprechen.
Leider musste ich Festellen das dies doch nicht so einfach ist.
Muss ich nun jeden Eingang jeden Ausgang den ich in der Visu habe als Bit, Byte oder Word an den Modbus übergeben?
oder reicht es wenn ich in der Pictory die Adressen vom DIO in die IN OUTPUT liste von dem Modbus teil schreibe.
soll heissen, ich habe Adresse
DIO Modbus Slave
INPUT_1 AT %IX1.9.0 Output_1_i07 AT %QW1.555:
würde dann so aussehen
INPUT_1 AT %IX1.9.0 IX1.9.0 AT %QW1.555:
so meine ich das? oder geht das so nicht.
ich hoffe du hast nun meine Fragestellung verstanden.
nein ich habe kein Physisches Gerät, ich habe dies Virtuell. Was auch so Funktioniert, ich kann daten Senden und auch Empfangen. Aber eben leider nur die Adressen von dem Virtuellen gerät.
Ich habe da wo etwas Falsch gedacht das es so einfach wäre.
Eigendlich Dachte ich, naja wenn das mit dem Modbus geht kannst du ja ganz Esay über den Modbus eine verbindung zum Pi herstellen und über HTML und JAVA script, was auch so geht, wo ich dann eine Visualisierung habe in der meine Ein und Ausgänge die ich sehen und schalten möchte (DIO) ganz einfach ansprechen.
Leider musste ich Festellen das dies doch nicht so einfach ist.
Muss ich nun jeden Eingang jeden Ausgang den ich in der Visu habe als Bit, Byte oder Word an den Modbus übergeben?
oder reicht es wenn ich in der Pictory die Adressen vom DIO in die IN OUTPUT liste von dem Modbus teil schreibe.
soll heissen, ich habe Adresse
DIO Modbus Slave
INPUT_1 AT %IX1.9.0 Output_1_i07 AT %QW1.555:
würde dann so aussehen
INPUT_1 AT %IX1.9.0 IX1.9.0 AT %QW1.555:
so meine ich das? oder geht das so nicht.
ich hoffe du hast nun meine Fragestellung verstanden.
Hallo Volker
Erstmal ganz herzlichen Dank für die ausführliche Antwort!
Dann werde ich mich mal durch die Betriebsmodi des Zählers ackern und schauen, welche Möglichkeiten sich ergeben.
Besten Dank und beste Grüsse,
Silvan
Erstmal ganz herzlichen Dank für die ausführliche Antwort!
Dann werde ich mich mal durch die Betriebsmodi des Zählers ackern und schauen, welche Möglichkeiten sich ergeben.
Besten Dank und beste Grüsse,
Silvan
@Volker: Ich würde dir auch sehr gerne auf deine Private Nachricht antworten - leider scheine ich das irgendwie nicht zu dürfen:
Beste Grüsse,
Silvan
Kannst du das irgendwie freischalten, oder mir eine E-Mail Adresse schicken? Danke vielmals!Leider bist du nicht berechtigt, diese Funktion zu nutzen. Du hast dich vermutlich erst vor kurzem registriert und musst dich noch mehr an Diskussionen im Board beteiligen, damit du diese Funktion nutzen kannst.
Beste Grüsse,
Silvan
silvan wrote:@Volker: Ich würde dir auch sehr gerne auf deine Private Nachricht antworten - leider scheine ich das irgendwie nicht zu dürfen:Kannst du das irgendwie freischalten, oder mir eine E-Mail Adresse schicken? Danke vielmals!Leider bist du nicht berechtigt, diese Funktion zu nutzen. Du hast dich vermutlich erst vor kurzem registriert und musst dich noch mehr an Diskussionen im Board beteiligen, damit du diese Funktion nutzen kannst.
Beste Grüsse,
Silvan
Hallo Silvan,
wir haben deine Userrechte nun so geändert, dass du jetzt auch PN schreiben kannst. Sollte es immer noch nicht funktionieren, bitte nochmals melden. Danke.
