Wird ein Drücken der "STOP" Taste an der MMaus als Nothalt interpretiert?

[Stuckalf]

Mahlzeit alle miteinander,

wird beim PWM Einsatz des LY-Decoders ein Drücken der "STOP" Taste an der MultiMaus oder LokMaus2 als Nothalt gewertet und werden die PWM-Ports dann direkt auf 0V, also LOW, gesetzt? Auch dann, wenn ich die Anfahr- und Bremsverzögerung über das "limitchange" Modul verwende?

Ich meinte, dass die Lok bei meinem Test auch durch das Drücken der "STOP" über die limitchange-Parameter eher langsam abgebremst wurde. Vielleicht habe ich mich vertan, aber das sah erst einmal nach einem gemütlichen Bremsvorgang aus.
Das wäre nicht optimal, da ich die "STOP" Taste ja eigentlich nur bei einer Notsituation auf der Anlage drücken würde.

[Zoltan]

Ich verwende "limitchange" nicht, da ich mit dem Fahrregler bremse (bin von den echten Loks so gewohnt). Bei der Z21 App steht die Lok sofort, wenn ich auf Stop tippe, als Notstopp wie es soll. Aber ich habe je eine LY in jede Lok und fahre sie direkt.

[little.yoda]

Sehr wahrscheinlich gibt es in LimitChange keine Behandlung für den Notstop.
Muss ich mir die Tage mal anschauen.

[little.yoda]

Habe mir die Sourcen nochmal angeschaut.

"limitchange" weiß nichts davon, ob ein emergency stop aktiv ist oder nicht, da das übergeordnete Modul sich um die Behandlung von emergency stops kümmert.

Und Lokospeed, als übergeordnetes Modul, setzt in diesem Fall einfach die Geschwindigkeit auf 0 und "limitchange" regelt die Geschwindigkeit langsam herunter.

Um bei der Implementierung sauber zu bleiben, muss ich limitchange so aufbohren, dass man die Limitierung deaktivieren (=emergency stop) bzw. aktivieren (=normaler Modus) kann.

[Stuckalf]

Das wäre toll.

Wie löst Du das? Es gibt doch bestimmt eine Klasse, die die DCC Befehle auswertet.
Implementierst Du dort als neues Attribut den Status (also entweder "emergency stop" oder "normaler Modus") oder beispielsweise ein boolsches Attribute "EmergencyStop" als TRUE oder FALSE und übergibst das der geänderten Klasse "FILTERLIMITCHANGE"?
Oder hebelst Du im Falle eines Nothalts FILTERLIMITCHANGE komplett aus und setzt die PWM Ports direkt zurück?
Würde mich von der Software Seite interessieren.

[little.yoda]

Wahrscheinlich wird es ein neues "Attribute" geben.

Aktuell übergibt der LocoDecoder "nur" die Geschwindigkeit[*]
Ich werde wahrscheinlich LimitChange um ein Attribute enable/disable ergänzen.

Während des normalen Betriebes ist enable auf true/1.
Im Fall des Nothalts wird enable vom LocoDecoder auf false/0 gesetzt.
In diesem Fall wird LimitChange die Lokgeschwindigkeit (in diesem Fall 0) einfach durchreichen.

Langfristig:
Mit dem separaten Attribute könnte man erreichen, dass man LimtChange auch mit Hilfe einer F-Taste aktiviert bzw. deaktiviert. Ich muss mir nur überlegen, wie ich damit umgehe, dass enable/disable dann von zwei Module beschrieben und ggf. überschrieben wird.



[*] IN der Software "SD" => Speed with Direction.

[Stuckalf]

Ich muss mir nur überlegen, wie ich damit umgehe, dass enable/disable dann von zwei Module beschrieben und ggf. überschrieben wird.

Ich habe nur grob den Code überflogen.
Falls ich das richtig sehe, wird der Emergency-Status schon im System festgehalten, z.B. über die Methode isEmergency oder den Zustand EMERGENCYActive. Das müsste noch an LimitChange übergeben bzw. dort ausgewertet werden.
Zusätzlich wäre ein schon von Dir erwähntes neues Attribut nötig, passend wäre vielleicht isLimitChangeEnabled oder etwas in der Art. Damit bliebe ein Ändern der Zustände konkurrierend über zwei Module ausgeschlossen und die Zustände bleiben in ihrer Funktionsweise klar erkennbar.

Mein Konstruktor würde dann etwa so deklariert:
FilterLimitChange::FilterLimitChange(int r, String n, bool isEmergency, bool isLimitChangeEnabled)
usw.

Ich vermute, dass könnte so ähnlich umsetzbar sein. Ist aber nur auf die Schnelle mit der heißen Nadel gestrickt.

[little.yoda]

Und so einfach ist es leider nicht.

LimitChange kann an verschiedenen Stellen eingesetzt werden. Auch z.B. wenn man ein Servo ansteuern will und die Ausrichtung (=den Wert) nur langsam ändern will.

Deshalb muss ich die Lösung generisch genug eingebauen, dass so etwas weiterhin möglich ist.

[Zoltan]

Genau das meinte ich mit "bitte nur vorsichtig bei Neuerungen "

Ich bin eben mal etwas paranoid nach > 40 Jahre IT und Programmierung/Support von großen modularen Systemen... wir haben damals nach 1 Woche Ideen-einsammeln, 1 Woche Planung, 2 Wochen Code Ändern und 4 Wochen Testen, nach etwa 2 Monate ins Beta gegangen (banking Software auf IBM AIX Sytem).

Aber ich bin sicher, dass Sven es korrekt umsetzen wird

[little.yoda]

Mir sind die Anmerkungen von anderen sehr wichtig. Ab und zu neige ich dazu, mich zu sehr in den Details zu verlieren. Dann hilft ein Blick von außen.

@Zoltan:
Ich glaube wir haben alle verstanden, was deine Bedenken sind.