1zu160 - Forum



Anzeige:
Harburger Lokschuppen

THEMA: Wer hat Erfahrungen mit ESU "Grade Crossing"?

THEMA: Wer hat Erfahrungen mit ESU "Grade Crossing"?
Startbeitrag
Torsten Lang - 05.05.11 20:45
Hallo zusammen,
ESU hat in seinen LokPilot Decodern an sich ein nettes Feature namens "Grade Crossing". Ich bin nach Dokumentation vorgegangen, um das Feature zu nutzen, nur funktionieren tut es nicht!

Wie ich die Anleitung verstehe, ist "Grade Crossing" eine logische Funktion, die man wie Rangiergang, Verzögerungsabschaltung o. ä. aktivieren kann. Weiterhin läßt sich diese Funktion wiederum als Effekt einem Ausgang zuordnen.

Lt. Anleitung sollte ein Ausgang, dem der Effekt zugewiesen wurde, nur dann aktiv werden können, wenn die logische aktiv ist, d. h. der Effekt bewirkt eine UND-Verknüpfung.

Ich habe das bei dem brandneuen LoPi Micro V4 ausprobiert - funktionieren tut's leider IN KEINER WEISE. Der Effekt wird einfach ignoriert, d. h. der Ausgang verhält sich so, als sei "Grade Crossing" dauerhaft aktiv bzw. nicht konfiguriert.

Da der ESU Support meine Anfrage bisher nicht beantwortet hat, wüßte ich gerne mal, ob einer von Euch diese Funktion schon mal erfolgreich konfiguriert hat...

Viele Grüße,
Torsten

Hallo Torsten,

betreiben wir mal ein wenig ESUterik.

Folgendes Beispiel funktioniert:

Aux1: Blinklicht, GradeXing konfiguriert.
F7  : GradeXing aktiviert.
F8  : Aux1 aktiviert.

F8 on  -> Aux1==ON
F7 on  -> Aux1 blinkt
F8 off -> Aux1==OFF

ciao
U
Moin U,
das klingt in der Tat eher nach Voodoo - mit der Anleitung deckt sich das von Dir geschilderte Verhalten ja in keinem Fall. Was Du beschreibst heißt ja letztlich, daß die Konfiguration des Effekts Grade Xing für den Ausgang dazu führt, daß ohne logische Funktion Grade Xing der Mode Select Wert ignoriert (bei muß er wohl 12 sein) und fest der Wert 1 angenommen wird, erst wenn Grade Xing aktiviert wird, wird der Mode Select Wert beachtet.

Damit wär's für meine Zwecke natürlich unbrauchbar...

P. S. Eine Antwort von ESU habe ich nach wie vor nicht!

P. P. S. In einer englischsprachigen Anleitung zu einem Sounddecoder habe ich den Hinweis gefunden, daß Grade Xing nur mit Blink-Effekten ab Mode Nr. 3 (Single Strobe) aufwärts funktioniert. Ob der Modus bei Grade Xing aus dann Ausgang an oder aus ist, hängt vom Lichteffekt ab. Damit ist die aktuelle Anleitung gnadenlos falsch (dort ist Grade Xing für alle Effekt-Modi erlaubt) und unvollständig.

Gruß,
Torsten

Hallo Torsten

um hinter den ESUterischen Voodoo Zaubern zukommen, spiel doch mal mit dem
Lokprogrammer v4.1.4 herum.

Das Programm hat die Möglichkeit CV's zu exportieren; wenn Du dann zwei solcher Listen
vergleichts, siehst Du welche Möglichkeiten in dem LokPilot stecken.

Es existieren massenhaft CV's die ESU derzeit nicht dokumentiert hat(kann man so auch irgenwo in den Tiefen des ESU Forums nachlesen).

ciao
U

Hallo Ullrich,
ich denke, ich habe mittlerweile alles Wichtige beisammen. Bei den meisten Decodern gibt es eine bestenfalls zweistufige Verarbeitung, die Zurdnung von Funktionen und Richtungsbit ist fest verdrahtet (z. B. NMRA CV33 == "F0" & "vorwärts"), man kann also nur die Ausgänge zuordnen (ODER-Term) und den Ausgängen noch Effekte zuordnen. Bei Zimo (und Lenz bzgl. F1) sind die fest verdrahteten Funktionen noch richtungsbhängig.

ESU hat eine vierstufige Verarbeitung, wobei man, wenn man schon mal GALs programmiert hat, die ersten Stufen gleich wiedererkennt, es ist also nichts irgendwie Neues oder revolutionäres.

Jeder Term besteht aus 12 CVs, startend ab CV257 in Page 4098.

Stufe 1:
Je 8 CVs werden verwendet, um einen UND-Term zu formulieren. Jedes Eingangssignal liegt dort in nicht inverser und inverser Form vor, also Vortwärts, /Vorwärts, Fahrt, /Fahrt, F0, /F0, ... F28, /F28. Baut man einen entsprechend breiten Betriebsdatenvektor auf, dann läßt sich der Wahrheitswert eines solchen Terms sehr effizient berechnen. Ganz witzig: Ohne zu wissen, daß es ESU schon so macht, hatte ich auch Herrn Holub von Zimo genau dieses Verfahren vorgeschlagen, um ein wirklich flexibles Funktion-Mapping zu realisieren. Hier läßt sich z. B. eine Zwangsabschaltung ganz einfach bewerkstelligen, indem z. B. die Default-Konfiguration des sechsten Terms "F0 rückwärts" für das rote Licht so geändert wird, daß gilt "/vorwärts & F0 & /F3", d. h. der Rangiergang würde verhindern, daß das rote Licht angeht.

Sufe 2:
Ist der Term wahr, dann bestimmen vier weitere CVs, auf welche Ausgänge und logischen Funktionen der Term wirkt (leider dokumentiert die Anleitung die jeweils zweite CV für die Ausgänge nicht, da finden sich nämlich die sekundären Ausgänge - s. Stufe 3). Nur diese CVs sind in der Anleitung dokumentiert und gelten in der beschriebenen Form nur dann, wenn die UND-Terme nicht geändert wurden. In dieser zweiten Zuordnung stecken implizit die ODER-Terme.

Sufe 3:
Jeder Ausgang ist logisch zweimal vorhanden. Ab CV355 in Page 4096 liegen Licht vorne [2], Licht hinten [2], AUX1 [2] etc. Der Sinn des Ganzen (leider auch in keiner Weise dokumentiert): Hier kann ein Ausgang mit verschiedenen Effekten (Lichteffekte, Dimmung, Spezialfunktionen) konfiguriert werden. Die primäre Konfiguration hat Priorität. Ein konkretes Beispiel wäre dann z. B. wieder unser rotes Licht bzw. dessen Zwangsabschaltung, man könnte AUX1 [1] mit Dimmung 0 (Licht aus) belegen und AUX1 [2] mit Dimmung 31. Der Rangiergang würde dann auf AUX1 [1] wirken, das normale Licht F0 rückwärts auf AUX1 [2].

Stufe 4:
Hier kommen dann noch die Lichteffekte am Ausgang ins Spiel. Leider ist die Doku hier gründlich falsch, das Grade Xing wirkt nur bei allem, was blinkt, und dient primär dazu, bei Annäherung an Bahnübergänge Blinksignale an der Lok einzuschalten.

Ich denke, ich werde werde das nochmal ausführlicher zusammenstellen, die (aus der Anleitung ersichtliche) etwas unsystematische CV-Wüste bekommt so nämlich einen sehr systematischen und logischen Charakter.

Viele Grüße,
Torsten

Hallo Torsten,

Danke für die Infos - puuh, da hat ESU ein ganz schönes "Monster" (im positiven Sinn) gebaut.
Der gravierente Nachteil dieser CV-Wüste ist allerdings, dass der Prozessor langsam "bootet" weil er nach jedem Spannungsverlust den ganzen CV-Haufen aus dem EEPROM (oder steht das im Flash?) lesen und in sein internes Speicherformat umrechnen muss. Ob das sinnvoll ist?

Grüße, Peter W.
Hallo Peter,
der Witz an diesem Format ist ja gerade, daß, wenn man die Software nicht völlig dämlich implementiert, eben keine Formatkonvertierungen braucht, sondern in einem Durchlauf durch die gesamte "CV-Wüste" durchrechnen kann. Deshalb bin ich ja bei eigenen Überlegungen zu einem sehr ähnlichen Programmiermodell gekommen.

Und daß diese "CV-Wüste" dann in einem NoInit-RAM-Bereich liegt und per Prüfsumme gesichert ist, damit man sie bei kurzen Spannungseinbrüchen eben nicht neu laden muß, sollte bei vernünftiger Programmierung auch klar sein.

Wo der ESU soviel Zeit beim Booten vertrödelt, kann ich natürlich auch nicht sagen, ich hab' die Software ja nicht gemacht...

Viele Grüße,
Torsten
Zitat

Wo der ESU soviel Zeit beim Booten vertrödelt


Hast Du schon versucht alle nicht benötigten Digitalformate (MM, SX) und auch die ESU-typische automatische Erkennung von 14 vs. 28 Fahrstufen abzuschalten?

Grüße, Peter W.
Hallo Peter,
das sollte hier keine große Rolle spielen: Es ist die "DCC only" Version, und die Festlegung des Fahrstufenschemas sollte auch keine Rolle spielen: Solange die Daten im NoInit-RAM erhalten sind können sie verwendet werden. Und auf das Booten kann und darf diese Automatik ohnehin rein logisch betrachtet keinen Einfluß haben, die greift ja erst, wenn der Decoder bereits gebootet hat und die Applikation läuft und muß m. E. die Erkennung "im Vorbeigehen", nämlich einfach so, beim Empfang entsprechender DCC-Pakete, erledigen.

Ullrich meinte (wenn ich ihn da richtig zitiere), daß der Powerpack das Problem löst/entschärft. Nur leider ist der in den allermeisten Spur N Modellen nicht nutzbar (ich hatte zum Test mal einen übriggebliebenen Lenz Power-Pack angeschlossen, um zu sehen, wie viel da überhaupt gepuffert wird).

Viele Grüße,
Torsten
Hallo zusammen,
noch ein kleiner Nachtrag: gestern habe ich an einem Trix Dampfer mit Glockenanker (BR 018 aus dem Rheingold-Set) mal die Decoder durchgetauscht, um einen meiner wertvollen MX620 zurückzugewinnen.

Der LoPi Micro V4 schlägt sich hier meines Erachtens genauso gut wie der MX620. Die Stromabnahmebasis ist bei dieser Lok breit genug, daß es keine Probleme mit Mikrounterbrechungen gibt.

Eine Sache für die Know-How-Ecke: Zimo orientiert sich bei der Beschleunigungs-/Verzögerungskennlinie nicht an der Geschwindigkeitskennlinie (via Basis-CVs Vmid/Vmax) oder Geschwindigkeitstabelle, diese Werte bestimmen ledigkich die Soll-Endgeschwindigkeit, bei ESU scheint das anders zu sein. Hier hat eine stark gekrümmte Geschwindigkeitstabelle (exponentieller Anstieg) auch den Effekt, daß die Lok beim Anfahren langsamer beschleunigt. D. h. ESU scheint bei der Beschleunigung/Verzögerung anders als Zimo die Geschwindigkeitsstufen VOR der Tabelle zu durchlaufen.

Um es zu verdeutlichen: Wenn ich bei beiden Decodern eine exponentielle Kennlinie in die Tabelle programmiere, dann wird der Zimo trotzdem ohne weitere Maßnahmen linear beschleunigen, der ESU aber exponentiell. So zumindest meine Beobachtung.

Viele Grüße,
Torsten
Hallo,

dazu gibt es ja bei Zimo extra CVs um die Beschleunigungs- und Bremskurven zu beeinflusssen.

Grüße, Peter W.


Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->

Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account





Zum Seitenanfang

© by 1zu160.net;