MDT AKU 2416.03: komisches Verhalten bei Sperr-KO

[jcd]

Hallo in die Runde,

ich habe bei einem MDT Universalaktor ein komisches Verhalten bei zwei Kanälen aus dem ich mir keinen Reim machen kann.
Es geht um das Sperr-KO zweier Kanälen (110 und 170). Es sollte sich eigentlich um 1 Bit-Objekte DTP 1.003 handeln (das ich wie bei allen Sperr-KO auf 1.002 geändert habe, weil ich die "freigeben" Übersetzung irritierend finde). Dennoch erhalte ich als Rückmeldung vom Aktor "$0F | Wahr" bzw. beim anderen KO "$28 | Wahr".

Ich schreibe dann ein $00 oder $01 auf das KO und für ca. 30-40 Sekunden meldet der Aktor auf Lese-Requests auch was ich zuvor gesendet habe. Danach kommen auf die Lese-Anfrage wieder die seltsamen Werte. An die KO sind nur je einzige GA verbunden und zwischen richtiger und falscher Antwort gibt es keine weitere Kommunikation mit dieser GA. Als Flags sind KLSÜ gesetzt.

Ich habe bereits die Applikation vollständig übertragen und einen freien Kanal mit den exakt gleichen Einstellungen belegt in der Hoffnung das Verhalten reproduzieren können. Beides ohne Erfolg. Ich habe weiterhin testweise eine "frische" GA ohne weitere Objekte und als einzige GA an das problematische KO gebunden - selbes Verhalten.
Die Sperrobjekte der anderen Kanäle zeigen keine Auffälligkeiten.

Was ist da los?

[jcd]

Hier noch ein Mitschnitt aus dem Gruppenmonitor:
grafik.png

[gbglace]

Bei den PM hat MDT ja so etwas wie eine Rückfallzeit aus den Sperren eingebaut, hast da auch etwas beim Aktor eingestellt?

Wozu das Ü Flag?

K damit das Ko kommunizieren kann
S Damit es den Sperrbefehl in sich aufnehmen kann
L damit Du es Abfragen kannst

[jcd]

ja… ich habe bei Rückfallzeit etwas eingestellt. Testweise auch mal rausgenommen. Folglich auch das „Ü“ damit der Aktor den Rückfall der Sperre auch sendet.

Mich irritiert ja am meisten, dass da, obwohl der Datentyp nur 1 Bit ist, andere Daten gesendet werden.
Als nicht-mehr-ganz-Laie würde ich sagen, dass ist ein Speicherüberlauf, oder ist das „normal“?


Edit: Der Rückfall gilt aber ja nur für das zweite Sperrobjekt?! Vielleicht sollte ich das Ü mal wegnehmen…

[gbglace]

Wenn KO's grundsätzlich eigentlich nur als Eingangsobjekt definiert sind, muss nicht alles so sauber sein wenn man da einfach die Flags ändert. Das kommt da dann immer drauf an wie das in der Firmware gebaut ist.

Da der Aktor kein separates Status KO für die Sperre hat würde ich da kein Ü setzten, weil dieses Telegramm sieht dann einfach nur nach Befehl aus, es sei denn Du baust eine GA 'Status Sperre' verbindest die als Erste GA und danach die GA 'Befehl Sperre'. Dann würde der Aktor eine andere GA verwenden für die Beantwortung der Leseanfragen und seiner Meldung bei interner eigener Umschaltung, halt die Status-GA und nicht die GA 'Befehl Sperre'.

[Beleuchtfix]

Es wird schon ein Byte gesendet, aber Standardmäßig bei einem DTP mit Bit Typ nur $00 oder $01
Gruß
Florian

[jcd]

Heute bekomme ich übrigens andere Werte: $3F statt $0F...

Ich habe das Ü-Flag rausgenommen, das Verhalten bei Sperren und Entsperren auf "keine Änderung" gesetzt und die Priorität/Zwangsführung deaktiviert. Damit sind alle "Zusatzfunktionen" hinsichtlich der Sperre für diesen Kanal deaktiviert und das ganz langweiliger Standard. Für die normale Sperre gibt es auch gar keine automatische Rückfall-Funktion. Sprich: der Aktor kann den Sperrstatus gar nicht selbsttätig ändern. Als Flags sind für dieses KO (110) nur KLS gesetzt.

Und es ist weiterhin so:
- Ich schreibe ein $00 | Falsch auf das KO
- Ich lese mehrfach das KO aus. Die ersten Sekunden bekomme ich mehrfach $00 | Falsch als Antwort, aber nach spätenstens etwa 40 Sekunden dann irgendwas anderes - heute $3F | Wahr
- Während dessen zeigt der Gruppenmonitor keine anderen Telegramme mit dieser GA, es gibt während dessen sogar überhaupt keine anderen Telegramme von oder zu dem Aktor.
- Tatsächlich ist der Kanal in diesem Zustand gar nicht gesperrt

Bei weiteren Test habe ich dann auch $01 | Wahr auf das KO geschrieben. Auch in dem Fall bleibt die Rückmeldung nicht bei diesem Wert. Ich bekomme z.B. $02 als Rückmeldung. Der Kanal ist aber tatsächlich gesperrt. Momentan steigt der Rückmelde-Wert gelegentlich an. Bin derzeit bei $06, aber ich erkenne kein Schema, wodurch sich die Zahl erhöht. Gerade eben einfach zwischen zwei Lese-Aktionen...

Seltsamerweise gibt es auch Kanäle wo das mit dem Lesen der Sperre überhaupt kein Problem ist. Der tatsächliche Sperr-Zustand entspricht immer dem was zuletzt geschrieben wurde. Die Rückmeldung dazu ist aber falsch.

hjk: Kannst du da etwas zu sagen? Sollte es eigentlich funktionieren beim AKU 2416.03 die Sperr-Objekte durch Setzen des L-Flags auslesen zu können?

[jcd]

Okay, ich habe den Auslöser gefunden:

Die Probleme verschwinden, wenn ich den Betriebsstunden-Zähler des Kanals deaktiviere! Es passt auch zu den übrigen Kanälen. Bei den beiden, wo der Betriebsstundenzähler aktiv ist, erhalte ich fehlerhafte Rückmeldungen. Bei den Kanälen, bei denen die Rückmeldungen zum Sperr-Objekt funktionieren, sind die Betriebsstundenzähler nicht aktiv.

Nach Reaktivierung des Betriebsstundenzählers (startet dann bei 0) funktioniert die Rückmeldung des Sperr-Objektes (KO110) zunächst korrekt. Zum Testen habe ist das S-Flag für den Betriebsstundenzähler (KO 108) gesetzt.
Schreibe ich 255 s (=00 00 00 FF) auf das KO 108 passiert bei KO 110 noch nichts und bleibt bei $00. Schreibe ich 256 s (=00 00 01 01) auf das KO 108, springt KO 110 auf $01.

Damit handelt es sich hier tatsächlich um einen Speicherüberlauf. Das KO 110 gibt beim Lesen den Wert des zweiten Bytes von KO 108 zurück. Bei 1535 s (00 00 05 FF) ist der Sperr-Status $05 und bei 1536s (00 00 06 00) dann $06.

[Beleuchtfix]

Saubere Fehlersuche und tolle Beschreibung
Gruß Florian

[jcd]

Danke, ich habe es nun auch dem MDT-Support per Mail gemeldet.

Seltsam, dass dies noch niemandem aufgefallen ist. Der AKU ist ja schon ein paar Tage älter. Werden die Sperren so selten verwendet oder liest man die üblicherweise nicht aus?

Mein Plan ist, dass es für alle Kanäle und Geräte eine Seite in der Visu gibt, wo man alles manuell sperren kann um im Bedarfsfall unpassende Automatiken zu überschreiben. Da möchte ich dann natürlich den Sperr-Status sehen können.

[Beleuchtfix]

na ja, Betriebsstunden zählen, Sperren setzten, das L Flag setzen um den Aktor auszulesen (früher hat man da immer den Schaltbefehl ausgewertet) alles zusammen ist nicht mehr Standard
Gruß Florian

[jcd]

Bisher habe ich leider keine Rückmeldung, außer dem dem ersten „vielen Dank, ich gebe das an die Entwicklungsabteilung weiter“ erhalten.

[hjk]

Da war tatsächlich ein Fehler, der bisher nicht aufgefallen ist. Wird mit dem nächsten Firmwareupdate in ein paar Wochen abgestellt.

[jcd]

Danke für die Rückmeldung!
Freut mich geholfen zu haben und dass der Fehler dann bald behoben ist.