IPS 6.3 / Umsetzung LCN Commandos

Hallo zusammen,

ich habe ein paar Test zur 6.3 und der Umsetzung zur Auswertung der Quiitierung gemacht:
a) Schalten eines Ausgangs ( $noerror = RequestAction($id_Test_State, $State); )

Wenn ich es richtig beobachte, wird das Schalten des Ausgangs schon nach Empfang der Quittierung in IPS gesetzt.
(z.B. -M000013!).
Das passt aus meiner Sicht nicht, es bestätigt lediglich, das der Befehl am Modul angekommen ist.
Die Umsetzung in IPS sollte erst erfolgen, wenn das auch durch das Modul gemeldet wird (z.B. :M000013A3100).
Ich muss leider beobachten, da die Meldung zum Status des Ausgangs auch mal etwas braucht. (> 4 Sekunden)

Was mir immer noch fehlt ist eine Wiederholung des Befehls, wenn es nicht umgehend Quittiert wird.

Bei dem Befehl LCN_SendCommand sehe ich keine Auswertung der Quittierung.

Das ist korrekt.

Das wäre über den Ablaufplan möglich. Dort gibt es passende Retry’s.

Wenn ich in den Quellcode gucke, kann das eigentlich nicht sein. Die Variable wird erst gesetzt, wenn das echte Feedback von Gerät kommt. Wir haben das „direkt“ setzen bei einigen anderen System implementiert → Das Verhalten ist dann aber eigentlich immer über den Satz „Emuliere Status“ veränderbar. Bei LCN warten wir jedoch immer auf das echte Feedback des Wertes.

paresy

Thema Quittierung:
Die Quittierung stellt sicher, das das Kommando am Modul angekommen ist.
Das ist in meinem Verständnis mehr eine Absicherung das der Bus frei ist.
Wiederholungen auf Applikationsebene führen zu langen Laufzeiten / Verzögerungen und machen selbst einfache Abläufe komplex. Das kann viel besser innerhalb von IPS umgesetzt werden.

Durch die Auswertung der Quittierung und Wiederholung würde vermutlich auch die meisten Fehlermeldung zu den Statusabfragen sich erledigen und Warnungen bei Kommandos.

Gibt dafür einen Grund?
Ich nutze den Befehl gerne um Tasten ins LCN System zusenden.

Ich werde einen neunen Trace machen und sende dir das Ergebnis, vielleicht interpretiere ich es falsch.

Gruß
Jan Peter

Hallo paresy,

[quote=„paresy, post:2, topic:130378“]

Das habe ich mir wieder angesehen und es lässt sich nicht bestätigen.

Folgende Versuchs Reihe
Ausgang Schalten (bei Fehler wird der Befehl wiederholt)

Event wertet Ausgang Aus / Timeout 30 Sekunden
2 Sekunden Warten
Ausgang Umschalten (bei Fehler wird der Befehl wiederholt)

Das Ganze 10.000Mal.

Ergebnis:
35 Kollisionen = > LCN Befehl meldet Fehler ( $noerror = RequestAction($id_Test_State, $State); )
Aber auch 4 mal der Event nicht ausgelöst.

Im Trace sieht das wie folgt aus:


Schalten
09/24/22 02:02:26 | TXT | WAITING | >M000013!A3DI100000<LF>
09/24/22 02:02:26 | HEX | WAITING | 3E4D30303030313321413344493130303030300A
09/24/22 02:02:26 | TXT | TRANSMIT | >M000013!A3DI100000<LF>
09/24/22 02:02:26 | HEX | TRANSMIT | 3E4D30303030313321413344493130303030300A

Quittierung
09/24/22 02:02:26 | TXT | RECEIVED | -M000013!
09/24/22 02:02:26 | HEX | RECEIVED | 2D4D30303030313321

Ausgang ist geschaltet
09/24/22 02:02:26 | TXT | RECEIVED | :M000013A3100
09/24/22 02:02:26 | HEX | RECEIVED | 3A4D3030303031334133313030
// so soll es sein...


Schalten
09/24/22 02:02:27 | TXT | WAITING | >M000013!A3DI000000<LF>
09/24/22 02:02:27 | HEX | WAITING | 3E4D30303030313321413344493030303030300A
09/24/22 02:02:27 | TXT | TRANSMIT | >M000013!A3DI000000<LF>
09/24/22 02:02:27 | HEX | TRANSMIT | 3E4D30303030313321413344493030303030300A

keine Quittierung
09/24/22 02:02:27 | TXT | RECEIVED | %M000013.A01208245
09/24/22 02:02:27 | HEX | RECEIVED | 254D3030303031332E413031323038323435

Ausgang ist geschaltet
09/24/22 02:02:27 | TXT | RECEIVED | :M000013A3000
09/24/22 02:02:27 | HEX | RECEIVED | 3A4D3030303031334133303030

Schalten
09/24/22 02:02:28 | TXT | WAITING | >M000013!A3DI100000<LF>
09/24/22 02:02:28 | HEX | WAITING | 3E4D30303030313321413344493130303030300A
**// 4 Sekunden passiert nichts**
09/24/22 02:02:32 | TXT | TRANSMIT | >M000013!A3DI100000<LF>
09/24/22 02:02:32 | HEX | TRANSMIT | 3E4D30303030313321413344493130303030300A

???? Erneutes Schalten
09/24/22 02:02:32 | TXT | WAITING | >M000013!A3DI000000<LF>
09/24/22 02:02:32 | HEX | WAITING | 3E4D30303030313321413344493030303030300A

Quittierung
09/24/22 02:02:32 | TXT | RECEIVED | -M000013!
09/24/22 02:02:32 | HEX | RECEIVED | 2D4D30303030313321

???? Erneutes Schalten
09/24/22 02:02:32 | TXT | TRANSMIT | >M000013!A3DI000000<LF>
09/24/22 02:02:32 | HEX | TRANSMIT | 3E4D30303030313321413344493030303030300A

Quittierung
09/24/22 02:02:32 | TXT | RECEIVED | -M000013!
09/24/22 02:02:32 | HEX | RECEIVED | 2D4D30303030313321

Ausgang ist geschaltet
09/24/22 02:02:32 | TXT | RECEIVED | :M000013A3000

Timeout???
09/24/22 02:02:32 | HEX | RECEIVED | 3A4D3030303031334133303030
09/24/22 02:02:33 | TXT | TRANSMIT | ^ping507<LF>
09/24/22 02:02:33 | HEX | TRANSMIT | 5E70696E673530370A
09/24/22 02:02:33 | TXT | RECEIVED | ^ping507-
09/24/22 02:02:33 | HEX | RECEIVED | 5E70696E673530372D
.... kein M013

// Jetzt geht es weiter
09/24/22 02:02:58 | TXT | WAITING | >M000013!A3DI100000<LF>
09/24/22 02:02:58 | HEX | WAITING | 3E4D30303030313321413344493130303030300A
09/24/22 02:02:58 | TXT | TRANSMIT | >M000013!A3DI100000<LF>
09/24/22 02:02:58 | HEX | TRANSMIT | 3E4D30303030313321413344493130303030300A
09/24/22 02:02:58 | TXT | RECEIVED | -M000013!
09/24/22 02:02:58 | HEX | RECEIVED | 2D4D30303030313321

Meines Erachtens entsteht es, da der Timeout für die Quittierung 5 Sekunden ist.
Das ist länger als meine Wartezeit. Der Ausgang wurde geschaltet, obwohl keine Quittierung ist erfolgt ist.
// Eine Automatische Befehlswiederholung nach kurzem Timeout hätte es anders aussehen lassen.
Unbeantwortet bleibt wann dann die Quittierung gekommen wäre

Das ist soweit zwar logisch, erklärt aber nicht warum 4 Sekunden lang auf dem Bus eine Ruhe war.
Das kann ich nicht erklären, als wäre alles stehen geblieben auf dem LCN Bus.

Ich bitte dich hiermit die Befehlswiederholung mit einem kurzen Timeout einzubauen. 5 Sekunden Timeout sind wirklich lang.

Hallo paresy,

ich habe den Versuch wiederholt mit einer Wartezeit von 10 Sekunden.
Das Ergebnis entspricht meiner Erwartung, alle Schaltvorgänge sind sauber verlaufen.

Das ändert nichts an der Anfrage, eine Befehlswiederholung einzubauen, wenn die Quittierung nicht innerhalb kurzer Zeit kommt.

Die 5 Sekundenwartezeit passieren leider zu häufig.

Gruß
Jan Peter

Die 5 Sekunden kommen nicht von ungefähr. Insbesondere beim Abfragen von Werten der alten Module dauert es mal länger. Wobei dort @ralf sagte, dass die sehr sehr unzuverlässig kommen und das Log zumüllen. Ich bin am überlegen dies ohne Quittierung laufen zu lassen (da unkritisch) und dann könnte man die Wartezeit auch reduzieren. Falls da jemand Tests machen will, wie lange sowas dauern sollte, dann wäre das cool. (Andere System bekommen von uns 2 Sek)

Da wir aktuell in anderen Systemen ebenfalls keine Wiederholungen auf Systemebene anbieten, sehe ich hier wenig Chance, dass wir bei LCN damit kurzfristig anfangen werden.

paresy

Naja, nach deinen letzten Änderungen gibt es immer mal wieder Fehlermeldungen, aber deutlich weniger wie vorher. Ohne Quittung würde halt keine Fehler mewhr verursachen, wenn das konfigurierbar wäre, wäre es super, aber ich kann auch so damit leben.

Die Quittierung ist ein zusätzliches Signal auf dem Bus, nicht viel Content aber dennoch zusätzlich.
Von daher entsteht zusätzlicher Traffic.
Die Wartezeit reduzieren ist eine Spielart, die das eigentliche Problem nicht löst.

Mein Verständnis zu dieser Quittierung (Korrektur immer gerne)
Die Quittierung signalisiert dem Sender, das sein Befehl an das Modul gesendet werden konnte.
Der Bus war frei. Ist der Bus verstopft, gibt es keine Quittung. (es gibt keine Bus ist frei Kennung)
Daher hilft dann nur eine Wiederholung.

Bei meinem System, (46 Module) werden ca. 35 Befehle von 10.000 nicht quittiert (5 Sekunden Timeout). Das bezieht sich jedoch auf einen Durchschnitt.
Leider gibt es auch Lastspitzen, da merke ich es deutlicher. Dazu ist mir kein Weg eingefallen es in Zahlen umzusetzen. (muss ich drüber Nachdenken)

Das ihr ungerne Wiederholungen anbietet ist bei mir angekommen, löst bei mir die Frage aus warum? Hier würde das System wesentlich robuster werden.

Gibt dafür einen Grund?

Gruß Jan Peter

Es gibt diverse Arten von Quittierungen. Du müsstest explizit angeben, welche Art von Quittierung du erwartest. (Das war übrigens ein expliziter Wunsch von dir, dass wir die Quittierungen strikter durchführen :slight_smile: ) D.h. manchmal kommt die Quittierung mit : und manchmal kommt halt nur ein Wert mit % den wir aus Quittierung annehmen. Wir müssten also einen LCN_SendCommandEx anbieten dem du mitteilen kannst, worauf du eigentlich wartest. Theoretisch kann es ja sein, dass auf einen Befehl gar keine Antwort kommen muss. Das muss also konfigurierbar sein je nach PCHK Befehl.

Leider recht simpel: Der eher hohe Aufwand rechtfertigt aktuell nicht die Nachfrage nach solch einem Feature. Zumal der Ablaufplan ein Wiederholen Feature integriert hat, über den man kritische Abläufe realisieren könnte.

paresy

Hallo paresy,

Ich war davon ausgegangen, das alle Funktionsbefehle eine Quittierung anfordern können.
Beispiel:

M000013!MWT12 // Befehl
-M000013! // Quittung

Mir ging es nur um die Auswertung der Quittierung.
%xxx sind Messwerte, !xxx sind Statusmeldungen.

Moin,
ich glaube, wir müssen Unterschiede sehen …
Die LCN-Module „unter sich“ haben ‚nur‘ eine Kollisionserkennung (schauen also ob der ‚Bus frei‘ ist), eine Quittung für ein ausgeführtes Kommando lösen die Module nicht aus - zumindest sieht man da nichts im Bus-Monitor der LCN-Pro. Die Quittung kommt nur beim programmieren von Modulen mit der Pro.
Die Module reagieren nur auf eine Statusmeldung, was bei aufgerufenen Kommandos eigentlich zwangsläufig immer die Folge ist. Solche Meldungen können (nach einer älteren Aussage der LCN-Hotline) auch mal „verschluckt“ werden - vor allem beim dimmen mit großer Rampe (was eigentlich alle 2% eine Meldung erzeugt) ist das gut zu beobachten. Damit ist z.B. auch ein Schalt-Kommando an eine LED („Lämpchen“, für Summenbildung etc.) sicherer als das nur auf eine Meldung reagieren zu lassen.
Aus dem Gefühl/Erfahrung ist dieser „Effekt“ bei älteren Anlagen/Modulen häufiger zu beobachten.
Meine Versuche mit einem ‚nagelneuen‘ LCN-VISU (das jetzt laut ‚Waschzettel‘ eine Kollisionserkennung integriert haben soll) zeigen bei Auslösungen über die PCHK keinerlei Quittungen im Busmonitor. Die (bei mir schon recht seltene) „Nichtausführung“ von Kommandos ist aber auch damit immer noch vorhanden.

Ich weiß, dass die im Symcon fehlende Quittung von der LCN-Hotline beanstandet und gefordert wurde. Der Zeitrahmen in dem @paresy das umgesetzt hat ist typisch (für mich auch „legendär“) für Symcon. Einen wirklichen „Nutzen“ kann ich aber bislang nicht erkennen - ich sehe das ein wenig als „Ausrede“ der Hotline, weil sie derzeit keine bessere Idee zur ‚Fehlerbehebung‘ hatten. Da schiebt man das eben auf „systemfremde“ Hard- und Software. Soll heißen: warum hat man jetzt im VISU plötzlich eine Kollisionserkennung (= „sie arbeiten daran“)?

Das ist nur meine Meinung/Erfahrung.
Grüße, Uwe