In Bearbeitung — Michael 2022/04/25
Ausgangsbasis für die folgende Anwendung war eine fixe Idee:
Dort existiert ein Gleisanschluss, der zeitweise zum Programmieren der Lokomotiven genutzt wird, aber zu 99% dem Spielbetrieb dient. Um das zu realisieren, muss dieser Gleisanschluss zweipolig getrennt werden und ganz wichtig: Nach erfolgreicher Programmierung muss er wieder an die Anlage gekoppelt werden. Um diesen letzten Schritt nicht zu vergessen, sollte in unmittelbarer Nähe ein nicht zu übersehendes Warnsignal blinken.
Warum also nicht einfach die RGB-LEDs eines in der Nähe stehenden Gebäudes nutzen und z. B. die Neonröhren einer Werkhalle rot blinken lassen?
Die Herausforderung:
Zur Generierung des Flackerns einer Neonröhre braucht man jedoch einen Speicher, in dem abgelegt wird, wie viele Zündversuche schon gemacht wurden und ob die Lampe endlich richtig gezündet hat. Diese Daten werden im roten Kanal der LED abgelegt, um Speicher im Arduino zu sparen. Bei jedem Zündversuch wird die rote LED um ein kleines bisschen heller. Das sieht dann so aus als wäre es die Glimmlampe des Starters. Zur Erkennung, ob die Lampe gerade hell ist, weil ein Zündversuch stattfindet, leuchtet sie nicht mit der vollen Helligkeit, sondern ein kleines bisschen weniger. In diesem „Weniger“ werden wieder die Zündversuche gespeichert. So spart die Programmierung ein zusätzliches Byte. Das ist wichtig, weil der Arduino nur 2000 davon hat und bereits knapp 800 für die LEDs benötigt werden.
Dieser Sparfimmel führt aber zu einem ungewollten Effekt. Die House Funktion (hier mit Neonröhren) prüft die Helligkeit der roten LED, sobald das Licht angeschaltet werden soll. Wenn die LED durch das Blinken bereits leuchtet, dann kommt das Programm durcheinander. Um das zu verhindern, nutzt man als Warnsignal einfach den Fotoblitz. Da dieser nur einen sehr kurzen Impuls sendet, kommt die House-Funktion beim Wiedereinschalten nicht mehr durcheinander. Man kann somit die RGB-LEDs eines Gehäuses sowohl als belebtes Haus, als auch als Warnleuchte in den Farben Rot (C1), Grün (C2), Blau (C3), Gelb (C12), Cyan (C23) und Weiß (C_All) nutzen.
Insgesamt stünden also sechs unterschiedliche Farben für sechs unterschiedliche Warnsignale zur Verfügung. Im Falle des unten gezeigten Programmiergleises sind das:
Um das Ganze per DCC zu steuern, werden im Programmgenerator als erstes die DCC-Adressen mit den Schalternamen verknüpft. Im Beispiel ist das Adresse #1 für die Aktivierung des normalen Lichts („Licht_Main“). Die Adressen #11 bis #14 werden zum Umschalten der oben genannten Relais und gleichzeitig zum Aktivieren des Fotoblitzes genutzt. Ihnen werden die Namen „Licht_Z21“, „Licht_ESU“, „Licht_Zimo“ und „Licht_Res“ zugeordnet.
Als nächstes benötigt man eine Logische Verknüpfung,
Die letzte logische Verknüpfung muss nicht berücksichtigen, dass auch versehentlich drei Programmer aktiviert sein können. Selbst wenn alle vier Programmer über die Adressen 11-14 aktiviert werden, ist eine der Bedingungen für „Licht_OutR“ wahr.
Die gezeigte Relaisschaltung schleift das DCC-Signal der Zentrale durch alle inaktiven Relais durch. Das hat einen entscheidenden Vorteil gegenüber einer aufeinander folgenden Schaltung: Es muss für jedes Programmiergerät nur das jeweils zugehörige Relais geschaltet werden und nicht alle davor liegenden zusätzlich. Werden versehentlich zwei Relais aktiviert, wird nur das am ersten Relais angeschlossene Programmiergerät durchgereicht, weil die Kette zu den folgenden Relais unterbrochen ist.
Schließt man hingegen das DCC-Signal der Zentrale am ersten Relais an die geschalteten Ausgänge und die Programmiergeräte ebenfalls an die geschalteten Ausgänge ihrer zugeordneten Relais, müssen bspw. für das Programmiergerät an Relais 3 die ersten drei Relais aktiviert werden.