Alternative Ansteuerung für KS-Signal ("led_signal_007") ?
Verfasst: So 8. Mär 2015, 00:41
Hallo in die Runde,
eine kurze Vorstellung: Ich habe mich wegen der u.g. Frage neu hier angemeldet, bin im FREMO aktiv und habe diverse LED-Decoder schon erfolgreich in Wattenscheider-Signalschächten untergebracht, weil sie dort so wunderbar hineinpassen.
Umprogrammiert habe ich die Decoder-PICs noch nie, aber ich kenne jemanden, der damit Erfahrung hat und mir helfen würde. Zunächst möchte ich hier aber klären, ob es für mein aktuelles Problem hier überhaupt Chancen zu einer erfolgreichen Umprogrammierung gäbe.
Mein Problem konkret:
Eine Reihe Ks-Signale möchte ich (vorbildwidrig) mit einem DrS2-Stelltisch von Erbert in der Loconet-Version ansteuern. Über diesen Tisch will ich hier nicht allzu viele Worte verlieren, sondern nur die für mein Problem entscheidenden Faktoren aufzählen:
- Die Ansteuerungssoftware ist relativ starr, d.h. ich kann sie in ihrer Logik nicht beeinflussen.
- Einem Hauptsignal wird eine Magnetartikeladresse zugeordnet, wobei dann rot automatisch "Halt" und grün automatisch "Fahrt" ist.
- Einem Ersatzsignal wird eine andere Adresse zugeordnet, wobei dann "rot" automatisch "Ersatzsignal aus" und "grün" automatisch "Ersatzsignal ein" ist.
- Einem Rangiersignal wird eine andere Adresse zugeordnet, wobei dann "rot" automatisch "Rangiersignal aus" und "grün" automatisch "Rangiersignal ein" ist.
- Der Haltfall der drei Begriffe (Haupt-, Ersatz-, Rangiersignal) wird mit derselben Tastenkombination ("Haltgruppentaste") erzeugt, wobei das System leider nicht alle drei Adressen auf "rot" setzt, sondern nur jene, die vorher auf "grün" standen.
Hier zeigt sich bereits der Widerspruch zur Software des LED-Decoders. Dieser kennt in der Variante "led_signal_007" nur einen zentralen Haltbefehl, beispielsweise "Adr. 1 rot". Einen separaten Befehl "Ersatzsignal aus" oder "Rangiersignal aus" gibt es nicht, hier müsste derselbe Befehl "1 rot" erfolgen - tut es der Erbert-Logik zufolge aber nicht.
Grundsätzlich finde ich die Funktionsweise des LED-Decoders toll, denn gerade bei Ks-Mehrabschnittssignalen macht sie einem das Leben extrem einfach. Eine modulare Ansteuerung jedes einzelnen Signallämpchens mit einer eigenen Digitaladresse, wie sie Erbert offenbar unterstellt, fände ich um ein Vielfaches komplexer. Der Ansatz "1 Adressbefehl = 1 kompletter Signalbegriff" soll bei mir also bestehen bleiben.
ABER: Gäbe es eine durch Umprogrammierung einfach zu erstellende Lösung, um dem zentralen Haltbegriff "Hp0" (standardmäßig ADR 1) mehrere Magnetartikeladressen zuzuordnen, also z.B. 1 rot, 2 rot und 3 rot?
Dann hätte ich voraussichtlich mein Problem gelöst: Egal ob die Erbert-Logik sagt "Hauptsignal Halt", "Rangiersignal aus" oder "Ersatzsignal aus", der LED-Decoder würde immer dasselbe tun und nur noch die rote Lampe leuchten lassen, was in allen drei Fällen korrekt wäre. Die restlichen Funktionen des LED-Decoders würde ich so belassen und könnte sie weiterhin in ihrer vollen Bequemlichkeit nutzen.
Also, würde ich diese Änderung durch PIC-Programmierung umsetzen können?
Vielen Dank für jegliche Antworten und Lösungsvorschläge!
... fragt der auf diesem Feld noch unerfahrene
Christoph
eine kurze Vorstellung: Ich habe mich wegen der u.g. Frage neu hier angemeldet, bin im FREMO aktiv und habe diverse LED-Decoder schon erfolgreich in Wattenscheider-Signalschächten untergebracht, weil sie dort so wunderbar hineinpassen.
Umprogrammiert habe ich die Decoder-PICs noch nie, aber ich kenne jemanden, der damit Erfahrung hat und mir helfen würde. Zunächst möchte ich hier aber klären, ob es für mein aktuelles Problem hier überhaupt Chancen zu einer erfolgreichen Umprogrammierung gäbe.
Mein Problem konkret:
Eine Reihe Ks-Signale möchte ich (vorbildwidrig) mit einem DrS2-Stelltisch von Erbert in der Loconet-Version ansteuern. Über diesen Tisch will ich hier nicht allzu viele Worte verlieren, sondern nur die für mein Problem entscheidenden Faktoren aufzählen:
- Die Ansteuerungssoftware ist relativ starr, d.h. ich kann sie in ihrer Logik nicht beeinflussen.
- Einem Hauptsignal wird eine Magnetartikeladresse zugeordnet, wobei dann rot automatisch "Halt" und grün automatisch "Fahrt" ist.
- Einem Ersatzsignal wird eine andere Adresse zugeordnet, wobei dann "rot" automatisch "Ersatzsignal aus" und "grün" automatisch "Ersatzsignal ein" ist.
- Einem Rangiersignal wird eine andere Adresse zugeordnet, wobei dann "rot" automatisch "Rangiersignal aus" und "grün" automatisch "Rangiersignal ein" ist.
- Der Haltfall der drei Begriffe (Haupt-, Ersatz-, Rangiersignal) wird mit derselben Tastenkombination ("Haltgruppentaste") erzeugt, wobei das System leider nicht alle drei Adressen auf "rot" setzt, sondern nur jene, die vorher auf "grün" standen.
Hier zeigt sich bereits der Widerspruch zur Software des LED-Decoders. Dieser kennt in der Variante "led_signal_007" nur einen zentralen Haltbefehl, beispielsweise "Adr. 1 rot". Einen separaten Befehl "Ersatzsignal aus" oder "Rangiersignal aus" gibt es nicht, hier müsste derselbe Befehl "1 rot" erfolgen - tut es der Erbert-Logik zufolge aber nicht.
Grundsätzlich finde ich die Funktionsweise des LED-Decoders toll, denn gerade bei Ks-Mehrabschnittssignalen macht sie einem das Leben extrem einfach. Eine modulare Ansteuerung jedes einzelnen Signallämpchens mit einer eigenen Digitaladresse, wie sie Erbert offenbar unterstellt, fände ich um ein Vielfaches komplexer. Der Ansatz "1 Adressbefehl = 1 kompletter Signalbegriff" soll bei mir also bestehen bleiben.
ABER: Gäbe es eine durch Umprogrammierung einfach zu erstellende Lösung, um dem zentralen Haltbegriff "Hp0" (standardmäßig ADR 1) mehrere Magnetartikeladressen zuzuordnen, also z.B. 1 rot, 2 rot und 3 rot?
Dann hätte ich voraussichtlich mein Problem gelöst: Egal ob die Erbert-Logik sagt "Hauptsignal Halt", "Rangiersignal aus" oder "Ersatzsignal aus", der LED-Decoder würde immer dasselbe tun und nur noch die rote Lampe leuchten lassen, was in allen drei Fällen korrekt wäre. Die restlichen Funktionen des LED-Decoders würde ich so belassen und könnte sie weiterhin in ihrer vollen Bequemlichkeit nutzen.
Also, würde ich diese Änderung durch PIC-Programmierung umsetzen können?
Vielen Dank für jegliche Antworten und Lösungsvorschläge!
... fragt der auf diesem Feld noch unerfahrene
Christoph