H/V-Asig: Animationsergebnis von Zufällen abhängig
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
H/V-Asig: Animationsergebnis von Zufällen abhängig
In Buke wurde folgende Situation beobachtet, bei der das Signalbild nicht dem Soll entsprach:
Gewollt und in der Animation hinterlegt war eigentlich, dass das linke Licht des Ausfahrsignals leuchtet. Mindestens einmal pro Simulationslauf erhält man auch ein korrektes Signalbild mit linkem roten Licht. Aber bei Folgeversuchen dann nicht mehr.
Die Animationsdefinitionen im Signalschirm sehen so aus:
Wenn man einen Ersatzsignalbegriff zieht, passiert folgendes: Die Animation "Hp 0" schaltet ein, und die Animation "Hp 00" schaltet aus. Dieser Vorgang passiert zeitgleich. Wenn man sich die Animationsdefinitionen anschaut, sieht man wo das Problem liegt: Beide Animationen wirken auf die Ani-Nr. 1 (das ist die linke Rotlampe), und zwar gegensätzlich: Die eine Animation fährt die Helligkeit der Rotlampe runter, während die andere sie gleichzeitig hochfährt. Das Ergebnis, was man dabei am Ende bekommt, ist offenbar von subtilen Timing-Zufällen abhängig. Nachdem beide Animationen durchgelaufen sind, ist die Rotlampe mal an und mal aus.
Was man auch sieht: Beim Signalbild Hp0/Sh1 liegt der Fall eigentlich genauso. Auch dort laufen die Animationen "Hp 00 aus" und "Hp 0 / Sh 1 ein" bei der linken Rotlampe gegeneinander. Es ist uns zwar noch nicht gelungen, auch im Fall des Hp0/Sh1 die linke Rotlampe zum Erlöschen zu bringen, aber ich halte es durchaus für möglich, dass uns dieses Animations-Timing-Problem beim flächendeckenden Ausrollen von Rangieren in Zusi 3 auf die Füße fallen könnte.
Um einen Komplettumbau aller H/V-Ausfahrsignale zu vermeiden, ist vielleicht eine programmseitige Lösung denkbar: Wenn der Simulator feststellt, dass gerade eine einschaltende und eine ausschaltende Animation gegeneinander laufen, sollte er die ausschaltende Animation der betroffenen Signallampe abbrechen, damit die einschaltende Animation den Wettlauf auf jeden Fall gewinnt. Ich denke da in Richtung einer Zählvariablen, die von einschaltenden Signalanimationen beim Start gesetzt wird und am Ziel wieder runtergezählt wird. Ausschaltende Animationen der selben Signallampe prüfen diesen Wert und brechen sich ab, wenn sie diesen Wert detektieren.
Gewollt und in der Animation hinterlegt war eigentlich, dass das linke Licht des Ausfahrsignals leuchtet. Mindestens einmal pro Simulationslauf erhält man auch ein korrektes Signalbild mit linkem roten Licht. Aber bei Folgeversuchen dann nicht mehr.
Die Animationsdefinitionen im Signalschirm sehen so aus:
Wenn man einen Ersatzsignalbegriff zieht, passiert folgendes: Die Animation "Hp 0" schaltet ein, und die Animation "Hp 00" schaltet aus. Dieser Vorgang passiert zeitgleich. Wenn man sich die Animationsdefinitionen anschaut, sieht man wo das Problem liegt: Beide Animationen wirken auf die Ani-Nr. 1 (das ist die linke Rotlampe), und zwar gegensätzlich: Die eine Animation fährt die Helligkeit der Rotlampe runter, während die andere sie gleichzeitig hochfährt. Das Ergebnis, was man dabei am Ende bekommt, ist offenbar von subtilen Timing-Zufällen abhängig. Nachdem beide Animationen durchgelaufen sind, ist die Rotlampe mal an und mal aus.
Was man auch sieht: Beim Signalbild Hp0/Sh1 liegt der Fall eigentlich genauso. Auch dort laufen die Animationen "Hp 00 aus" und "Hp 0 / Sh 1 ein" bei der linken Rotlampe gegeneinander. Es ist uns zwar noch nicht gelungen, auch im Fall des Hp0/Sh1 die linke Rotlampe zum Erlöschen zu bringen, aber ich halte es durchaus für möglich, dass uns dieses Animations-Timing-Problem beim flächendeckenden Ausrollen von Rangieren in Zusi 3 auf die Füße fallen könnte.
Um einen Komplettumbau aller H/V-Ausfahrsignale zu vermeiden, ist vielleicht eine programmseitige Lösung denkbar: Wenn der Simulator feststellt, dass gerade eine einschaltende und eine ausschaltende Animation gegeneinander laufen, sollte er die ausschaltende Animation der betroffenen Signallampe abbrechen, damit die einschaltende Animation den Wettlauf auf jeden Fall gewinnt. Ich denke da in Richtung einer Zählvariablen, die von einschaltenden Signalanimationen beim Start gesetzt wird und am Ziel wieder runtergezählt wird. Ausschaltende Animationen der selben Signallampe prüfen diesen Wert und brechen sich ab, wenn sie diesen Wert detektieren.
Zuletzt geändert von Alwin Meschede am 14.02.2018 21:03:01, insgesamt 2-mal geändert.
Mein Youtube-Kanal: youtube.com/echoray1
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Spontan würde ich sagen, dass das nicht so einfach geht.
Läßt sich das nicht irgendwie über die Konfiguration der Animationen lösen?
Carsten
Läßt sich das nicht irgendwie über die Konfiguration der Animationen lösen?
Carsten
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Wir testen derzeit einen Satz Signalschirme, wo die Animationen anders organisiert sind.Carsten Hölscher hat geschrieben:Läßt sich das nicht irgendwie über die Konfiguration der Animationen lösen?
Mein Youtube-Kanal: youtube.com/echoray1
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Stand der Dinge: Von Jörg wurden Signalschirme gebastelt, die das Problem umgehen. Man kämpft nicht mehr gegen das Ausschalten der Rotlampe an, sondern blendet an der selben Koordinate eine zweite Rotlampe ein. Das Ergebnis ist optisch leider nicht so richtig zufriedenstellend. Während die Animationen laufen, sind deutliche Helligkeitsschwankungen zu sehen.
Das Grundproblem ist übrigens noch viel weiter verbreitet als wir ursprünglich dachten: Es gab in den letzten Jahren immer mal wieder Fälle, wo H/V-Vorsignale plötzlich zweifelhafte Signalbilder anzeigten. Reproduzierbar war das nie. Mit dem Wissen von heute liegt es aber nahe, dass hier jeweils ein ungünstiger Timing-Zufall zwischen den Animationen für Vr 0 und Vr 2 zustande kam.
Das Grundproblem ist übrigens noch viel weiter verbreitet als wir ursprünglich dachten: Es gab in den letzten Jahren immer mal wieder Fälle, wo H/V-Vorsignale plötzlich zweifelhafte Signalbilder anzeigten. Reproduzierbar war das nie. Mit dem Wissen von heute liegt es aber nahe, dass hier jeweils ein ungünstiger Timing-Zufall zwischen den Animationen für Vr 0 und Vr 2 zustande kam.
Mein Youtube-Kanal: youtube.com/echoray1
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Wobei mir von allen prof. Sims nicht eine eiznige Meldung zu dem Thema bekannt ist - und die werden ja intensiv genutzt.
Carsten
Carsten
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Kannst du dir das betroffene Signal Buke N3 mal anschauen? Es wäre natürlich das beste, wenn Zusi das ohne zutun selbst hinbekommen würde.
Neuer Fahrplan mit Neuenheerse und Buke, Fahrzeug am einzigen Aufgleispunkt der Strecke (vor N3) aufgleisen und über Fehlersuche die Hilfsfahrstraße zum Lsf von Neuenheerse einstellen. Bei mir hat es gleich beim ersten mal nicht das gemacht, was es sollte. Bei Alwin hat es offenbar ab- und zu geklaptt, ggf. mehrfach verwenden.
Neuer Fahrplan mit Neuenheerse und Buke, Fahrzeug am einzigen Aufgleispunkt der Strecke (vor N3) aufgleisen und über Fehlersuche die Hilfsfahrstraße zum Lsf von Neuenheerse einstellen. Bei mir hat es gleich beim ersten mal nicht das gemacht, was es sollte. Bei Alwin hat es offenbar ab- und zu geklaptt, ggf. mehrfach verwenden.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Die Frage ist, bezeichnen wird das jetzt als Bug oder als Feature? So ein Hv-Signal macht ja auch in echt zwischen zwei Signalstellungen die dollsten Dinger.Alwin Meschede hat geschrieben:Das Ergebnis ist optisch leider nicht so richtig zufriedenstellend. Während die Animationen laufen, sind deutliche Helligkeitsschwankungen zu sehen.
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Hm.
Beobachtung: Wenn ich in Willebadessen mich vor P1 stelle und P2->Sbk 10 (Hp2, eingestellt) auflöse und ohne das Fenster zu schließen P2->Sbk 110 (Hp1) einstelle erlischt P2, sobald ich das Fenster schließe. Wenn ich umgekehrt P2->Sbk 110 auflöse und P2->Sbk 10 einstelle erscheint Hp2 korrekt. Der Fahrstraßenwechsel auf P3 funktioniert korrekt...
Edit: Mit sämmtlichen anderen Signalen ebenso beobachtbar: Der Wechsel von Hp1 auf Hp2 und von Hp2 auf Hp2 klappt, der Wechsel von Hp2 auf Hp1 aber nicht.
Beobachtung: Wenn ich in Willebadessen mich vor P1 stelle und P2->Sbk 10 (Hp2, eingestellt) auflöse und ohne das Fenster zu schließen P2->Sbk 110 (Hp1) einstelle erlischt P2, sobald ich das Fenster schließe. Wenn ich umgekehrt P2->Sbk 110 auflöse und P2->Sbk 10 einstelle erscheint Hp2 korrekt. Der Fahrstraßenwechsel auf P3 funktioniert korrekt...
Edit: Mit sämmtlichen anderen Signalen ebenso beobachtbar: Der Wechsel von Hp1 auf Hp2 und von Hp2 auf Hp2 klappt, der Wechsel von Hp2 auf Hp1 aber nicht.
Zuletzt geändert von F. Schn. am 02.03.2018 19:27:48, insgesamt 1-mal geändert.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Wie ist zu dem Thema der aktuelle Stand? Hab das noch auf der "todo-Liste".
Carsten
Carsten
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Das Thema hat sich wie so üblich in die Modulthemen gezogen: https://forum.zusi.de/viewtopic.php?p=283074#p283074" target="_blank
Wir haben folgende Lösung vorgeschlagen:
Letzt Aussage von dir dürfte das hier sein:
Wir haben folgende Lösung vorgeschlagen:
Alwin Meschede hat geschrieben:Wir haben bereits fertige Bausätze in der Hinterhand, die das Problem nicht mehr haben, weil sie einzeln gesteuerte Lampen verwenden. Es ist technisch überhaupt kein Problem, das gesamte Zusi-Netz automatisiert auf diese Signalschirme umzubauen und alle Signalmatrizen passend umzustellen. Nur: Es muss Rückendeckung für so eine Aktion geben.
Du hattest grundsätzlich erst mal ein OK gegeben:F. Schn. hat geschrieben:Einzeln angesteuerte Lampen. Also nicht wie bisher mehrere Lampen nach Signalbegriff gruppiert sondern eben einzeln.
Carsten Hölscher hat geschrieben:Komplett einzeln angesteuerte Lampen sind erstmal ein guter Ansatz.
Wir sollten unsere Profistrecken dann am besten auch umstellen. Dafür wäre eine kleine Doku sinnvoll, welche Änderungen das im Detail standardmäßig erfordert.
Carsten
Letzt Aussage von dir dürfte das hier sein:
Die Frage ist nach wie vor, ob wenn man die Lampen nicht mehr nach Signalbegriffen gruppiert, das möglicherweise negative Auwirkungen auf die Profi-Version hat. Möglicherweise ist dann im Trainer-Arbeitsplatz die Beschriftung schlechter. Da habe ich bislang nur eine allgemeine Aussage bekommen, dass das schon in Ordnung seien müsste.Carsten Hölscher hat geschrieben:Ich hab das Thema Stw-Schnittstelle jetzt wieder auf dem Tisch liegen für die nächsten Tage. Evtl. ergeben sich da auch noch Anforderungen/Wünsche. Also vielleicht lassen wir das Thema ein paar Tage ruhen.
Carsten
Zuletzt geändert von F. Schn. am 02.06.2018 13:00:54, insgesamt 2-mal geändert.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
OK, danke. Das Problem mit der Profiversion besteht schon. Am besten wäre die Lösung, dass man Einzellampenanimationen und als eine Art Zwischenebene Signalbegriffe im Klartext einführt, die dann zu definierende Animationen auslösen. Es dürfte aber sehr undankbar sein, den Bestand dann umzurüsten, außer das ließe sich automatisieren.
Carsten
Carsten
-
- Beiträge: 9005
- Registriert: 04.11.2001 19:57:46
- Aktuelle Projekte: Zusi3 Objektbau
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Lässt sich denn auf diesem Weg zuverlässig vermeiden, dass dann von der Zwischenebene aus zwei Animationen der selben Einzellampe angestoßen werden, die in entgegengesetzter Richtung wirken? Nur indem man eine Zwischenebene einführt, ist man da doch noch nicht am Ziel?Carsten Hölscher hat geschrieben:Am besten wäre die Lösung, dass man Einzellampenanimationen und als eine Art Zwischenebene Signalbegriffe im Klartext einführt, die dann zu definierende Animationen auslösen.
Mein Youtube-Kanal: youtube.com/echoray1
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Damit ließe sich erstmal eine Einzellampenansteuerung umsetzen, ohne dass die Profiversion unübersichtlich wird. Auch für diverse Schnittstellenfragen ist eine saubere Klartextdarstellung der Signalbegriffe hilfreich. Zusi würde diese Zwischenebene nicht unmittelbar nutzen sondern wie bisher direkt mit den "ausgewählten Häkchen" arbeiten. Die Zwischenebene dient nur der Übersetzung.
Carsten
Carsten
- Johannes
- Beiträge: 3216
- Registriert: 14.03.2009 22:36:06
- Aktuelle Projekte: Zusitools (http://git.io/zusitools)
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Es sollte auch noch eine Loesung fuer das Problem her, dass die Einzellampen ja nicht alle auf einmal angeschaltet werden, sondern mit vorbildgerechter Verzoegerung. So eine Zwischenebene sollte andere Animationen also auch zeitgesteuert an- und ausschalten koennen.
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Stimmt, das muss ja auch noch beachtet werden.
Carsten
Carsten
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Was ist dort das Problem? Für's erste würde sich dort IMHO anbieten, die Vorlaufzeit in die Lampenanimation zu stecken (was uns zwar als Stellwerkssimulation in die Quere kommen würde aber sei's drum). Langfristig würde sich vielleicht auch der Baukasten anbieten, der für das Schrankenschließen-Problem kommen wird.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Carsten, darf ich noch mal nerven: Wie ist jetzt die Planung? Planst du eine Programmerweiterung und hast es bis dahin zurückgestellt, oder...?
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Evtl. weiß ich nächste Woche was.
Carsten
Carsten
- Konstantin E.
- Beiträge: 1157
- Registriert: 25.02.2003 17:16:59
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Das kann ich so nicht bestätigen. Die Reihenfolge von Anzug und Abfall der Relais ist immer die gleiche.TeeEssHah hat geschrieben:So ein Hv-Signal macht ja auch in echt zwischen zwei Signalstellungen die dollsten Dinger.
@Carsten: Wenn du Hilfe dazu brauchst, kannst du dich gerne melden. In meinen Unterlagen habe ich die Schaltungen (zumindest für SpDrS60 und DrS2) aufgezeichnet. Ich müsste mich nur noch mal etwas reinfuchsen.
Zu dem Thema wollte ich dich beim nächsten Treffen sowieso noch mal ansprechen.
- Carsten Hölscher
- Administrator
- Beiträge: 33496
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: H/V-Asig: Animationsergebnis von Zufällen abhängig
Das steckt bei Zusi ja in den Signalen. Also die Signalbastler wären die Richtigen.
Carsten
Carsten