bereits vor einiger Zeit bin ich auf das mrrwa-Projekt (http://mrrwa.org/) gestoßen. Dis Projekt beschäftigt sich mit dem Auswerten der DCC-Signale mit dem Arduino.
Der Gedanke, einen vollkommen frei Programmierbaren und genau meinen Wünschen anpassbaren Decoder für unter 5 Euro zu erhalten reizte mich, daher habe ich das ganze nun in Angriff genommen.
Zu Beginn habe ich mir ein Entwicklerboard gebaut, das mit 8 LEDs und einem Servoanschluß auskommt. (Keine Schönheit, aber funktional ;))
Nun mußte die Library installiert und verstanden werden. Das gestaltete sich anfangs schwieriger als erwartet, da es praktisch keine Dokumentation gibt, abgesehen von ein paar Kommentaren im Quelltext. Zudem bin ich noch über ein paar Fehler in den Beispielen und Eigenarten des DCC Protokolls gestolpert.
Nachdem ich alle Klippen umschifft hatte, war es soweit, ich konnte mir die ersten Tastendrücke anzeigen lassen.
Nun kann der eigentliche Teil beginnen. Mein erstes Ziel ist ein möglichst flexibel einsetzbarer Lichtdecoder. Der erste Schritt ist erledigt, nun könne mehrere Lampen über einen Funktionstaste eingeschaltet werden. Dabei gibt es eine (optionale) Zeitverzögerung.
Nun sollen die LEDs natürlich noch dimmbar sein. Da nicht jeder Ausgang PWM-Fähig ist, muß dies Softwaremäßig gelöst werden. Der erste Versuch ist leider fehlgeschlagen. Hier werde ich mir noch eine filigranere Variante suchen müssen. Normal sollten die LEDs mit 100%, 50% und 10% leuchten.
besten Dank, genau sowas möchte ich in nächster Zeit auch umsetzen. Ich werde mir dein Thema mal bei Gelegenheit genauer anschauen und auch Erfahrungen sammeln.
ich bin auf deine Ergebnisse gespannt, und freue mich auf einen regen Erfahrunsgaustausch.
Da ich für ein anderen Projekt (meinen geplanten Loklift) einen Schrittmotor ansteuern muß, habe ich gestern mal versucht, siesen in meinen Decoder zu interieren. Ich hatte etwas Sorge, dass es mit dem Timing Probleme gibt, hat aber problemlog geklappt.
Der Motor muß jedoch in Einzelschritten angesteuert werden, sonst "blockiert" er den übrigen Programmablauf.
schön, dass Du dich auch auf der Arduino-Spielwiese tummeln willst.
Wie Du vielleicht entdeckt hast, bin ich dabei einen Susi-Modul zu bauen, da das Angebot doch recht bescheiden und von der Funktion nicht mehr zeitgemäß ist. Bei Suchen nach Informationen bin ich auch auf diese von dir genannte Seite und auch auf diese hier gestoßen. Testweise habe ich mal die Hardware mit den einfachen Optokoppler der 2. Seite aufgebaut und habe den Monitor übernommen und etwas ausgebaut. Er protokolliert die DCC Befehle auf dem seriellen Monitor der Arduino IDE. Die Bibliotheken des DCC-Projekts habe ich mir auch installiert und ich habe mir einige Anregungen für das Programmieren geholt. Da es aber offenbar keine Doku gibt, habe ich da erstmal noch nicht weitergemacht. Zum Umsetzen meiner Ideen bräuchte ich aber Railcom oder ich baue gleich einen LocoNet-Modul. Aber das kommt später, wenn der Bedarf wirklich da ist.
Mich würde aber interessieren, was diese Bibliothek unterstützt? Ich nehme an das Auswerten der Befehle. Wie kann man dann die Verarbeitung durch eigene Komponenten anbinden? Welche CVs kann man verwenden und kann man diese auch programmieren, auch die eigenen CVs? Werden diese CVs gespeichert, damit sie nach dem Einschalten des Dekoders wieder zur verfügung stehen? Was hast Du eigentlich vor? Soll es eine Lichtsteuerung für die Anlage werden? Denn in eine H0-Lok bekommst Du das dann ja nicht.
Mich würde Deine Lösung für das Dimmen interessieren, da ich gerade das Dimmen in den Susi-Modul einbaue. Da habe ich bis jetzt aber nur vor, die Ausgänge zu berücksichtigen, die es hardwaremäßig unterstützen.
die genannte Seite kenne ich, auf dem Schaltplan basiert mein Testboard. Mit der Funktionalität als Lokdecoder habe ich mich nicht weiter auseinander gesetzt, lediglich Testweise die Fahrstufe angezeigt. Interessant könnte das werden, um z.B. einen Servo „Stufenlos“ über die Farhstufe zu steuern, allerdings ist das momentan nur eine Idee, eine praktische Anwendung fehlt mir da.
Ich habe mich daher mit den Funktionen für einen Funktionsdecoder beschäftigt. Da scheint es auch verschiedene zu geben, wo da die Unterschiede genau liegen, kann ich noch nicht sagen.
Ich habe mir da lediglich eine vorgenommen: „extern void notifyDccAccState( uint16_t Addr, uint16_t BoardAddr, uint8_t OutputAddr, uint8_t State) „
Die habe ich so modifizier und vom Ballast befreit, dass die mir eine eigene Funktion aufruft, und dieser die Funktionsmummer und des Status (true / false bzw. rot / grün) übergibt. Die Funktionsnummer errechnet sich aus der aufgerufenen Adresse im Bezug zur Basisadresse des Decoders. Ist die Basisadresse 100, und wird die Funktion mit der Adresse 104 aufgerufen, ist die Funktionsnummer 4. Diese 4er Blöcke scheinen ja zumindest bei Weichen und Signaldecodern üblich zu sein (keine Ahnung, ob es dazu einer Norm gibt oder sich da nur eingebürgert hat), können aber vollkommen frei gewählt werden. Theoretisch kann ich den Decoder nur ein eine Adresse reagieren lassen, oder jeden Port mit einer eignen Adresse ansteuern lassen. Die CV Programmierung scheint recht umfangreich zu sein. Für mich ist sie momentan noch uninteressant, da ich die Decoder ohnehin am PC Programmiere. Normal kann man Variablen ja im EPRom speichern. Ob das automatisch durch die Library passiert, oder man den teil selber programmieren muß, entzieht sich meiner Kenntnis.
Mir geht es für mich in erster Linie um Lichtsteuerung. Ein – und Ausschalten von Laternen / Lampen / neonröhren, „belebtes Haus / Büro / Werkstatt“, eben alles was mit einer LED versehen werden kann.
Fürs Dimmen habe ich auf eine externe Library (SoftPWM) zurückgegriffen. Meine Klassen geben lediglich die Intensität (0 .. 255) zurück. Das ist zwar nicht die eleganteste Lösung, funktioniert aber halbwegs. Das Dimmen über eine Softwarelösung ist allerdings mit Kompromissen verbunden. Die Hardware-PWM-Ausgänge sind da auf jeden falls die besser Wahl.
Im Anhang mal meine Basis-Script auf dem ich meine aktuelle Entwicklung aufbaue. Keine Gewähr, dass dieser immer und überall fehlerfrei funktioniert. Ich kann nur mit meiner Ecos testen.
Gruß Denis
Denis
hat folgende Dateien an diesen Beitrag angehängt
Funktionsdekoder sind eigentlich Lokdekoder ohne Motorunterstützung. Sie verarbeiten das Protokoll wie ein Lokdekoder. Du hast einen Schaltdecoder (Lenz) oder Zubehördekoder (Zimo) implementiert. Sie haben ein eigenes Protokoll, worauf sie reagieren. Es ist in der Norm RCN-213 DCC-Protokoll Betriebsbefehle für Zubehördecoder beschrieben. Da findest Du dann auch Deine Fragen zur Adresssierung beantwortet. Zubehördekoder waren recht dumm und konnten nur an/aus für eine Adressse. Da kann ein Lokddekoder doch einiges mehr.
Ich habe mir das Beispiel mal angeschaut. Ich muss mich mal mit den externen Methoden beschäftigen. Was man damit erreichen kann. Es scheint noch eine andere Heransgehensweise zu sein, wie man geboten Funktionalität in eigne Projekte einbinden kann.
Ja es ist die Frage, wie das Dimmen mit Software implementiert ist. Im Susi-Projekt verwenden ist den Interrupt des Ports 2. Zum Quitieren des Lesen und Schreibens der CVs wollte ich zur Zeitsteuerung den TimeOne verwenden. Jedoch hatte der Interrupt damit ein Problem und das Erkennen der Befehle verschlechterte sich erheblich. Irgendwie suche ich noch eine Möglichkeit, wie man die Interrups selektiv aus/einschalten kann. Ich vermute, dass es daran liegt.
Wenn DU hier Programmteile einbinden willst, kasst Du das Programm direkt in der IDE abgreifen und hier über "Inhalte Integrieren code /code" einbinden.
ZitatZubehördekoder waren recht dumm und konnten nur an/aus für eine Adressse.
Wie "intelligent“ ein Decoder ist, hängt ja davon ab, was ich dort programmiere. Ich muß wissen welche Adresse angesprochen wurde, und ob es sich um einen ein- oder ausschaltenden Impuls handelt. Beide Informationen bekomme ich von der Library. Alle weiteren Funktionalitäten sind keine Sache des Protokolls mehr.
Hallo Uli, Danke für den Link. Den Thread kenne ich allerdings schon.
In den letzten Tagen habe ich wieder Programmiert. Zur Zeit arbeite ich an Lichtfunktionen, mit der in gewissen Rahmen auch Relais oder Optokoppler angesteuert werden können, im externe Geräte schalten zu können. Das ganze ist Objektorientiert programmiert so dass ich flexibel die einzelnen Ausgängen ansprechen kann. Da gibt es zum einen die Grundeinstellungen wie Ein- Ausschaltverzögerung, Automatisches abschalten und die Helligkeit, und dann Effekte wie Blinken, Flackern, Flimmern und noch ein paar geplante Effekte wie das aufblenden von Natriumdampflampen. Später wird es noch möglich sein, komplette Lichtprogramme mit festgelegten und zufälligen Abläufen zu schreiben. So beschränkt man sich nicht auf das ein- und Ausschalten der Lampen, sondern kann diese sozusagen im Automatikbetrieb betrieben um z.B. ein belebtes Haus / Büro etc.) zu simulieren.
Zum Abschluss noch ein paar Effekte. Noch im Standalone Betrieb, die Einbindung in meine Licht-Library ist jetzt nur noch eine Kleinigkeit.
Mein erster Funktionsdecoder ist fertig gestellt. Er soll zur Steuerung des Bahnhofes (Licht, Kelle heben und Wasserkran) dienen. Dazu ist er mit diversen Anschlüssen für LEDs (Vorwiderstand bereits auf dem Board) einem Servoanschluß, Relais (für den FDL -> Magnetartikel) sowie einem Optokoppler als potentialfreien Kontakt für ein Soundmodul (Abfahrspfiff) ausgestattet. Nun geht es an den Einbau und die Programmierung der Ausgänge.
eine Bitte hätte ich: Könntest du vielleicht von einem Projekt den Code posten, so dass man Material zum Einarbeiten und Nachvollziehen hat? also z.B. über Weichenadresse 1 eine LED einschalten und wieder ausschalten. Danke dir.
schau mal in den Beitrag Nr. 5, da habe ich mein Basisscript angehängt.
Interessant sind zum einen folgende Zeilen:
1
#define This_Decoder_Address 120
Hier wird die Basissddresse des Decoders eingestellt, in diesem Fall 120.
1
#define This_Decoder_Function_Num 4
Die Anzahl der weiteren Adressen auf die der Decoder reagiert, in diesem Fall 120, 121, 122 und 124, so wie die meisten Weichendecoder. Theoretisch kann man hier auch mehr oder weniger Funktionen eintragen, also den Decoder nur auf eine oder 100 Adressen reagieren lassen.
Deinen Coder, also den zum LED ein- und Ausschalten mußt du in folgende Funktion schreiben:
1
void myFunction(bool state, int functionNo){
Dieser Funktion werden zwei Parameter übergeben. Zum einen der Status (state) diese ist true oder false, und gibt an, ob die Funktion ein oder ausgeschaltet wird. (oder anders: Weiche rechts / links.) Die Funktionsnummer (functionNo) gibt an, welche Funktion (bezogen auf die Basisadresse) aufgerufen worden ist. Bei Adresse 120 ist diese Variable 0, bei 121 ist sie 1 usw.
pinX muß natürlich deinem Ausgang am Arduino entsprechen.
PS.: Das ganze konnte ich bisher nur mit meiner Zentrale (Esu ecos) testen. ob sich das Script bzw. die Library bei anderen zentralen anders verhält kann ich nicht beurteilen.
Hallo Denis, ein interessantes Projekt stellst Du hier vor. Ich habe mich schon vor längerer Zeit auch intensiv mit der mrrwa/dcc-Library beschäftigt. Sie ist sehr leistungsfähig, aber das größte Problem ist in der Tat die doch sehr rudimentäre Dokumentation. Vielleicht kann ich auch ein paar Fragen beantworten, denn ich glaube sie inzwischen recht gut zu kennen.
Manfred hatte ja auch schon ein paar Fragen gestellt ( vielleicht sind sie aber inzwischen geklärt oder irrelevant? ):
Zitat von dr iv im Beitrag #4Mich würde aber interessieren, was diese Bibliothek unterstützt? Ich nehme an das Auswerten der Befehle. Wie kann man dann die Verarbeitung durch eigene Komponenten anbinden?
Die Lib arbeitet fast ausschließlich über Callback-Funktionen. Die Namen dieser Funktionen beginnen alle mit 'notify...' und sind in der NmraDcc.h deklariert. Sie sind aber kein Bestandteil der Lib, sondern müssen vom Anwender im Sketch implementiert werden. Die Lib erkennt automatisch, dass eine solche Funktion existiert, und ruft sie dann entsprechend der empfangenen DCC-Pakete auf. Dies geschieht in dcc.process(), der Funktion die im loop aufgerufen werden muss. Letztendlich sind alle 'notify...' Funktionen im Sketch Unterprogramme von dcc.process().
Zitat von dr iv im Beitrag #4Welche CVs kann man verwenden und kann man diese auch programmieren, auch die eigenen CVs? Werden diese CVs gespeichert, damit sie nach dem Einschalten des Dekoders wieder zur verfügung stehen?
Alle CV's werden im EEProm gespeichert. Dabei entspricht die CV-Nummer einfach der EEProm-Adresse. Es existieren Aufrufe zum Schreiben und lesen der CV's. Man kann sich über eine 'notify...' Funktion auch informieren lassen, wenn die Lib eine CV verändert, z.B. als Reaktion auf einen Programmierbefehl der Zentrale. Dabei beherrscht die Lib auch PoM (muss aber beim Initiieren freigeschaltet werden).
Ob die Lib als Zubehör- oder als Funktionsdecoder arbeitet wird bei der Initiierung festgelegt. Beides parallel geht nicht. Dass Denis seine Anwendung als Funktionsdecoder bezeichnet ist da etwas verwirrend, da seine Anwendung im Sinne der Lib ein Zubehör (Accessory-) Decoder ist. Wie Manfred schon erwähnt hat, reagiert ein Funktionsdecoder auf Lok-Befehle. Ein Zubehördecoder ist im Grunde ein dedizierter Weichendecoder. Die entsprechenden DCC-Befehle sind stark auf die Weichen mit Doppelspulenantrieben ausgelegt. Aber natürlich kann man sie auch für andere Anwendungen nutzen.
Alle Zentralen senden die entsprechenden Pakete übrigends mehrfach um sicherzustellen, dass auch bei Übertragungsfehlern der Befehl ausgeführt wird. Die Lib filtert das nicht - deshalb kommen die Befehle mehrfach an. Das muss in der Anwendung berücksichtigt werden.
ich möchte jetzt nicht direkt auf Deinen Beitrag antworten, sonder nur einige Aspekte betrachten und Überlegungen loswerden.
Ich hatte mich vor einiger Zeit mit dieser Bibliothek (Lib) beschäftigt und sie mangels Doku und mangels momentanen Erfordernis wieder beiseite gelegt. Deshalb interessierte mich der Beitrag von Denis. Doch die Art, wie er es für sich implementieren will, fand nicht mein Interesse. Was ich nicht als Wertung verstanden haben möchte.
Ich habe mir dann nochmals die Lib vorgenommen und habe mir die Callback-Technik angesehen und bin dann erstmal zu der Erkenntnis gekommen, dass die wohl nur für statische Klassen funktioniert.
Mittlerweile habe ich es aber auch für Objektinstanzen mittels Vererbung im Griff.
Im Susi Projekt habe ich eine Klasse für dimmbare Ports. Für jedes Port wird dabei einen Instanz angelegt. Die Methoden werden nun wiederrum von Mehoden der Instanzen fürs Mapping, die einseitige Lichtunterdrückung oder das Dimmen aufgerufen. Das hat nun alles noch nichts mit einem Susi-Modul zu tun. Dadrüber liegt nun wieder die CV-Verwaltung, die Susi-Modul Befehlererkennung und deren Befehlsbearbeitung. Erst die machen dann den Susimodul aus. Für jeden Aufgabenkomplex gibt es eine Lib. Mittlerweile sind es 14 Libs. Vieles ist objektorientiert programmiert. Die Befehlabarbeitung aber dann doch eher prozedural in c++, da ich der kleinen Kiste nicht so recht zutraue, dass sie dabei nicht in die Knie geht. Auch könnte der Speicher dann bald zu klein sein. Obwohl der Compiler mir sagt, dass 376 Bytes belegt wären sind es dann bei der Ausführungs schon eher 1,3 kBytes, weil die dynamischen Objekte auch noch Speicher belegen. Es war auch eine interessante Erfahrung, das Verahlten der Kiste bei vollem Speicher zu studieren. Alles wird unkalkulierbar. Man sieht nichts und muss eine Idee haben. Bis jetzt habe ich nicht in Erfahrung bringen können, ob das Ding einen Carbage collector besitzt.
Wenn man jetzt diese Libs für einen Funktionsdekoder und z.B. Deine Servosteuerung hernimmt, könnte man, wenn es zusammenpasst, relativ einfach einen eigenen Funktionsdekoder mit Ports und Servoausgängen bauen. Bei den Lichteffekten könnte man sich dann auch noch austoben. Da habe ich bis jetzt nichts gemacht.
Zu dem ganzen Thema hatte ich die Frage nach der CV-Verwaltung und den verfügbaren CVs gestellt. In der Beziehung ist ja ein Susi-Modul sehr eigenwillig designt. Das könnte man sich ja u.u. sparen, wie Zu sagt, da es ja bereits existiert. Da es aber Funktionsdekoder mit derartigen Eigenschaften gibt, sehe ich z.Z. kein Erfordernis.
Bei Zubehördekodern sehe ich meinen Bedarf eher bei LocoNet- und nicht bei DCC-Modulen. Kann mir jemand sagen, ob sich zwei LocoNet-Module ohne Zentrale unterhalten und Informationen austauschen können? Oder anders, wer regelt den Verkehr?
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Digitaltechnik
»
Arduino DCC - Der flexible Decoder
21.10.2016 15:26 (zuletzt bearbeitet: 21.10.2016 15:30)
Thema drucken
Antworten
Funktionsdecoder.rar
