Motorsteuerung mit zwei Taster

[Beleuchtfix]

Nach allem, was ich bis jetzt weiß, werden die Befehle der Reihe nach A1-A8, jeweils zuerst kurz - lang -los und dabei zunächst Erstbelegung-Zweitbelegung ausgeführt.

Es ist schon sehr wichtig, welcher Befehl an welcher Stelle kommt. Und ob eine Reaktion nun vor oder nach dem nächsten Befehl kommt, ist nicht unbedingt vorherzusehen. Bei richtig zeitkritischen Anwendungen muss man noch eine Zeitverzögerung einbauen.
Gruß
Florian

[H.Boldt]

Ich güße dich,

[zitat]Original von Beleuchtfix
Nach allem, was ich bis jetzt weiß, werden die Befehle der Reihe nach A1-A8, jeweils zuerst kurz - lang -los und dabei zunächst Erstbelegung-Zweitbelegung ausgeführt.

Das sehe ich auch so :-O

Es ist schon sehr wichtig, welcher Befehl an welcher Stelle kommt. Und ob eine Reaktion nun vor oder nach dem nächsten Befehl kommt, ist nicht unbedingt vorherzusehen. Bei richtig zeitkritischen Anwendungen muss man noch eine Zeitverzögerung einbauen.


Wo wurdest du sie einbauen, ich bin da noch zu schwach

Gruß Heinrich

[Beleuchtfix]

Jetzt bin ich die einzelnen Beispiele noch einmal genauer durchgegangen. Kann es sein, dass die Tastensperre per Schieberegister durchgereicht wird und zwischendurch nicht perfekt ist? Beim Abwärtsschalten kommt das weniger zum tragen, da ja immer das höchste Register erst arbeitet.
Das wäre dann aber schon ein gewisser Firmware Bug.
Gruß
Florian

[MartinH]

Ueli, danke für Deine Variante und den Timing-Problem-Nachweis !
Heinrich, freut mich, dass Du jetzt eine laufenden Lösung hast.
(Bitte die Initialisierung weiterhin gut testen!)


[zitat]Original von Uwe
[zitat]Ein Firmware-Bug (?) [/zitat]
Definitiv nein, Martin. Das ist schon immer so - und das wird wohl auch so bleiben. Eben "Timing" der Kommandos ...
[/zitat]
Naja, vielleicht ein Firmware-Bug/Verhalten, das immer schon so war (!) (?)
Ich sehe ja die Reihenfolge der Tastenauswertung C1, C2, C3, C4 ein (auch Primärbelegung vor Schattenbelegung usw.) wenn alle Tasten aktiv (=nicht gesperrt sind) - ABER wenn eine Taste gesperrt ist zu dem Zeitpunkt der Befehlsauswertung, dann "darf" das Modul doch nicht hinter sagen: "Moment, da hat doch gerade jemand die Taste X freigegeben, da muss ich doch gleich noch mal versuchen, ob der letzte Befehl jetzt vielleicht geht?"
Wenn das allgemein gültiges LCN Verhalten ist, sollte es eine "Rote Liste" von Kommandos geben, die nicht atomar ausgeführt werden; also wo ein Teil des Befehls schon mal gemacht wird und irgendwann später mal weitere Teile des Befehles ausgeführt werden.
Das "Sende Taste" gehört dann schon mal auf diese "Rote Liste".

Frage an LinHK ist dann noch, warum die vM Firmware es anders (besser!) macht?
Und braucht LinHK dann eine vM Option damit Befehle "nicht atomar" ausgeführt werden, um kompatibel mit dem Vorbild zu bleiben?

Gruß, Martin - der sich in der virtuellen Realität wohler fühlt

[MartinH]

[zitat]Original von Beleuchtfix
Kann es sein, dass die Tastensperre per Schieberegister durchgereicht wird und zwischendurch nicht perfekt ist? [/zitat]
Florian, ja das Tastensperren baut eine Art Schieberegister auf.
(Leider gibt es in LCN keine direkte Schieberegisterfunktion für Tastensperren, Relais und Lämpchen, sonst gäbe es elegantere Lösungen.)

Ich hatte auch vermutet, dass die Programmierung "zwischendurch nicht perfekt ist" und daher um ein Modul-Protokoll gebeten - aber Heinrich hat anscheinend perfekt gearbeitet und trotzdem das Problem gesehen, was ich mit dem vM nicht sah.

Gruß, Martin - der so nebenbei vMs testet: Danke an Heinrich für die Aufgabenstellung - sonst hätten wir vielleicht jahrelang nicht bemerkt, dass heutige vMs sich anders verhalten.

[Beleuchtfix]

Ich finde die Analyse von Heinrich beeindruckend. Vielleicht sollte man dieses kleine Beispiel inklusiv der Auswertung einmal an die Hotline schicken und um eine Stellungnahme bitten.

Ich denke aber, das man sich dieses Problems in jedem Fall bei älteren Modulen bewusst sein muss, da wird man nichts mehr ändern können.

Heinrich, kannst du jetzt einmal mit Uelis Beispiel das Busprotokoll veröffentlichen, ich finde es interessant zu sehen, wie groß der Zeitunterschied nun ist. Bis jetzt ging es ja um 0,4 Sekunden, während der alles ausgeführt wurde, und so lange ist wohl der erste Befehl noch zwischengespeichert.

Gruß
Florian

[Uwe]

Das ganze ist schon logisch in der Reihenfolge A>B>C>D 1>2>3.. erst primär, dann sekundär usw. (niedere Modulnummern sind da genauso priorisiert).

Das probieren bekomme ich immer wenn ich einen Befehl "zurück" schicke - also von Modul 50 an 5 oder auch schon Tabelle C nach A usw.
Da reagieren die Module schon immer mal etwas "eigenwillig" ...
Auch Ueli hat im obigen Beispiel "Folge"-Tasten verwendet (er weiß schon warum ): "C1 sendet an C5".
Wie eine Tastensperre dann behandelt wird ...

Und immer daran denken: die Module senden maximal 5 Kommandos pro Sekunde (!)
Ggf. muss man hier auch auf andere Module ausweichen ... sonst dauert die Abarbeitung ohnehin länger.

Es ist nicht immer einfach, aber ... es geht :-O
Grüße, Uwe

[Wowbagger]

Naja, wie Uwe schon angemerkt hat hatten wir ähnliche (nicht unbedingt nachvollziehbare) Probleme bei der Belegungssteuerung meines Condominios, die ebenfalls mit Tastensperren arbeitete. Inzwischen ist das umgebaut, das Thema für mich also abgehakt.

Was ich aber tatsächlich gelernt habe: Ich werde mich nie darauf verlassen, dass Befehle in einer bestimmten Reihenfolge abgearbeitet werden, egal was die Manuals schreiben. Solange das Ganze auf einem einzigen Modul stattfindet mag das wohl noch vorhersehbar sein, sobald aber mehrere Module miteinander kommunizieren kann ich mir durchaus Gründe vorstellen, weshalb diese theoretische Reihenfolge nicht eingehalten wird. Ich schliesse mich hier Florians Meinung an, dass man die Befehle mit Zeitverzögerung abfeuern sollte.

Gruss Ueli

[Uwe]

Dann hier auch noch mal den Hinweis, das auch bei der Stromausfallerkennung evtl. ein STV besser bzw. notwendig sein kann.
Ich habe es schon erlebt, dass das Kommando kam bevor das Modul vollständig initialisiert war. STV 3 Sek. reicht da meist schon.

Uwe

[MartinH]

[zitat]Original von Uwe
Das ganze ist schon logisch in der Reihenfolge A>B>C>D 1>2>3.. erst primär, dann sekundär usw. (niedere Modulnummern sind da genauso priorisiert).[/zitat]
Das ist schon ok und auch gut, wenn man sich auf diese Reihenfolge verlassen kann.
(Ist das schon im Wiki? )

Mein einziger Kritikpunkt ist hier - wie oben beschrieben - allein das ein Befehl "nicht atomar" abgearbeitet wird.
Das ist mir neu(!) und ich bin nicht erfreut darüber.

Dass der Trick von Ueli funktioniert, in dem er "Folge-Tasten" (weitere Sende Taste) einfügt, ist auch klar. Das wäre ja sonst noch ein dickerer Hammer wenn "Folge-Tasten" noch vor dem aktuellen Befehlsabschluss ausgeführt werden.

[zitat]sobald aber mehrere Module miteinander kommunizieren kann ich mir durchaus Gründe vorstellen, weshalb diese theoretische Reihenfolge nicht eingehalten wird.[/zitat]
... dem schliesse ich mich auch an !

Gruß, Martin - der noch auf die vM Antwort gespannt ist