EtherCAT -> MQTT mit RevPi Connect

[nmg97]

Leider habe ich bisher noch gar keine Erfahrung mit Python gemacht und würde daher eher die Variante mit dem replace_io_file versuchen.

Könntest du mir hier vielleicht einen Tipp geben, wie ich da am besten vorgehe? Wo befindet sich das file bzw. wie erzeuge ich es?
Vielen Dank!

Viele Grüße
Nina

[nicolaiB]

Du verwendest revpipyload als MQTT Connector? Dort kannst du auch den Pfad zur replace_io Datei konfigurieren (https://revpimodio.org/revpipyplc/revpipyload)

Gruß Nicolai

[nmg97]

Hi Nicolai,

vielen lieben Dank! Es funktioniert (fast), jedoch wird mir der Wert nach dem Komma einfach abgeschnitten.
Hast du eventuell eine Idee wodran das liegt?
Ich habe meine REAL Variable als float (f) im replace_io_file formatiert.

Viele Grüße
Nina

[nicolaiB]

Hi Nina,

kannst du vielleicht mal deine replace IO Datei hier teilen?

Gruß Nicolai

[nmg97]

Hi Nina,

kannst du vielleicht mal deine replace IO Datei hier teilen?

Gruß Nicolai

Anbei die Datei:

replace_ios.zip

(311 Bytes) Downloaded 789 times

...ganz simple gehalten für diesen einen Wert... wie gesagt: im Prozessabbild kommt der richtige Wert als binär oder auch hex an (egal ob positiv oder negativ).
Mir kommt es so vor, als ob die Nachkommastelle einfach nur abgeschnitten (nicht gerundet) wird, da z. B. sowohl 19.24 als auch der Wert 19.65 als 19 ausgegeben werden.

Viele Grüße
Nina

[nicolaiB]

Nutzt du dabei die originale RAP, oder deine modifizierte Version? Da revpimodio2 die anderen Datentypen auf dem Gateway nicht unterstützt, kann es sein, dass es nur mit der original RAP Datei (mit den Bytes) funktioniert.

Gruß Nicolai

[nmg97]

Ich nutze die modifizierte RAP-Datei sowie eine entsprechende Konfiguration im EtherCAT Master.
Ich übertrage Bits, Bytes, Worte, Doppelworte und jetzt auch noch ein REAL (im Gateway als Doppelwort (mit VZ!) interpretiert, durch piTest fürs Prozessabbild bestätigt, da Bitmuster und hexadezimal passen sowie die Dezimalzahl mit VZ).
Es funktioniert also bis dahin dementsprechend, jedoch ist die Darstellung nicht korrekt.
All diese Werte werden mir nämlich nur als vorzeichenlose Dezimalzahl in MQTT angezeigt, was in meinem Fall bis auf für den REAL Wert (hier Gleitkommazahl benötigt) erst einmal egal wäre.

Daher meine Idee den REAL Wert mit dem replace_io_file als float zu formatieren -> Gleitkommazahl aus 4 Byte, theoretisch genau das was ich brauche.
Und das funktioniert leider nur halb, der Wert vor dem Komma passt, danach ist einfach nichts mehr... einfach abgeschnitten Dies wäre noch okay, wenn er den Wert runden würde, aber auch bei z. B. -19.99 erhalte ich nur -19 usw.

Wenn ich jetzt die originale RAP Datei nutze, kann ich doch gar keine Werte mehr größer als 1 Byte in PiCtory definieren, oder?

Viele Grüße
Nina

Ergänzung: hier ein Screenshot des Prozessabbilds für den REAL-Wert -15.34, in MQTT wird dieser Wert (ohne die replace_io Formatierung!) als vorzeichenloser Dezimalwert angezeigt also: 3245699236
Mit der Formatierung in float wird er in MQTT als -15 angezeigt.

Prozessabbild.png (120.89 KiB) Viewed 15220 times

[nicolaiB]

Ich denke das Problem ist, dass revpimodio nicht anderen Datentypen als einem Byte auf den Gateways umgehen kann. Daher wird es ohne patchen von revpimodio darauf hinauslaufen, dass du die originale RAP Datei nimmst und deine IOs in der replace_io definierst.

Wenn ich jetzt die originale RAP Datei nutze, kann ich doch gar keine Werte mehr größer als 1 Byte in PiCtory definieren, oder?

Das ist im Falle von revpimodio egal, da es die Bytes selbst entsprechend zusammenbaut (4 aufeinander Folge Bytes werden z.B. für den REAL verwendet)

Gruß Nicolai