Fehlerhafte Werte in Prozessabbild ModBus RTU Master

Hallo zusammen,

Mein Vorhaben:
Ich möchte mittels RevPi Connect und der integrierten RS485 Schnittstelle bis zu 8 EnergyMeter (Stromzähler) auslesen, die Werte verarbeiten und auf einer CAN-Schnittstelle ausgeben.

Die Hardware:
RevPi Connect
RevPi con CAN Schnittstelle
Schneider Electric iEM 3155 (Stromzähler)

Die Software:
Ich habe zur bessern Übersicht mein Programm in drei Teile geteilt:
1. ModBus Kommunikation
2. CAN-Kommunikation (läuft bereits tadellos)
3. Eine Art "Main" um die Abläufe zu steuern

Das Problem:
Ich lese bereits über den Modbus RTU Master 150 Werte ein und greife mittels Python Skript auf das Prozessabbild wie von Volker in seinem "Zugriff mit Python" Beitrag beschrieben zu. viewtopic.php?f=10&t=32
Soweit so gut. Leider bekomme ich immer wieder inkorrekte Werte angezeigt. Lasse ich mir zum Beispiel die Spannung der Phase 1 (Offset 27) anzeigen spuckt meine Funktion erst 233,xxxx Volt aus dann wieder "nan" sprich "not a number". (siehe Bilder)
Auch wenn ich mir die Werte direkt über piTest -r Slv1_Volt_P1_A anzeigen lasse sehe ich direkt das die Werte hier auch zwischen korrekt (~0x436C) und inkorrekt (0xFFC0) schwanken.
Dies bedeutet für mich das ich entweder zur falschen Zeit auf das Prozessabbild zugreife oder das ich falsche Werte empfangen.
Um dies genauer analysieren zu können habe ich eine weiter Config in PiCtory erstellt und lese in dieser nur 4 Register fehlerfrei ein.
Auch habe ich mal die Action Intervalle verändert (deshalb die ungeraden Zahlen im Bild unten) aber bringt nur eine geringe Verbesserung.

Ich komme wirklich nicht mehr weiter und wende mich nun an euch!

Hallo zusammen,

habe jetzt meinen Fehler gefunden.
Ich hab bei der Config in PiCtory zweimal das gleiche Register ausgelesen.
Sprich ich habe in Action ID Register Addr. 3000 bzw. 3001 ausgelesen da ich bei Quantity of Registers 2 eingetragen habe.
Zusätzlich habe ich noch in Action ID 2 die Register Addr. 3001 ausgelesen.
Das hat dann dazu geführt das bei falschem Timing quatsch im Prozessabbild steht.
Berichtigt man die Angaben und ließt tatsächlich nur einmal die Werte aus kommen immer plausible Werte.

Leider habe ich jetzt ein neues Problem:
Da ich ja wie oben beschreiben mehrere gleiche Slaves (EnergyMeter) auslesen will habe ich diese in den ModBus RTU Master 150 eingetragen.
Es sind immer die selben Signale nur die Slave Addr. ändert sich.
Ich bin jetzt bei 3 Slaves und mein Problem ist das die Werte quasi nur noch alle 5 sec aktualisiert werden. Das reicht natürlich nicht.
Hat jemand etwas ähnliches schon einmal beobachtet bzw. kann mir sagen was ich falsch mache?
Die Zeit ist wenn ich mittels piTest auslese auch bei ca. 5 sek bis die Werte aktualisiert werden.

Viele Grüße
Raphael

Hallo Raphael,

welche Baudrate hast du konfiguriert?

Wenn du 19200 eingestellt hast, kannst du mit deinem „Action Interval“ auf 50 ms gehen.
Wenn du mit der Baudrate noch höher gehst, kannst du auch mit dem „Action Interval“ noch weiter runter gehen.

Gruß
Eduard

Moin Moin,

bei mir tritt derzeit leider ein ähnlicher Fehler, wie der ürsprünglich beschriebene auf:
Ich verwende einen RevPi Connect als ModBus TCP Master um 30 Register zu lesen und 400 Register zu schreiben. Ich kommuniziere alle Werte direkt über das Prozessabbild mittels Python. Ich verwende gemäß der Beispiele aus den Tutorials, die Datei "/dev/piControl0" und lese und schreibe direkt mittels struct.pack und struct.unpack. Bei bedarf kann ich gerne noch Codebeispiele schicken. Aufgrund der Menge an Registern lese und schreibe ich zusammenhängende Blöcke, von Register, immer am Stück aus (natürlich maximal 32). Ich verwende entprechend auch immer nur eine Action pro zusammenhängenden Block. An die Action habe ich keine große Anforderung an einen Echtzeitberieb und verwende für alle schreibenden Register ein Intervall von 7000ms, alle lesenden 1000ms.
Mein Problem besteht nun darin, dass in den ersten mehrtägigen Tests einzelne Register, immer mal auf Werte sprigen, die ich nicht gesetzt habe / wollte. Wenn dies auftritt, betrifft es meistens mehrere und manchmal alle Register eines Device.
Lesend tritt der Fehler ca. einmal pro Stunde auf, schreibend ca. 10 mal am Tag. Der Wert wird zwar umgehend wieder auf den korrekten zurück gesetzt, aber gerade für die schreibenden Werte ist das leider nicht tollerabel. Ich habe jetzt mehrfach kontrolliert, dass ich keine sich überchneidenen Register in unterschiedlichen Actions definiert habe und würde mich freuen, wenn mir jemand behilflich sein könnte bzw. einen kleinen Tip für mich hat.

Beste Grüße
Matthias

Hallo,

es scheint als kämen hier zwei Fehler zusammen. Zum einen habe ich einen Bug in meinem übergeordneten Programm gefunden, wodurch ich falsche Werte in das Prozessabbild geschrieben habe. Nachdem ich den Fehler behoben habe, lese ich leider immer noch sporadisch (+/- alle 15 Minuten) einige register mit 0 aus. Schreibend logge ich jetzt auf dem Slave sekündlich, wo mir aufgefallen ist, dass auch hier einige Register sporadisch auf 0 schalten. In meinem übergeordneten Programm setzte ich das Prozessabbild alle 30 Sekunden, der Fehler bzw. die 0 tritt immer genau ein schreibzyklus des RevPi auf (in meinem Fall 7000ms) und springt danach wieder auf den von mir weit vorher geschriebenen Wert.
Derzeit tritt der Fehler ausschließlich auf dem ModBus TCP Master Device auf, in dem Inputs und Outputs verwendet werden. Ich würde das als nächstes ändern und ein neues Device nur für Inputs konfigurieren, sollte doch aber eigentlich keine Auswirkungen haben oder? Darüber hinaus ist auffällig, dass der Wert immer auf 0 springt, was ebenfalls der in PiCtory verwendete default Wert ist. Könnte es unter Umstanden sein, dass aus irgendeinem Grund der Action Reset des Device getriggert wird, wodurch der Wert kurzzeitig auf den default Wert gesetzt wird?

Ich bin leider immernoch ein wenig ratlos und würde mich über Input oder Vorschläge sehr freuen.

Gruß
Matthias

Hallo bitte schaue Dir die Register der ActionSatatus und des Master an, siehe hier: https://revolution.kunbus.de/tutorials/ ... verwenden/