Ich wurde hier auf die Möglichkeit aufmerksam, aus den im Betreff genannten Komponenten eine Zentrale aufzubauen.
Die Hardware besteht aus
+ einem Arduino Uno (Klon ich weiß leider nicht genau, was für einer das ist aber exakt so sieht er aus: Werbung: Link), + einem passenden Motor Shield (Deek Robot), + einem 15V 2A Netzteil und + einem USB-Kabel.
Hier erst nochmal die Links zur Software:
Arduino - hier habe ich mir im Bereich Software - Download die Arduino IDE für WinXP und höher geladen. Nicht die App für Win 8.1 oder 10, die ich verwenden könnte (müsste?). Diese Arduino IDE wird nur benötigt, um die Software für die Zentrale (= DCC++) auf den Arduino Uno zu spielen.
DCC++ - Hier gibt es die Software, die die Zentrale zur Zentrale macht. Ich habe sie ohne Probleme (und ohne Anpassungen) auf den Arduino aufgespielt.
JMRI - Das ist die Software, die ich auf meinen Rechner gespielt habe, um die Zentrale zu steuern.
Beim Aufsetzen der Zentrale habe ich mich an diese Anleitung gehalten: Link, also auch am Motor Shield den Pin für Voltage IN (VIN). Zusätzlich habe ich, wie hier empfohlen, die Pins 8 & 9 (Brake disable) getrennt.
So weit, so gut. Mit JMRI DecoderPro kann ich Decoder auslesen (ausgelesene Werte, die ich kenne, werden korrekt angezeigt). Mein Problem ist, dass ich nicht fahren kann. Am Eingang des Motor Shield (da hängt das Netzteil dran) liegen aber knapp 15V DC an. An den Ausgängen des Motor Shields liegen etwa 12V AC an. Trotzdem kann ich keine Lok steuern. Programieren funktioniert teilweise (ich ändere die Adresse und kann dann mit der Multimaus unter der neuen Adresse das Licht schalten aber nicht den Motor in Gang setzen. Im Dialog "Preferences" bei JMRI DEcoderPro steht unter "VErbindungen" folgendes:
+ System manufacturer "DCC++" + System connection "DCC++ Serial Port + Settings: Serial Port "COM3" + Settings Verbindungsvorlauf "D" + Settings Verbindungsname "DCC++"
Die von DCC++ empfohlene Diagnose kann ich nicht durchführen, *glaube ich*! Wenn ich den seriellen Monitor der Arduino IDE anschmeiße (und die Baudrate korrekt auf 115200 einstelle) bekomme ich folgende Meldung:
1
<iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1.+ / Aug 10 2018 11:35:25><NO: SERIAL>
Aber wenn ich dann versuche, bei gebrückten PINs 13 und 3 mit einer <1> oder einer <0> den Motorstrom ein bzw. auszuschalten, dann bekomme ich werder über die LED am Arduino noch über den seriellen Monitor dazu eine Rückmeldung.
Ich hoffe jetzt erstmal, dass mir hier geholfen werden kann, sonst melde ich mich mal bei Trainboard an, wo der Entwickler auch die DCC++ Zentrale vorgestellt hat.
Viele Grüße
Jörg
Mit diesem Beitrag wurden folgende Inhalte verknüpft
ich bin im Moment nicht zu Hause und kann nichts am Arduino probieren. Insgesamt sieht es aber ganz gut aus bei dir.
Daher habe ich mal schnell in das JMRI reingeschaut, hast du die aktuelle Version 4.12 laufen?
Bei mir sieht es in den Einstellungen von DecoderPro so aus: Verbindung: DCC++ DCC++ Serial Port unten müsste dann der passende COM stehen Vorlauf DCCPP Name DCC++
In der Liste von Einstellungen gibt es links noch direkt unter "Verbindung" den Punk "Vorzug". Dort müssen alle Punkte von Internal auf DCC++ gelegt werden, vielleicht löst das dein Problem schon. Bei mir waren die Voreinstellungen dort auch nicht passend und soweit ich mich erinnere konnte ich am Anfang auch nicht fahren.
Ja, ich habe die aktuelle Version 4.12 von JMRI. Auch in den Einstellungen sind die "Verbindung" und die "Vorzüge" so eingestellt, wie du es beschrieben hast.
Ich bin auch recht positiv, denn Lesen funktioniert ja. Und das ist ja auch schonmal was, denn ich kann mir jetzt alle Einstellungen meiner Loks abspeichern. Das war noch nie da!
Interessant finde ich dieses Verhalten: Ich kann über JMRI und die DCC++ die Adresse schreiben. Mit der Multimaus kann ich dann unter der neuen Adresse z.B. das Licht ein- und ausmachen, aber nicht fahren. Ich kann mit der Mulitmaus die Adresse dann auch nicht mehr ändern. Ich muss den Decoder zurücksetzen...
Wäre klasse, wenn du noch eine Idee haben tätest, wenn du wieder zu Hause bist;-)
Ich habe eigentlich nichts geändert, außer dass ich die Decoder jetzt komplett einlese, bevor ich sie programmiere. Und ich habe ein "Hauptgleis" angeschlossen. Läuft. Bisher habe ich einen Zimo MX645, einen Zimo MX621 einen alten Roco OEM 10745, zwei ESU LoPi V4.0 DCC Plux 16, einen Kühn N025 und einen Uhlenbrock 76420 getestet. Alle problemlos gelesen und beschrieben!
sehr gut, dass es jetzt funktioniert. Es geht bei dieser Zentrale nur ein Ausgang zum Programmieren und der andere zum Fahren. Ich habe beide an einen Umschalter mit einem Testgleis angelötet. Dadurch muss ich einmal in DecoderPro zwischen Programmiergleis und Fahrgleis umschalten, sowie am Umschalter den richtigen Ausgang des Motorshields wählen. Ich finde die Lösung auch sehr gut, besonders für verschiedene Decoderhersteller, so kann man sich einfach einen Stand speichern und nach dem Probieren falls nötig zurücksetzen.
ja, ich freue mich auch sehr. Endlich kann ich problemlos und für wirklich günstiges Geld alle Lokdecoder-Einstellungen speichern und auch recht komfortabel programmieren.
Dass du Anlagengleis und Programmiergleis umschaltest, habe ich im anderen Thread gelesen gehabt. Das ist auch eine gute Idee, das werde ich auch machen. Was für einen Umschalter benutzt du? Ich überlege noch, wie ich das ganze jetzt aufsetze, schließlich möchte ich auch meine Meterspur möglichst unkompliziert anschließen können.
Auf alle Fälle haben die "Hersteller" einen riesigen Respekt verdient, das gilt für besonders für JMRI und DCC++. Denn solche Projekte anzugehen und dann auch noch kostenlos zur Verfügung zu stellen, dazu bedarf es schon echten Enthusiasmus'.
in Decoder Pro habe ich schon vor einiger Zeit in Zusammenhang mit dem SPROG mal reingeschaut. Es macht einen ordentlichen Eindruck, auch wenn die Dekoderfefinitionen für die Zimo Dekoder doch der Wirklichkeit hinterherhinken und so für mich nur sehr eingeschränkt nutzbar ist. Der SPROG war mir da noch zu teuer. Für diese Sparversion habe ich mir jetzt mal die Hardware geordert und werde dann auch mal etwas praktisch spielen wollen.
Gibt es denn andere Quellen für die Dekoder-Definitionen? Erfahrungen würden mich da interessieren.
Toll wäre ja, wenn die Decoderdefinitionen Bestandteil der DCC Norm wären und die Hersteller ihre Definitionen zurückmelden. Isses aber wohl nicht. Also scheinen die Decoderdefinitionen genau wie das ganze JMRI-Projekt auf der freiwilligen und unentgeltlichen Mitarbeit von Enthusiasten zu beruhen. Aber das hattest du sicher schon selber rausgefunden.
JMRI verwendet ja einen XML-Ansatz für seine Decoderdefinitionen. Hier kann man sie alle angucken: http://jmri.org/xml/decoders/
Mich würde auch interessieren, ob es für diese Definitionen noch andere Quellen gibt.
ich habe nur mal etwas das Netz abgesucht und bis jetzt nichts außer dort gefunden.
Ich habe den aktuellen produktiven Stand mal installiert und dann in einem Verzeichnis die Entsprechung Deines Links gefunden und einiges angesehen. Da ich am Ende meine Arbeitszeit auch mit soetwas rumplagen musste, habe ich da schon einen Zugang. Nur man kann da schnell was zerschießen. Deshalb muss man wissen, was sich der Author dabei gedacht hat. Da sind noch einige Geheimnisse für mich. Ein großer Schwachpunkt von ZCS ist (neben vielen anderen), dass es immer mit Zeitverzug nur den aktuellen (schon nicht mehr aktuellen) Stand wiederspiegelt. Will man einen paar Jahre alten MX64 programmieren, kommt man da schnell ins Aus, da man was programmiert, was es auf dem Dekoder nicht gibt. In Decoder pro sind Versionen von Dekoder-Beschreibungen möglich, auch für einen Dekoder mit unterschiedlichen Firmware-Ständen. Man muss sich da nun so einklinken, dass ein Update von Decoder Pro nicht alles zerschießt.
Mal sehen, ob ich Lust habe. Der Frust auf ZCS ist jedenfalls groß genug. Nur noch einen Baustelle aufmachen?
Will mir auch nochmals die Entwicklungsversion ansehen.
Ich habe mich vor ein paar Jahren auch mal beruflich mit XML rumgeschlagen. Das heißt, da könnte ich versuchen, mitzudenken. Von dem ganzen DCC-Geschäft habe ich halt herzlich wenig Ahnung. Einen Zeitverzug hätte man doch immer, oder? Es ist ja nicht zu erwarten, dass jemand die Decoderdefinitionen anpasst, sobald z.B. ein neuer Firmwarestand kommt. Oder würdest du das für Decoder, die du verwendest, selbst machen wollen?
Und was kann man sich da zerschießen, was nicht reversibel wäre? XML-Dateien, eine JMRI Installation, einen Decoder?
Respekt, dass du dir die Entwicklerversion ansiehst, ich bin gespannt!
Ich habe heute - damit auch ein paar Bilder kommen, mal ein Rätsel: Was ist das?
Schluss jetzt mit dem Käse, ist doch alles Quark, habe ich mir gedacht und meine Zentrale da mal reingepackt.
Und nachdem ich meinen schönen Schalter verbraten habe, muss ich jetzt doch zwischen Programmiergleis und Hauptgleis umstöpseln.
Aber: Sie tut, die Zentrale. Mal sehen, wie lange das "Gehäuse" hält. Ich dache, es ist mal was anderes. Und kostet nichts.
also mir gefällt das Gehäuse, es geht doch nichts über Transparenz. So kannst du immer alle LEDs auf den Platinen im Auge behalten. Meins ist eine BlackBox.
Das Format der XML-Dateien muss ich mir auch mal genauer ansehen. Mit Hilfe der Decoder Anleitung sollte sie sich auf den neuesten Stand bringen lassen. Das macht aber sicher nur bei Decodern Spaß, die nicht unheimlich viele CVs haben.
auch eine Lösung. Für meinen UNO habe ich gleich so ein Acryl-Rechenzentrum mit bestellt. Da kommt dann das Motor Shield drauf und das sollte erstmal langen.
Z.B. das Schweizer Mapping beim MX633 und MX645 ist noch sehr zurück. Ich verwende da einiges mehr. Das war bis jetzt ein Ausschlusskriterium für Dekoder Pro bei mir. Wenn man es schaffen würde, das für einen Fehlende zu ergänzen, wäre das k.o. Kriterium nicht mehr relevant. Bei mir wären das fürs erste 2 oder 3 Dekoder. Also sehr überschaubar. Wenn man das Anpassen ungeschickt macht, ist die reingesteckte Arbeit bei einem Update futsch. Man wird eh abmischen müssen, aber das soll dann erträglich bleiben.
Eigentlich muss so eine zeitgemäße Software vom Hersteller des Dekoders kommen und mit jedem Firmware-Update angepasst werden. Aber da schläft Zimo friedlich und lässt andere rumwurschteln. Das Entsprechende Programm mit einer grafischen Oberfläche zum Einstellen der Dekoder heißt ZCS. Es wird aber nicht von Zimo erstellt und ist somit oft nicht aktuell. Das Programm ist aber von Anfang an in den Brunnen gefallen. Es hat einige schwere konzeptionelle Fehler und lässt so vieles Sinnvolles nicht zu.
Dekoder sind heute so komplex, dass man eine Reihe von Einstellungen vornehemn muss, um zu sehen, ob es funktioniert. Das muss ich einzeln und im Block zurücknehmen können. Ist so eine Einstellorigie erfolgreich muss ich die auch abspeichern können und zu einem anderen dekoder dazuladen können und auf Knopfdruck in den Dekoder schreiben. Soetwas istheutzutage kein Hexenwerk mehr. Man muss sich nur eine Platte machen und was anbieten. Dann gibt es auch keine Frust bei Leuten, die sich mit dem ganzen zeug nicht auseinander setzen woll, sondern nur einfach spielen.
ZCS kennt keine Dekoder-Beschreibungen und Versionsstände der Dekoder. Das Dekoder Pro ist da eben mit den Dekoder-Beschreibungen fortschrittlicher aufgestellt. Ob anderes, was für mich einfach dazugehört, um zeitgemäß und fortschrittlich zu sein, bei Dekoder Pro dabei ist, habe ich noch nicht ergründet. Wenn der Hersteller was drauf hätte, würde er immer aktuell etwas hier dazu liefern.
Ssssoooo, jetzt hast du mich so weit, ich probiere rum.
Ich wusste ertsmal nichts mit dem Begriff "Schweizer Mapping" anzufangen und dachte mir, was will er denn als DR EpIV Bahner mit dem schweizer Lichtwechsel? Jetzt weiß ich mehr, weil ich bei Zimo eine Info gefunden habe: http://www.zimo.at/web2010/newsitems/SW3...tember_news.htm
Geht das in die richtige Richtung? Falls ja, ich habe bis jetzt zwei ZIMO-Decoder, einen MX645SP22 version 32+ und einen MX621 version 28+ (Bezeichnungen nach DecoderPro). Ich hänge dir die beiden Dateien mal an den Beitrag an, du solltest die Dinger auch ohne Hardware in dein Decoder Pro importieren können. Dann kannst du mal schauen, ich weiß nämlich nicht genau, wo ich da suchen soll. Die Dateien findet man hier (natürlich nicht auf meinem Rechner;-):
Edit: Ahsoja, und dann musst man die Dateien in DecoderPro importieren, in meiner englischen Version unter "File" - "Import Roster Entry".
Und dann - wenn ich dich richtig vertehe - geht es dir drum, möglichst einfach Einstellungen von einer Lok bzw. einem Decoder auf einen anderen zu übertragen? Das probiere ich auch bald mal aus.
Ich hoffe, ich erzähle dir hier nicht allzu viele Sachen, die du eh schon weißt... Falls ja, dann brems mich gern;-)
Viele Grüße
Jörg
Lernkern
hat folgende Dateien an diesen Beitrag angehängt
ja, da hast Du ins Volle getroffen. Heute heißt es ja nicht mehr Schweizer sondern Erweitertes Mapping. ich werde das mal ausprobieren, was Du gefunden und vorgestellt hast. Zum Einen brauche ich die Erweiterung auf 17 Mappinggruppen, aber auch das Negieren der Mastertaste, die Zweitadresszuordnung bei Funktionsdekodern und vorallen das Zuordnen von Dimmwerten.
Bei meinen eigengestrickten Platinen ist ja jede Lampe der Stirnbeleutung einzeln ansteuerbar. Die LEDs werden über Vorwiderstände mit niedrigen Ohms (6,8k) betrieben. Über das Erweiterte Mapping werden sie gedimmt. Bei den in der DDR gebauten Loks hat der rechte Scheinwerfer eine Weitwurflampe, bei den sowjetischen und tschechischen Loks der Obere und kann so aufgeblendet werden. So kann ich im Mapping prüfen, ob das Licht angeschalten ist und der gewünschte Scheinwerfer kann durch Wegfall des Dimmens aufgeblendet werden. Das muss gehen, bevor es für mich interessant wird.
Bei Übertragen von CV - Einstellungen het es um CV Änderungen an bestehenden(!) Decoder-Einstellungen, also nicht das erstbespielen. Ich habe z.B. die Dekoder auf die Loks eingestellt und will jetzt z.B. obiges Lichtspiel hinzufügen. Da sind schon einige CVs zu ändern. Diese Differenz möchte ich also abspeichern können (ist also nur ein teil eines Projekts) und einem anderen Projekt hinzufügen.
Ich habe heute mal was ausprobiert. Und zwar hat es mich interessiert, ob man 1. an einer XML-Datei für eine einzelne Lokomotive im Code Änderungen vornehmen kann, dann 2. die Lok (bzw. natürlich die XML-DAtei) in DecoderPro öffnen und 3. abschließend die Änderung in den Decoder schreiben. Warum? Zwei Gründe:
Erstens könnte man, wenn das geht, einzelne oder mehrere CV Einträge von einer Lok auf eine andere kopieren.
Zweitens könnte man sich einzelne oder mehrere Änderungen jeweils in einer eigenen XML-Datei für eine Lok abspeichern und hätte so die Möglichkeit, Änderungen einzeln oder blockweise zurückzunehmen.
Ich probiere das an einer XML-Datei, denn ich sehe in der Programmoberfläche keine Möglichkeit dazu, kann den Programmcode nicht ändern (was ist Java) und bin daher auf der Suche nach einem Workaround.
Lange Rede, kurze Antwort: Das geht. In jeder XML-Datei für eine Lok (siehe die beiden in einem Beitrag weiter oben angehängten) gibt es am Ende eine Liste mit Einträgen für die einzelne CV, die so aussehen:
1
<CVvalue name="1" value="43" />
Das ist jetzt hier die DCC Adresse. Um sie zu ändern, reicht es, hier einen anderen Wert einzutragen, die Lok auf Programmiergleis zu stellen und dann im Programmierfenster auf "Write all sheets" zu klicken.
Hallo Järg, klar geht das :-) Ich habe das mit dem SPROG schon gemacht um Daten von einer Ae 6/6 auf die andere Ae 6/6 zu kopieren. Ausserdem habe ich für mich mal dokumentiert, wie das so mit DCC++ so geht. Ich bin aber noch nicht fertig. https://www.thobaben.ch/moba/?p=4470 Vielleicht ist ja auch was für Euch dabei.
Freut mich ja, dass das Gehäuse gefällt, die liegen hier zigweise im Küchenschrank. Wir, etwas wegwerfen? Nenenene. Falls einer ein Gehäuse braucht, ich hätte billig welche abzugeben . Ich überlege noch, wie ich es schwerer mache, denn so ist es etwas kippelig. Steine..?.
Ich war mir auch sehr sicher, dass es geht. Aber glauben heißt nicht wissen, also habe ich's ausprobiert.
Deine Doku ist gut, vielen Dank für den Link. Da hast du ja sehr detailliert und mit Screenshots geschrieben, wie man die Zentrale aufsetzt . Da bin ich gespannt, was noch kommt, wobei ich jetzt mit Loconet nicht sooo viel anfangen kann. Aber das kann ja noch werden. Ach, und genannt hast du mich auch, danke .
Hallo Jörg Klar habe ich Quellen genannt - Ehre, wem Ehre gebührt... Es kommt sicher noch was. Bin ja noch nicht fertig. Ich werde den Setup zu JMRI und auch zu Rocrail beschreiben. Und schauen, ob ich damit das Loconet zum fliegen bringe. Wozu? Erklär ich dann auch.
mein Rechenzentrum mit Aufsatz ist im Schweinsgalopp aus fernen Landen eingetroffen. Nun will ich es erstmal in Betrieb nehmen.
Dank Eurer Anleitungen wird dies sicher gelingen.
An Loconet wäre ich auch intereessiert. Und dann möchte ich noch Jörgs Ideen ausprobieren. Die Idee ist sicher brauchbar. Nur wenn es einzelne Bits in Bytes betrifft, die im Bestand unterschiedlich gesetzt sind für die Loks, dürfte Nacharbeit notwendig sein.
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Digitaltechnik
»
JMRI mit DCC++: Mein Einstieg in die digitale Steuerung?
12.08.2018 04:15 (zuletzt bearbeitet: 06.02.2022 21:50)
Thema drucken
Antworten
218_469_5.xml
) und bin daher auf der Suche nach einem Workaround.
. 
. Da bin ich gespannt, was noch kommt, wobei ich jetzt mit Loconet nicht sooo viel anfangen kann. Aber das kann ja noch werden. Ach, und genannt hast du mich auch, danke 
.
