THEMA: Kennt Ihr schon DCC++? (3)

Hi Tom,

sollte auf WDP laufen.

Geht aber aktuell nur mit der alten BaseStation

Die läuft wieder.  Mein Fehler.

Danke

Peter

Warum willst du eine MAC anpassen? machst du doch auch mt keinem anderen Gerät, oder?

Bei Ethernet gilt (also via Kabel, nicht Wifi):
1. Die MAC Adresse wird automatisch unik aus der Arduino board-ID generiert
2. IP entweder via DHCP (default) oder per im config.h
angegebener IP_ADDRESS.

Achja, man kann in der Version noch Ethernet/Kabel und Wifi gleichzeitig, das Resultat kann aber etwas undefiniert sein. Wird in Zukunft nicht mehr unterstützt.

Grüße,
Harald.

Hallo,

hat irgendjemand hier DCC-EX mit JMRI via LAN am laufen? Da gibt es ja nicht viel einzustellen, entsprechend sollten die möglichen Fehlerquellen überschaubar sein - und trotzdem spricht mein JMRI nicht mit DCC-EX, nur über USB geht es. Irgendwann kommt vielleicht doch noch der Punkt an dem ich die LAN-Verbindung nutzen möchte - hat da jemand einen Plan?


LG - Tom

Weil die vorgegebene Mac Adresse (BaseStation) von meiner Fritzbox nicht angenommen wurde.
Nach der Änderung läuft es Einwanfrei.

DCC++EX läuft leider (noch) nicht auf WinDigipet.

Grüße

Peter

Es gibt solche Anwender im Discordchat. Selber hab ich kein LAN-Shield.



Eigentlich sollten als MAC welche 6 Bytes auch immer gehen, nur solten sie halt einmalig im LAN sein.

EDIT: NEE, die zwei erstgesendeten Bits sollten 0 und 1 sein. Patch kommt....

EDIT2: Patch auf github. https://github.com/DCC-EX/CommandStation-EX/co...28c9ddd74b0721033085

Welche 6 Bytes hat denn unser Code aus deinem Arduino ausgelesen? (steht im Debug über USB)

EDIT2: War das erste Byte ungerade?

Grüße,
Harald.

Hallo Harald und Peter,

wir haben das jetzt in WDP eingebunden. Mit Version 3.0 getestet per USB, LAN und WIFI. Es wird sicher in dem nächsten Update Veröffentlicht. Zeitpunkt kann ich aber nicht sagen. Das steht nicht in meiner Macht. Ich lese hier aber im Hintergrund mit. Sollten sich noch Einstellungen ändern, dann werden wir das vor dem Update noch einarbeiten und die Version anpassen. Wobei die 3.0 sicher stehen bleiben wird, als funktionierende Version.

Ich werde an meinen DCC++EX jetzt erst einmal ein Display ausprobieren.

Die Homepage zu DCC++EX ist übrigens sehr gut und übersichtlich.

VG Sven

Also wr arbeiten konstant die Bugs raus, bitte testet gegen den git _Master_. WIr versuchen wirklich da nix Mieses zu pushen, Entwicklung läuft auf Branches, keine Angst. Bald wird der 3.0.X zum 3.1.0. Man kann sich auf Discord als  Tester melden. Tests sind noch in Entwicklung aber wir nehmen gern auch  automatisierte Tests entgegen

Ich rate von WiFi bei der Automatiksteuerung ab. Auch kommen ungepollte Zustandsänderungen der Sensoren bis jetzt nur über USB. WiFI ist ein feines Gimmick aber für den Automatikbetrieb z.Z. am besten USB.

Grüße,
Harald.

Hallo Harald,



Da bin ich ganz auf Deiner Seite. USB ist bei mir auch die Nummer 1 bei Computersteuerung. Aber wir müssen ja auch alles erst einmal durchtesten, wenn wir es anbieten.

VG Sven

Hallo Harald,

ich habe jetzt mal die v3.0.6 etwas angetestet. Netzwerktechnisch ist alles beim alten, ich kann die CommandStation anpingen, sonst geht nichts. Was mich aber wirklich stört ist der Umstand, dass ich mit der v3.0.6 nicht programmieren kann!

Ich habe mir den Master letzten Samstag runter geladen und gestern Abend nochmal, da sind zwar Änderungen dabei aber mit beiden Versionen ist das Programmiergleis beim Start an und lässt sich in JMRI nicht ausschalten. Das Hauptgleis ist default aus, kann dann manuell eingeschaltet werden - dann kann ich auch fahren wie gewünscht.

Zum direkten Vergleich habe ich nochmal die v3.0.0 drauf geladen, da ist das Programmiergleis default aus und funktioniert auch wie es soll. In der v3.0.3 die mir der automatische Installer mal gegeben hatte hatte ich das selbe Problem.

Mein Motor Shield ist ein DIY More, das ja identisch zum Deek-Robot sein sollte und zu den empfohlenen Boards gezählt wird; in der v3.0.0 läuft es als Standard Board problemlos, daher würde ich das mal als mögliche Ursache ausschließen.

Bin ich der einzige der dieses Problem hat oder traut sich nur sonst niemand das zuzugeben?


LG - Tom

Tante Edit hat noch mal die letzte Versionsnummer korrigiert...

Hallo,

gerade die aktuelle v3.0.8 ausprobiert - die Probleme bleiben: Keine Netzwerkverbindung möglich, Programmiergleis ist immer an und damit nicht nutzbar. Obwohl das was da raus kommt sogar ungefähr nach DCC aussieht, aber nur mit 7V - und eben nicht schaltbar.

Schade eigentlich, aber irgendwas hat nach der v3.0.0 das Programmiergleis zerschossen...

Laut der config.example.h sollte jetzt auch ein OLED mit SSH1106 gehen - das funktioniert auch, mit einem kleinen Fehler: Die Anzeige ist etwas nach links versetzt und die abgeschnittenen Spalten finden sich am rechten Rand wieder.


LG - Tom

PS: Gibt es sowas wie hier irgendwo direkt für DCC++? Ein direkter Draht würde vielleicht manches vereinfachen.

Und Tante Edit hat noch das Display erwähnt.

Direkten Support gibts auf Discord (chat) https://discord.gg/PuPnNMp8Qf Aber nach deiner Fehlerbeschreibung mit 7V denk ich du hast einen Hardwarefehler, ich würde raten nur 1/2 H-Brücke aktiv oder so. Ich würde erstmal die Ausänge vom Arduino durchmessen. Die Nummern stehen ja im Motordrivers.h

Erste Zeile is Main, zweite Zeile is Prog.
Erste Pinnummer ist an/aus (also z.B. 11 für Prog) Da sollten 0V sein bei aus und 5V bei an.
Zweite Pinnummer (12 bzw 13) ist das DCC-Signal. Das ist ja eine Rechteckspannung, die sollte immer an sein und da sie 50% an ist misst man da normal 2,5V.
Normal sind die Signale von Main und Prog natürlich unterschiedlich. Nach Kommando <1 JOIN>  allerdings haben beide das Main Signal.

Und nee, dein Problem hab ich bis jetzt noch nicht gehört. Wenn du übrigends deine HW testen willst kannst du die Werte in den beiden Zeilen vertauschen,
dann wird Prog zu Main und umgekehrt. Auch A0 mit A1 vertauschen nicht vergessen. Wenn man sich vorsichtig fühlt kann man die 2000 (mA) auch noch etwas runterschrauben.

Für Fehlersuche am LAN empfehle ich den Discord weil ich hab keine LAN-Karte, nur WiFi Erfahrung.

Grüße,
Harald.

PS: Wenn man einen \ haben will muss man 3 (!) schreiben.

Hallo Harald,

den Hatdwarefehler würde ich mal ausschließen: Wenn ich wieder auf die v3.0.0 zurück gehe funktioniert es ja. Dann sind beide Gleisausgänge beim Start inaktiv, ich kann sie aber dann nach Bedarf ein- und auch wieder ausschalten und programmieren!

Das sieht mir eher so aus als ob nach der 3.0.0 irgendwo mal die Pins anders definiert worden wären. Danach habe ich noch nicht geschaut.

Auf den Discord hatte ich vorher mal drauf geschaut - wirkt auf den ersten Blick etwas unübersichtlich, da muss ich mal in Ruhe lesen.


LG - Tom

So, es geht weiter: Da das Motor Shield in beiden Versionen (3.0.0 als bekannt funktionierend und die aktuelle 3.0.8 zum Vergleich) identisch definiert wird - das wäre ja auch zu einfach gewesen - wollte ich eigentlich mal rumprobieren, ob ich das Ding zum Laufen bringe wenn ich einzelne Unterprogramme der 3.0.8 durch die alte Version ersetze.

Da ich gerade kein Netzwerkkabel holen wollte und der Start mit aktiviertem Netzwerk, aber ohne Kabel recht lange dauert (muss ja immer erst auf DHCP warten, bis er aufgibt), habe ich vorab in der config.h mit
#define ENABLE_ETHERNET false
das Netzwerk einfach deaktiviert. Und jetzt darfst du raten was passiert: Das Programmiergleis geht! es ist beim Start aus und kann nach Belieben geschaltet werden. Da scheint also irgendwie das Netzwerk Shield mit ins Motor Shield rein zu spucken.

Naja, solange ich die Command Station nicht über Netzwerk ansteuern kann habe ich kein Problem mit dieser Lösung. Und was das Netzwerk angeht muss ich mich dann mal mit dem Discord befassen.


LG - Tom

Also ich hab die Änderungen in der Ethernetecke zwischen 3.0.0 und 3.0.8 nicht verfolgt. Aber scheinbar liegt da ein Hund begraben und den wollen wir _vor_ dem Release 3.1.0 eigentlich finden.

Grüße,
Harald.

Wir haben da Problem jetzt zumindest auf Ethernetlibrary + DCC++EX eingegrenzt. Da es aber Leute gibt die 3.0.8 _mit_ Ethernet am Laufen haben werden wir das auch noch hinbekommen.

Grüße,
Harald.

So, nach 3.0.1 bis 3.0.16 gibt es jetzt ein neues Release mit 3.1.0.

Hier ist die lange Liste von Neuerungen/Fixes: https://github.com/DCC-EX/CommandStation-EX/releases/tag/v3.1.0-Prod

Fred nennt das einen "minor" Release. Nicht weil intern nicht viel passiert wäre (lest es durch) sondern weil das Interface immer noch schön kompatibel mit dem vorigen ist. Wenn man den Zip runterlädt anstelle den Installer anzuwenden, dann bitte nicht über das alte drüber entpacken, das gibt Probleme mit alten Dateien. Also zuerst das Alte löschen oder verschieben und dann das Neue entpacken wenn es an die gleiche Stelle soll.

Die den Installer getestet haben sagen mir der geht jetzt auf Windows und Linux. Na dann gut. Ich installier aber immer noch händisch mit dem Arduino IDE und kopiere/editiere config.h. Sind ja wirklich nicht viele Einstellungen die man machen kann. Auch das ist ein Ziel von uns, weder der Anwender noch der Entwickler mag 100 Einstellungen die man alle verdrehen kan. Auf MacOS weiss ich nicht was der Installer macht (oder auch nicht). Händisch geht auch auf MacOS.

Grüße,
Harald.

Hallo!
Hardwarefrage rein aus Interesse:

Hat jemand schon überlegt/versucht DCC++EX auf einem Raspberry Pi Pico (oder Arduino pinkompatiblen Versionen davon) zu installieren?
Der ist um einiges leistungsfähiger und extrem günstig und sollte eigentlich (fast) genauso zu programmieren sein.
Wenn es jemand versucht hat, interessieren mich die Erfahrungen damit.

Nur so aus Interesse, ich will definitiv keinen Glaubenskrieg oder Endlosdiskussionen auslösen.

LG
Thomas

Hallo Frank,

schön dass deine Command Station grundsätzlich funktioniert. In JMRI kannst du die Weichenstellung invertieren, das scheint man öfter zu brauchen. Schau mal auf

https://www.jmri.org/help/en/package/jmri/jmrit/beantable/TurnoutTable.shtml

da müsste hoffentlich die Lösung zu finden sein. So weit bin ich allerdings noch nicht, bei mir geht “Fahrbetrieb“ erst auf meiner kleinen Testanlage, da gibt es nur eine Handweiche. Aber ich hatte das schon mal gesehen.


LG - Tom

Zu der Weichenstellung: Ja ist mir bekannt. Ich arbeite an einer Lösung, die ist aber etwas verzwickt, also nicht die technische Lösung sodern wie man das so hinbekommt dass es dem Standard und der Dokumentation übereinstimmt. Alles geht zurück darauf ob man "abzweigend" als 1 oder 0 (true/false) ansieht. Im NMRA Standard steht darüber nix. In der alten NEM auch nicht. Erst im RCN-213 stehts. Den haben aber nicht alle gelesen und/oder verstanden oder überhaupt gewusst dass man da gucken sollte. So hat sich eingeschlichen dass es zwischen JMRI und DCC++ anders ist als auf dem Gleis und dann gibts auch noch 3 verschiedene Arten um in DCC++ Weichen zu stellen. Also ich arbeite an einer Lösung und es wird wahrscheinlich sowohl DCC-EX als auch JMRI betreffen. Bis es eine Lösung gibt habe ich folgenden "quick fix" anzubieten:

Man suche in DCC.cpp folgende Zeile:


Das ändert man zu



Dann Compile+Upload im Arduino IDE.

Damit dreht man bei allen DCC Zubehörbefehlen (Weichen, Signale, ...) die Logik um. Ist das nicht praktisch mit Open Source? Wie gesagt, ein richtiger Fix ist in Arbeit.

Zu dem Problem mit dem Fahrregler (damit ich das richtig verstehe):

* Ist das der graphische Fahrregler in JMRI?

* Fährt die Lok in die richtige Richtung, also mit Schornstein oder Führerstand 1 vorraus wenn man auf Vorwärts stellt?

* Meinst du die Stellung in der der graphische Fahrregler startet und man eine neue bis jetzt noch nicht angewendete Lok wählt?

Wenn das alles "Ja" ist dann liegt das Problem in JMRI weil zu dem Zeitpunkt hat JMRI überhaupt noch nix zu DCC++ gesagt, die Lok wird von JMRI erst richtig angewählt wenn der erste Geschwindigkeitsbefehl gegeben wird (ob das so sein soll kann man auch diskutieren). Aber ich kann mir das auch angucken, bis dahin muss man halt einmal auf "vorwärts" klicken.

Grüße,
Harald.

Hallo Frank,

da ich das unter der Überschrift “JMRI: Turnouts Documentation“ gefunden hatte, habe ich das als grundlegend für JMRI im ganzen gehalten - von Panel Pro habe ich da auf die Schnelle nichts gelesen. Sorry wenn's nichts hilft.


LG - Tom

Ja, und genau da liegt der Hund begraben weil nach RCN-213 ist gerade/closed auf dem Gleis 1(on) und gebogen/thrown auf dem Gleis 0(off) und das <a> Kommando sollte so sein wie auf dem Gleis. Da es aber om DCC++ schon lange andersrum war muss man da vorsichtig rangehen sonst bekommt man einen shitstorm wenn man jetzt plötzlich zu JMRI sagt: Bitte andersrum.


Ist ganz einfach:
Issue:  "Startup direction of software throttle window in JMRI for DCC++ throttle is "reverse". Should be "forward".

Nein, der Eigenstromverbrauch wird nicht gemessen. Doch deine Hardware braucht ja nicht 100% funktioniernen. Funktioniert die Kurzschlussmeldung über USB wenn du einen Kurzschluss machst? Zieht eine Auto Bremsleuchte (15-21W) zwischen 1A und 2A auf dem Hauptgleis? Hast du die neuste JMRI Version? Funktioniert das Auslesen von CV (dann hast du schon mal Strommessung auf dem Proggleis). Spannung kannst du ohne extra Hardware und Software nicht messen, ich glaube da macht dir JMRI was vor.

USB: Der Arduino hat nun mal den USB Anschluss den er hat. Fuzt aber mit USB-OTG-Kabel und der Webthrottle auf dem Handy, so man kann es zum Laufen bekommen mit USB und Kabel ohne Computer.

Weder mit USB-OTG oder mit Withrotttle, dann aber über einen ESP-01 oder solches Shield.

Grüße,
Harald.

Die USB-OTG gibts in verschiedenen Formen aber dazu muss das Gerät das auch können, also logisch auf "A" wechseln, weil der Arduino ist immer "B". OTG heisst ja dass der Anschluss beide Richtungen kann.


Wenn eine Fehlermeldung kommt dann schaltet DCC-EX auch ab. Je länger der Kurzschluss bestehen bleibt, je länger wird gezögert bis wieder eingeschaltet wird. Am Anfang will man wegen Kehrschleifenautomatik schnell wieder einschalten. Dann aber nicht mehr wenn der Kurzschluss bestehen bleibt. Später sind dann die Einschaltversuche so 10-20ms und die Pausen 10s. Ob dann irgendwann mal permanent abgeschaltet werden soll (mit Mitteilung an JMRI) darüber scheiden sich die Geister. An der Stromanzeige in JMRI wurde in letzter Zeit etwas zuviel rumgewerkelt, kann sein dass man da 4.25 braucht.

Grüße,
Harald.

Hallo Harald,

in diesem Zusammenhang fällt mir ein. daß doch einer Deiner Kollegen vom dem Team ein DCC-Treiberboard (als "Motorshield"-Ersatz) angedacht hatte. Ich hatte neulich mal gesucht, aber nichts gefunden. Gehe ich richtig in der Annahme, daß das Projekt eingeschlafen ist? (was kein Vorwurf sein soll!)

Klaus

Was ich jetzt von Gathow gesehen habe war von der Programmierung her eher "spannend". Auch kann man darauf nicht weiter aufbauen da das "Produkt" einen "Coctail" von SW-Lizenzen enthällt die nicht immer verträglich sind.

Die Firebox/Fireshield ist auf Eis da der Entwickler gerade was anderes macht, Studium fertig oder so. Das "neue" Treiberboard von 2021 von einem anderen Entwickler gibts als Prototyp, ich bin aber noch nicht überzeugt dass das so "taucht" (frei nach Brösel). Da muss man meiner Meinung noch mal ran.

Grüße,
Harald.

Ja, das Drama um Firebox/Wasatech habe ich ja mitbekommen. Da drohten zumindest einige, auf ihrem Geld sitzenzubleiben. Wie das dann ausgegangen ist, habe ich nicht weiter verfolgt. Ich habe mir noch das von Frank verlinkte Projekt angeschaut. DCC-mäßig ist das auch durch eine reguläre H-Bridge gelöst, einerseits ein Infinion-Chip, andererseits ein ST-Chip, jeweils 5A Maximallast. Die eine Implementierung hatte laut Schaltplan noch einen Railcom-Detektor eingebaut.

Klaus

Bei der Entwicklung von HW seh ich folgende Probleme:

1. Konkurrenz von Bastellösungen aus anderer "Chinahardware" (IBT-2) die einem fast nachgeworfen wird.
    Ist nicht notwendigerweise gut aber oft dann doch "gut genug".

2. Die vor allem in den USA verbreitete Ansicht: "RailCom ist so marginell, das brauchen wir nicht (*)". Das führt dann zu
    HW die kein RailCom kann und dann kann man ja gleich was aus 1. basteln.

3. Sachen in HW lösen die man auch in SW lösen kann. Tut mir leid ihr HW-Designer, aber in SW ist das flexibler, man
   packt also zuviel auf Version 1.0. Wobei gewisse HW braucht man doch. Siehe 2.

Hm. VNH7070, kann der Chip alles was man will?

Grüße,
Harald.

(*) ... verstehen wir nicht und wenn Digitrax ohne auskommt dann kann es gar nicht so wichtig sein

Mich stört halt so ein bißchen, daß am Ende immer die eierlegende Wollmilchsau herauskommen soll, hier dann mit diversen Anschlüssen für die Bussysteme und so weiter.

Leider bin ich entwicklungstechnisch nicht so drauf, daß ich das selber realisieren könnte, aber meine Vision wäre eine eben eine einfache H-Brücke, die für die geforderte Flankensteilheit und die Frequenz von DCC geeignet ist, und evenuell eine Schaltung für Railcom dazu. Das ganze kurzschlußfest (mit Erkennung), vielleicht noch ein I2C-IC für Strom-/Spannungsmessung. Das entspräche dem Prinzip, das man in der "Maker"-Szene (mag den Begriff nicht) gerne verfolgt: Man konzentriert sich auf ein einzelnes Problem, das man lösen will. Was man durchaus noch machen könnte: Gleichrichter und Spannungsregler, realisiert als Bestückungsvariante. D.h. die Bauteile brauchen nicht vorhanden sein, wenn die Funktion nicht benötigt wird.

Klaus

Hallo zusammen,

hier gibt es ein Arduino Shield für DCC/MM und RailCom:
https://desktopstation.net/wiki/doku.php/dsshield2_en

Ist auch ein spannendes OpenSource-Projekt, nicht nur das Shield sondern auch die "fertige" Zentrale.

Grüße
Daniel

Erstmal vielen Dank für den Fund. Sowas intressiert mich. Sammler sind wir ja auch alle. Doch nachdem ich mir das angeguckt habe bin ich mit unserem DCC++EX dann doch sehr zufrieden. Müsste den Skech mal auf einen Arduino spielen und mit dem Scope ansehen wie das Signal denn aussieht. Deren Shield hat einen Kanal und externen Stromfühler. Sehe doch nix im Sketch was nach "Decoder auslesen" oder so aussieht. Die fertige Zentrale ist dann wieder andere HW und andere SW. Ganz steig ich nicht durch, kann ja auch kein Japanisch. Für "Open" wär dann vielleicht doch gut gewesen wenn man eine open source Lizenz drangepappt hätte. Irgendeine wär schon besser als nur "Copyright". So wie das jetzt ist kann ichs mir angucken und vielleicht auf meinen eigenen Arduino spielen.

Grüße,
Harald.

Hallo Harald,

doch, da kommen Methoden wie GetCurrent und getCVData vor. Im Detail habe ich mir das jetzt allerdings nicht angeschaut. Ansonsten scheint der Code ganz aufgeräumt, auch wenn auch wohl die Signalerzeugung nicht interruptgesteuert stattfindet (jedoch mit Hilfe eines Timers).

Klaus

Da liegt der Hund begraben.

Ja, was macht dann der Arduino während eines "delay()": Nix anderes.
Was macht das Signal währen der Arduino andere Sachen macht (z.B. Anwenderinput analysieren): Pause.

=> Ich bin skeptisch auch ohne den Sketch jetzt in einen Arduino hochgeleaden zu haben (der Tag hat ja nur 26h oder so).

Grüße,
Harald.

Hab den Sketch nach etwas rumrödeln (Compiler Warnungen und so) auf einen Uno gedrückt (Mega geht vielleicht wenn man den Timer anpasst) und mir das DCC Signal auf dem Ozi angeguckt. Wie erwartet 0.52 bis 1 ms Pause während der CPU anderes macht. Währen der Pause liegt dann weiter Spannung an, weiss nicht genau, hab ja nicht deren Shield. Mach denen vielleicht nichts weil ist ja eine Zentrale die eigentlich MM und DCC kann und sobald man MM anwendet sind ja Pausen im DCC Signal sowieso drin.  Die Software spricht also default MM und wenn man im Schnittstelenkommando 49152 (0xC0000) zur Adresse addiert dann bedeutet das "DCC". Wird dann intern wieder abgezogen. Das dazgehörige Windowsprogram macht das hinter den Kulissen automatisch. So, jetzt weiss ich zumindest was (oder auch nicht) los ist mit dem "desktop station shield".

Grüße,
Harald.

Hallo,

deren Shield ist ja auch nichts großartig anderes, nur ein MOSFET Motortreiber mit optionaler PWM Stromregelung, diese wird hier halt nicht verwendet.

Grüße, Peter W

Prototyp mit PWM hab ich übrigens auch, funzt jetzt mit EngineDriver und  auch mit EX-RAIL, unserer neuen Automation. Bis jetzt aber nur auf Anfrage im Discord. Wenn von Intresse, bitte melden.

Grüße,
Harald.

Hallo zusammen,

hat der Firebox Entwickler eigentlich seine Sourcen mal irgendwo veröffentlicht nachdem er das Kickstarter Projekt in den Sand gesetzt und einige Interessierte um ihre Investition gebracht hat? Ich hatte irgendwo gelesen, dass er das machen wollte .... Evtl. könnte man darauf aufsetzen!?

Gruß Jürgen

Ich weiss nicht ob die letzte Version des HW-Designs veröffentlicht wurde. Wenn du daran intressiet bist Hardware für DCC++EX zu entwickeln würde ich vorschlagen sich mit anderen Intressierten im Discord zu koordinieren. Es gibt da bestimmt Sachen wo man drauf aufbauen kann. Ist auch nicht so dass der David das absichtlich in den Sand gesetzt hat aber ich glaube er hätte sonst sein Studium in den Sand gesetzt und das wär wohl noch blöder gelaufen. Natürlich hätte es mich auch gefreut wenn es funktioniert hätte, vor allem weil dann hätten wir jetzt eine gescheite HW für die SW. Doch muss man wenn man einen anderen CPU nimmt als den Arduino 2560 (was man wahrscheinlich will) ein bisschen portieren, sollte aber dafür vorbereitet sein. Dann muss man heutzutge genau überlegen auf welchen CPU man setzt. Hat man Pech kauft die Autoindustrie einem alles weg oder so

Grüße,
Harald.

Hallo, ich poste heute zum ersten mal hier, habe aber schon einiges mit Interesse gelesen.

Meine DCC++ EX Station mit dem L289 Motor shield läuft zu meiner Zufriedenheit. Nun möchte ich das System weiter ausbauen. Dazu meine Frage:
Spricht etwas dagegen oder hat jemand schon damit Erfahrungen gemacht, auf den Arduino Mega zwei Motor shields übereinander zu stecken und mit zwei Netzteilen die doppelte Leistung für zwei Stromkreise zur Verfügung zu stellen?

Viele Grüße Uli

Du willst etwas was noch in Entwicklung ist: Mehr als 2 Stromkreise. Da muss man dann mehr als 2 AD-Wandler abfragen und dass kann der Sketch bis jetzt noch nicht. Es gibt aber einen Prototyp.

Wenn du nur so zwei Shields nimmst dann bekommst du Konflikte bei den Stromfühlern, A0 und A1, keine Ahnung was da passiert wenn man die einfach paralell schaltet, ich würde eher sagen "nicht gut". Oder willst du die Endstufen per Shield zusammenschalten? Was passiert dann mit dem L289 Pärchen und der Überstromerkennung?

Wenn du programmieren willst/kannst dann kann ich dich in die richtige Richtung schubsen

Grüße,
Harald.

Okay, Stromfühler auf A0 und A1 sind natürlich ein Argument dagegen. Sind das die einzigen Rückkanäle vom Motorshield?

Liege ich richtig damit, dass man die Stromfühler nur als Rückmelder zum Programmieren und für Railcom benötigt?
Dann könnte man die beiden Kontakte auf dem 2, Shield mit den damit verbundenen Einschränkungen deaktivieren. Man braucht ja nicht zwei Programmiergleise.

Also erstmal, RailCom haben wir noch nicht und mit dem ollen L289 wird das ohne extra HW auch nix weil der Innenwiderstand der H-Brücke zu groß ist. Leider hab ich bis jetzt noch keine Motorshields gefunden die Mosfet und guten Stromfühler vereinen.

Je nach Motorshield sind A0 und A1 die einzigen Rückkanäle, manche Shields haben auch noch einen "Fault".



Nein, die Kurzschlusserkennung/Abschaltung läuft auch noch darüber. Man braucht keine 2 Programmiergleise aber man will dann doch auf Überlast reagieren. Ein externer Booster hat ja auch Kurzschlussabschaltung. Im Gegensatz zu anderen Shields hat das L289 ja keinen eingebauten Selbstschutz. Solche Shields mit eingebautem Schutz könnte man ja draufstacken und dann das L289 zum Programmieren behalten.

Grüße,
Harald.

Die zusätzlich notwendige Kurzschlusserkennung / Überstromabschaltung kann man vielleicht mit einem zusätzlichen Stromsensor wie diesem hier realisieren:

https://wolles-elektronikkiste.de/max471-stromsensor

Dafür bräuchte es einen zusätzlichen überwachten Analogport auf dem Arduino der bei gemessen 2A (zulässige Oberlast des Motorshields) die Schutzschaltung aktiviert. Wenn man das weiter ausrollt, wären sogar noch weitere gestapelte Shields für mehrere Stromkreise denkbar.

Ist so ein Ansatz denkbar, oder bin ich auf dem Holzweg?

PS. Auf der DCC++EX Seite sind werden auch einige alternative leistungsstärkere Motorshields vorgestellt. Diese unterstützen jedoch immer nur einen main und einen prog Anschluss.

Wie ich gesagt habe, es gibt einen Prototyp im Git mit mehr als 2 Kanälen. Pro Kanal braucht man mindestens einen Input (am besten analog) und einen Pin zur Steuerung (also man muss den Kanal ja an/aus machen). Und beim Stapeln die richtigen Pins trennen. Wie  du an die A0/A1 in der Mitte von 3 Lagen kommst wird noch intressant.

Oder ein Shield wo man das per Kanal per SPI machen kann. Gibts auch, z.B. http://www.robotpower.com/products/MultiMoto_info.html Dazu müsste man dann natürlich auch noch mehr SW machen.

Grüße,
Harald.

Ist der Prototyp mit den mehreren Kanälen schon verfügbar ? In er aktuellen MotorDrivers.h sind für die verschieden Platinen immer nur 2 Kanäle verfügbar.
Beim Standard Shield stelle ich mir die Konfiguration für ein zweites shield etwa so vor:

new MotorDriver(3, 12, UNUSED_PIN, UNUSED_PIN, A0, 2.99, 2000, UNUSED_PIN),
new MotorDriver(11, 13, UNUSED_PIN, UNUSED_PIN, A1, 2.99, 2000, UNUSED_PIN),
new MotorDriver(4, 12, UNUSED_PIN, UNUSED_PIN, A2, 2.99, 2000, UNUSED_PIN),
new MotorDriver(5, 12, UNUSED_PIN, UNUSED_PIN, A3, 2.99, 2000, UNUSED_PIN)

Dann könnte man mit einer Zwischensteckeinheit dem A0-Pin des Motorshields auf den A2-Pin des Arduino legen, den A1 auf A3, 3 auf 4 und 11 auf 5 legen.

Dann sollte es relativ einfach möglich sein durch Überwachung von A2 und A3 die beiden Kanäle des zweiten Shields zu überwachen.

Gruß Uli

Det Sourcecode ist etwas älter, so den letzten Pin gibts da nicht und die Slaveboards brauchen ja nicht alle Pins.

Ich glaub das wär ungefähr so:

#define MULTIBOARD F("MULTIBOARD"),\
  new MotorDriver(3, 12, UNUSED_PIN, UNUSED_PIN, A0, 2.99, 2000),\
  new MotorDriver(11, 13, UNUSED_PIN, UNUSED_PIN, A1, 2.99, 2000),\
  new MotorDriver(4, A2, 2.99, 2000),\
  new MotorDriver(5, A3, 2.99, 2000),\
  NULL,\
  NULL

#define MOTOR_BOARD_TYPE MULTIBOARD

https://github.com/DCC-EX/CommandStation-EX/tree/multiBooster

Aber das ist jetzt über ein halbes Jahr her und man müsste das mit aktueller Source mergen, so wenns nicht geht - Tja, happy hacking -

Grüße,
Harald.

Vielen Dank, dann werde ich das mal so testen. Mein 2. Shield ist bereits auf dem Weg zu mir.

Du meinst sicher in der config.h:
#define MOTOR_SHIELD_TYPE MULTIBOARD

Die zweite Verbesserung / Weiterentwicklung die ich gerne umsetzen möchte ist die Anzeige des aktuellen Stromverbrauches des main tracks auf dem LCD Display, also von A0. Kannst du mir dazu einen Tipp geben wie ich die Daten abfragen kann.

Gruß Uli

Der aktuelle Stromverbrauch wird regelmäßig schon abgefragt (sonst gäb es ja keine Kurzschlusserkennung). Was du im loop() noch machen musst ist den Wert auf das LCD zu schubsen. Vielleicht nicht jedes Mal im loop(). Die Funktion die du brauchst ist DCCWaveform::mainTrack.getCurrentmA().

Wenn dir Lust nach mehr ist, dann empfehle ich unseren Discordserver.

Grüße,
Harald.

Ich habe jetzt dank der Tipps von Harald den aktuellen Stromverbrauch auf dem Display. , sicher nicht in der programmtechnisch besten Variante, aber es funktioniert und das Display hat einen neuen zusätzlichen Nutzen.

Die Aktualisierungsfrequenz des Displays habe ich von 3 auf 1 Sekunde reduziert (LCD_SCROLL_TIME), damit der angezeigte Stromverbrauch auch aktuell ist. Der angezeigte Wert ist ein Mittelwert ermittelt über die Dauer einer Sekunde. Die Anzeige ist bei mir jetzt nur noch 2zeilig, wie auch mein Display, so entfällt das ansonsten notwendige Scrollen. Die Version und die "Starting"-Anzeige erfolgt nun nur noch während des Bootens.

Du darfst den Code schon herzeigen, vielleicht erbarmt sich jemand und steckt es so oder etwas verbessert in den nächsten Release.

Z.Z. wird an folgenden Fronten gearbeitet:

* Automationsscripte
* DC-District (also einen oder beide Ausgänge auf DC PWM umstellen und dann von einer "Adresse" fahren)
* ESP8266 port

Grüße,
Harald.

Folgende Änderungen/Ergänzungen habe ich umgesetzt:

CommandStation-EX_3.1.ino:

a) vor dem void setup() eingefügt:
     #include "DCCWaveform.h"

     // Variablen-Definition for "DCCCurrentAmpereDisplay.h"
     long rawAmpere = 0;
     long numValue = 0;
     unsigned long time=0;

b) LCD(2,F("Free RAM=%5db"), ramLowWatermark);
         in
     LCD(1,F("Free RAM=%5db"), ramLowWatermark);
         geändert

c)  und am Ende der void loop() - Schleife ein
       #include "DCCCurrentAmpereDisplay.h"
     eingefügt

Der Include-File "DCCCurrentAmpereDisplay.h" sieht wie folgt aus:

// AmpSampRate - Current ampere sampling rate in milliseconds defined in config.h
// <#define AmpSampRate 1e3>  (=LCD_SCROLL_TIME)

  if ( millis() < (time + AmpSampRate) ) {
    numValue++;
    rawAmpere += DCCWaveform::mainTrack.getCurrentmA();
  }
  else {
    int avgAmpere = (rawAmpere/numValue) + 0.9;
    LCD(0,F("Main AVG= %4dmA"), avgAmpere);
    time = millis();
    numValue = rawAmpere = 0;
  }

In der config.h habe ich die Definition für die Abtastrate am Ende eingefügt:

// Current ampere sampling rate in milliseconds
// für "DCCCurrentAmpereDisplay.h" = LCD_SCROLL_TIME
#define AmpSampRate 1e3

Und dann habe ich nach der LCD_SCROLL_TIME gesucht und diese von 3000 in 1000 Millisekunden geändert.

Die von Uli_22 zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Mein 2. Motorshield ist eingetroffen.... und es funktioniert.

Ich habe beide Motorshield übereinander auf den >Arduino< gesteckt und dabei die PIN-Verbindungen D3, D11, D13 und A0 bis A3 zwischen den beiden Motorshield getrennt. Dann habe ich auf dem oberen Bord D4 mit D3, D5 mit D11 und D12 mit D13 gebrückt. Die Arduino PINs A2 und A3 habe ich mit A0 und A1 des oberen Motorshields verbunden.
Nun habe ich auf dem unteren Shield einen MAIN und einen PROG - Gleisanschluss und auf dem oberen Shield 2 x MAIN-Gleis, also 3x 2Ampere max. Ausgangsleistung und somit genug Power für mehrere Züge, digitale Weichen u.v.m.

Die Multibooster-Version ist 3.0.11. Es wäre schön, wenn die Möglichkeit eines zweiten Motorshields in den Standard übernommen werden würde, damit auch die Multibooster-Version von zukünftigen Weiterentwicklungen profitiert.

Fein dass es funktioniert.


So langsam merkt man schon dass das Team ein paar mehr Leute vertragen könnte die verschiedene Features im Source Code unter einen Hut bringen.

Wie heisst es so schön in Stellenangeboten: Vertrautheit mit C++ ist Vorraussetzung und mit Git von Vorteil.

Grüße,
Harald.

Hallo,

nach einer längeren Moba Pause, habe ich mal wieder versucht etwas mit DCC++EX zu machen.
Nach einen Update auf die aktuelle Version, klappt leider die Ethernet Verbindung nicht mehr.

Auch nach vielen Versuchen, bekomme ich keine Verbindung.

Kann mir da jemand weiter helfen?  Hat sich irgendetwas verändert zu den älteren Versionen?

Vielen Dank

Grüße

Peter

* Von welcher Version auf welche?
* Was kommt über USB, da sollten DIAG Mitteilungen kommen
* Welche Ethernet Karte und welche Library. Immer noch die Gleiche wie da wo es funktioniert hat?

> Hat sich irgendetwas verändert zu den älteren Versionen?
Ja wie soll ich darauf jetzt antworten?

Sonst frag im Discord.

Grüße,
Harald.

Hallo,

von der Version 3.05 auf die aktuellste, die auf der Internet Seite freigegeben ist, glaube 3.10 oder 3.1.1.

Über USB habe ich eine Verbindung, wenn ich den richtigen Com Port einstelle. Da ist alles OK.

Ja es ist die gleiche Ethernet Karte und die gleiche Library.

Jetzt zeigt sich leider wieder, don't Change a running System.
Wollte nur updaten, hinterher ist man schlauer.

Grüße
Peter

Probier einfach mal den aktuellen code aus github, 3.1.6 oder so.  3.1.0 könnte ein Ethernetproblem gehabt haben.
Leider ist man auch von Updates der Ethernet Library nicht sicher.
Grüße,
Harald.

Hallo,

habe jetzt die aktuelle Version 3.1.6 versucht.
Sowohl über Ethernet wie auch über WiFi, klappt es mit der Netzwerk Verbindung nicht, leider.

Habe es mit der IDE und auch über den Installer versucht.

Derzeit habe ich nur eine Verbindung über USB, dann ist alles OK und funktioniert.

Auch die Verbindung zu WDP klappt gut.

Grüße
Peter

Ethernet habe ich nicht, aber WIFI geht bei mir mit der Version 3.1.0 ohne Probleme. Ich arbeite nur mit der Arduino IDE.

Wenn WIFI nicht geht, versuche mal Ethernet zu deaktivieren. In deiner config.h Datei sollte es eine Zeile

#define ENABLE_ETHERNET true    

geben. Ändere true nach false und lade den Sketch neu in den Arduino.

Viel Erfolg Uli

Wir versuchen noch vor dem Fest eine neue Version rauszubringen. "Release Candidate" gibts schon im Git. Wenn jemand Probleme hat, dann bitte doch über die Funktion im Discord da ein support ticket aufmachen oder einfach in einem der Supportkanäle um Hilfe bitten. Da kommt dann immer recht schnell eigentlich immer jemand zur Hilfe. Z.Z haben wir Helfer in Zeitzonen von Australien bis Californien auch wenn der Löwenanteil in Europa und an der US-Ostküste daheim ist. Was wir eigentlich immer haben wollen ist was übers USB ausgespuckt wird (Version, Fehlermitteilungen etc). Gut zu haben wenn man Hilfe braucht.

Grüße,
Harald.

Ich weiss schon von kleinen Fehlern in 3.1.0, aber in deinem Anwendungsfall bist du halt noch nicht darüber gestolpert. Wer vor 3.2.0 RC noch Angst hat kann auch 3.1.7 nehmen. 3.2.0 hat solche Sachen wie Automation, man kann also z.B. Routes einkompilieren oder einfache Abläufe wie z.B. Pendelzugsteuerung. Typischer Anwendungsfall: Den Kringel unterm Baum etwas zu beleben. Wahrscheinlich wird das 3.2.0 dann beim Release 4.0.0 genannt (achja, das "Marketing").

Grüße,
Harald.

PS: https://github.com/DCC-EX/CommandStation-EX/tags

Hallo,

gibt es schon einen (empfehlenswerten) Hardware WiFi-Handregler? Bei DCC++ EX sind die WiFi Throttels alle als Apps ausgeführt.
Ich stelle mir ein OLED-/LCD-Display vor, Dreh- oder Schieberegler, zur Not auch Up-/Down-Tasten und paar Tasten für Direktzugriff auf die Funktionen F0...Fxx.


Viele Grüße,
SX1-Norbert

Hallo Norbert,

meinst Du sowas?
https://sites.google.com/view/frankydcc/startseite/franky-m5f
Basiert auf den Modulen von https://m5stack.com/

Ich finde das M5Stack ein geniales Konzept. Und bevor jemand schreit: es ist fast alles Open Source.

Grüße
Daniel

Hallo Daniel,

ja, genau sowas Vielen Dank!
Hintergrund: Mein Großcousin baut aktuell eine Gartenbahn, einfache Strecke. Jetzt suche ich für ihn eine interessante (Bastel-) Lösung, seine Lok per Funk zu steuern.
Und vielleicht ist das auch eine interessante Bastelei für zu Hause

Wenn es noch Vorschläge gibt, gern her damit.


Viele Grüße,
SX1-Norbert

Für die Großbahn: Ich hab da einen Prototyp für die Bahn um den Weihnachtsbaum: Eine DCC-EX Zentrale auf einem ESP32+LiPo in die Loks gesteckt und dann fahr ich die Lok von EngineDriver über WiFi. Etwas in der Source geändert und schon kommt PWM aus dem GPIO Pin. Für Märklinmotoren reicht ein MOSFET per Wicklung. Für Gleichstrommotoren müsste man noch ne H-Brücke unterbringen. Jede Lok hat also ihre eigene Zentrale mit eigener IP an Bord und auf den Gleisen ist nur Spannung für den Motor und Ladung der Batterie für den CPU. Irgend eine Spannung zwischen 12 und 20V geht, wird in der Lok sowieso gleichgerichtet. Dann noch etwas programmiert dass die Lok auch mit den Lichtern blinkt wenn sie ohne Motorspannung dasteht und einen Schubs braucht. Auch muss man den CPU abschalten wenn der LiPo anfängt an seine Spannungsuntergrenze zu kommen.

Es gibt auch mehrere Projekt für HW-Handregler sowohl für Withrottle als auch fürs DCC++ Protokoll. Sowohl Withrottle als auch DCC++ sind über TCP, also braucht man eine Battere für den CPU damit bei einer Schmutzstelle der CPU nicht wieder startet sondern schön die Verbindung aufrechterhällt.

Grüße,
Harald.

Hallo,

Ja, die schönen Chips von Infinion, habe ich mir neulich auch mal angeschaut. Schnell genug scheinen sie ja zu sein (25 KHz), Flankensteilheit vermutlich auch (habe jetzt die Vorgaben von DCC nicht im Kopf). Stolze Leistung, die aber auch ihren Preis hat. Generell ist die Frage, ob bei so hohen Strömen die Erkennung eines Kurzschlusses noch schnell und sicher genug abläuft. Das wurde ja schon mal hier in dem Forum diskutiert. Ein anderes Thema ist, daß das ja zwei getrennte Halbbrücken sind. Das DCC-Signal muß da daher zweifach geliefert werden, einmal normal, einmal invers. Sollte kein großes Problem sein, aber ich weiß nicht, ob die Software das out-of-the-box kann.

**Nachtrag: 10:08** scheint zu gehen über "signal_pin2" beim MotorDriver.

Ich habe mir erstmal zum Herumexperimentieren ein kleines Bord mit einem DRV8801 (1A max.) für rund 6 Euro gekauft. Viel anderes gibt es im Moment wohl auch nicht, die H-Brücken sind offenbar auch von der Chip-Krise betroffen. Wenn man bei Digikey oder Mouser schaut, sind die Lager alle leer und Lieferzeiten von Monaten bis ein Jahr…

Klaus

Also fürs Main Track gehen die meisten dieser High-Power Shields ohne Probleme, man muss sie halt auf sagen wir mal 3-5A runterdrehen und bei 3-5A geben sie auch genug Volt am Sense damit man das kann. Aber mit Programmieren ist da halt dann nix mit so einem Teil. Wie man "main" von einem standard shield mit so einem Teil ersetzt steht auf der Homepage. Mit dem jetzt freien Ausgang kann man dann mit etwas externer Strombegrenzung auch noch einen Boosterbus füttern. In der Software kann man Signal-Pin und Invers-Signal-Pin definieren. Siehe Motorshields.h.

Das Grundproblem vom "Standard Shield" ist ja der antike Halbleiter mit dem riesen Spannungsabfall und der daraus resultierenden Verlustwärme. 2A reichen mir per Abschnitt in N eigentlich aus, wenn man die 2A denn im Dauerbetrieb ganz ausnützen könnte. 2,5A wären fein. 3A reichen recht sicher und auf 5A will ich bei N nicht hochgehen.

Grüße,
Harald.

Hallo,

ich habe nach langer Pause wieder den Arduino vorgeholt. Er ist mit dem Ethernet-Shield und dem Motor-Shield ausgestattet. Also nur Huckepack aufgeschnallt. Am Motor-Shield die V-In Pin durchtrennt. Läuft mit der V3.0 einwandfrei.

Habe jetzt V3.1 aufgespielt, ein OLED-Display 128 x 64 angeschlossen und in der 'config.example.h' freigeschaltet. Klappt alles und wurde sofort erkannt. Jedoch werden auf den Zeilen nur 16 Zeichen angezeigt. Der Rest wird abgeschnitten. Ist bei der Zeile mit der IP aufgefallen. Dort wird die letzte Zahl nicht angezeigt. Habe dann in der 'EthernetInterface.cpp' in der Zeile 83 den Text 'IP: ' rausgenommen. Jetzt ist der Text verkürzt und die IP wird komplett angezeigt.

Warum ist das so? 16 Zeichen x 5 Pixel Breite sind 80 Pixel. Irgendwie komme ich mit diesem Wert nicht klar. Der passt in keine Einstellung. Wo muß ich noch in den Einstellungen dran drehen?

VG Sven

Hallo Frank,

Danke für die schnelle Antwort. Muß ich mir noch einmal genau die Vorgehensweise durchlesen. Jetzt wo Du das mit der 'config.h' schreibst, klingelt bei mir auch etwas.
Die V3.2 konnte ich bis jetzt nicht finden. Wurde von der Homepage auf die V3.1 verwiesen zum Download. Werde mich da aber noch einmal belesen.

VG Sven

Hallo Frank,

nochmals vielen Dank. Ich habe den Fehler gefunden. Der liegt zwischen meine beiden Ohren. Problem ist weniger das Verständnis von Elektronik und Software, sondern das Fach-Englisch.
Habe mir nun die V3.2 geladen und meine Einstellungen in der 'config.h' gemacht und nun klappt alles. Nach weiterer Durchsicht ist mir aufgefallen, das sich seit der V3.0 eine Menge getan hat. Muß mich da aber erst noch etwas durchlesen. Trotzdem habe ich noch eine Frage dazu. Ist es geplant auch Loconet zu integrieren? Bei den Infos konnte ich jedenfalls nichts finden.
Warum frage ich danach. Hier wird viel über Motortreiber (Booster) geschrieben und diskutiert. Man kann aber nicht unendlich viele auf die DCC-EX packen. Es fehlen dann einfach die benötigten PIN's. Mein Gedanke dazu ist, dem DCC-EX im jetzigen Ausbauzustand ein Loconet-Shield zu spendieren und am Loconet dann Loconet-Booster anschließen. Das würde dann pro Booster 1x Uno + 2x Motor-Shield + 1xLoconet-Shield sein. Beim Motor-Shield  hätte man den Vorteil, das der Programmierausgang entfällt und man mit 2 Motortreiber 4 Boosterausgänge hätte.

VG Sven

Also wenn du nur das Boostersignal brauchst dann einfach auf Pin1 und Pin6 einspeisen. Dazu braucht es kein Shield.

Wenn du wirklichen LocoNet Datenverkehr zur CS willst dann musst du erstmal die LocoNet Lib anpassen sonst zerhaut die dir das Timing fürs DCC Signal - ich habs nicht geschafft. Also mein Ansatz ist seperater Uno mit LN-Shield und dann da drauf Slotmanager implementieren. Kommunikation mit der CS in Serial.

Wir feilen gerade an den Releasenotes für 4.0 (so heisst dann 3.2.0rc13 oder 14 wenn fertig).

Grüße,
Harald.

Wenn jemand testen will, dann das da: https://github.com/DCC-EX/CommandStation-EX/releases/tag/v3.2.0rc13

Hallo Frank und Harald,

das hier sehr viel per I2C Bus eingebaut wurde ist mir aufgefallen (Sound, RM, Servo usw.). Werde mich da erst mal zurückziehen und lesen, bevor ich mich entscheide was ich mache.
Zur Zeit habe ich einen Loconet-Buffer Ethernet (Arduiono Basis) und den DCC-EX Ethernet hier Betriebsfertig liegen, die auch perfekt funktionieren. Mein Gedanke war, beides zu vereinen. Aber wenn das vom Timing her Problematisch ist, dann lasse ich es. Man muß das Fahrrad auch nicht zweimal erfinden. Das mit dem zweiten Motor-Shield werde ich auf jeden Fall mal in Angriff nehmen.
Vielen Dank noch für die Starthilfe. Wenn man mal einige Zeit abwesend war, dann merkt man erst mal, das einiges nach zu holen ist.

VG Sven

Dann sag mir doch mal genauer was du da hast an Hardware und Software, dann können wir ja mal sehen was man aus den Bausteinen machen kann. Meine Bausteine für LocoNet sind jetzt gerade mit denen ich dann weiterbauen möchte:

* Arduino Mega
* Motorshield
* DCC-EX 3.2.0rc13

^
|
v

* Arduino Uno
* LocoNet Shield
* LocoNet Library
* Mein halbfertiger Slotmanager

Die beiden Teile hab ich vor per Serie zu verbinden, der Mega hat ja noch freie UARTs.

Das LocoNet Shield direkt auf dem gleichen Arduino der DCC produziert seh ich als problematisch, aber vielleicht schreibt jemand die LocoNet Library, um so dass sie nicht so interruptintensiv ist, weil so wie jetzt ist da ja "Bitbanging", d.h. man schiebt per Software Bit für Bit raus und rein.

Grüße,
Harald.

Hallo,

wenn ich das richtig sehe und verstanden habe, gibt es das doch schon von Hans Tanner.

Hier der Link dazu:

https://www.youtube.com/watch?v=BG7DtPcBpxU&t=183s

Beste Grüße

Peter

Ich kenne das Projekt von Hans, Fred von unserem Prokjekt hat auch schon mit Hans geredet. Ich hab aber keine Lust einen M5 IOTT Stick zu shoppen da ich den Uno und das LN-Shield für den Uno schon hatte. Ich kann also entweder Bugs in Hans seinem Slotmanager finden (einen hab ich schon gefunden und eingeschickt ) oder meinen eigene Bugs produzieren.

Dann versteh ich beim Hans gewisse Sachen nicht, z.B wie man nicht zuerst eine gescheite Endstufe designt oder nimmt und erst dann die Verbindungen für RailCom Lücke legt. Die RailCom Lücke auf einer Endstufe zu produzieren die sowieso out of Spec ist für RailCom bringt doch nix.

Grüße,
Harald.

Das LocoNet ist wegen der großen "installed base" von Handreglern intressant. Ob BiDi für jemand intressant ist, der das dann auch implementiert weiss ich nicht, konkrete Anwendungen ("ich habe BiDi und will da was machen") sind bis jetzt noch nicht aufgetraucht. Im Gegensatz zu S88, das von sozusagen am anderen Ende des Spektrums auftaucht und manchmal gewünscht wird. Das Projekt ist wie gesagt Open Source und wenn jemand ein Problem juckt, dann kann er ja mal vorbeigucken (auf Discord) und nachsehen ob wir ein passendes Kratzstäbchen haben.

Grüße,
Harald.

Hallo Harald,



Zentrale:
* Arduino Mega
* Ethernetshield
* Motorshield
* DCC-EX 3.2.0rc13

LoconetBuffer;
* Arduino Uno
* Ethernetshield
* Loconetshield (Eigenbau mit Stromversorgung für Arduino und Loconet-T)
* LocoNetEthernetBuffer aus der Loconet Bibliothek

Loconet Decoder (diverses):
* Arduino Uno
* Loconetshield (Eigenbau mit Stromversorgung für Arduino und weitere Shield 5V und 12V)
* diverse Shield für Sound, Servo, Mortor, RM, Lichtsensor (alle können gleichzeitig aufgesteckt und verwendet werden)
* Loconet Bibliothek und eigeneRoutinen für die Shields

Loconet Decoder (Loklift):
* Arduino Uno
* Loconetshield (Eigenbau mit Stromversorgung für Arduino und Motor/RM Shield 5V und 12V)
* Motor/RM Shield
* Loconet Bibliothek und eigene Routine für die Steuerung eines Lokliftes


Das alles funktioniert. Bei der Software für den Decoder (Diverses) bin ich noch am verbessern und erweitern. Mein Gedanke war nun, einen LoconetBooster zu bauen.

LoconetBooster:
* Arduino Uno
* Loconetshield (Eigenbau mit Stromversorgung für Arduino)
* Motorshield

Damit könnte man beliebig die Leistung erhöhen, je nach Anlagenausbau. Dafür müßte ich das Loconetshield des LoconetBuffers ändern, damit das DCC Signal (entkoppelt und verstärkt) in das Loconet eingespeist werden kann. Bis jetzt habe ich da nur 12V für Loconet-T drauf. Wenn wie schon geschrieben, es zu viele Probleme macht, das auf den DCC-EX zu schnallen, dann könnte ich auch damit leben, mir nur das DCC-Signal zu holen und dann über den LocoBuffer zu realisieren.
Jetzt könnte man sagen, warum nicht das DCC Signal direkt verwenden, sondern der Umweg über das Loconet. Nun, es würde immer die Möglichkeit bieten Rückmeldungen über den Zustand der Booster zu empfangen.
Aber eventuell würde es auch per DCC-Signal und I2C gehen. Beides könnte man vom DCC-EX abgreifen und auch verarbeiten.

Einen Motor-Shield Ausgang für LocoNet-B einzuspeisen auf Pin 1 und 6 ist kein Hexenwerk. Dann der LocoNetBuffer kann ja trotzdem so bleiben wie er ist. Frage ist nur, welche Kommunikation muss eigentlich zwischen der Zentrale und dem LoconetBuffer erfolgen und in wecher Richtung. DCC++ über Ethernet oder Serial gilt zu entscheiden. Oder redet am Schluss sowieso alles mit einem Computerprogram in der Mitte? Muss ehrlich sagen dass ich Rückmeldung von Boostern nie intressant fand. Das geht erst los mit RailCom in jedem Abshnitt, aber dazu braucht man dann nen Bus mit mehr Speed als LocoNet. Etwas vertrackt das Ganze, ich brauch ja LocoNet eigentlich nur für extra Handregler und deswegen brauch ich den Slotmanager. Ohne Handregler bräucht ich den nicht. Aber SlotManager machen ist auch cool und die ich bis jetzt im Internet gefunden habe waren eher von Elektronikern programmiert (nix für ungut, aber das geht besser).

Grüße,
Harald.

Hallo Harald,

ich versuche das mal zu mit einem Vergleich. Nehmen wir mal eine Zentrale mit Loconet (IB oder DR5000). Dort werden beim ansprechen eines Fahrzeuges oder MA-Adresse die Signale auf DCC (Booster) und Loconet (PIN 3/4) parallel ausgegeben. Sind wie in unserem Fall DCC und Loconet getrennte Geräte, dann klappt das ja schon einmal nicht. Somit würden sich auch keine Handregler oder Booster ansteuern lassen. Bringen wir jetzt das DCC von der DCC-EX auf das Loconet des Buffers, dann könnte man dort weitere Booster betreiben, da diese nur das Signal (PIN1/6) verstärken. Rückmeldungen zum Booster würden dann wieder auf das Loconet gelegt.
Ob das aber so klappt oder die verwendete Software auch so unterstützt, das über zwei Zentralen verwaltet wird.? Ich möchte auch ungern das da irgendwelche Krücken in das bis jetzt sehr gute Projekt reinkommen.

VG Sven

Wenn du das Video von Hans anguckst dann ist das dort auch so, der M5 macht die LocoNet Verwaltung und der Arduino das DCC-Signal. Wenn der Arduino nur immer ganz genau das auf das DCC Signal rauslegt was vom LocoNetMaster über z.B. Serie verlangt wird,  dann geht das. Du brauchst ja auch nicht das "Schalte Weiche 17 gerade" exakt zur gleichen Millisekunder über DCC und übers LocoNet rausgeht weil Weiche 17 ist normal nur eine Weiche die entweder am LocoNet oder an DCC hängt.

Grüße,
Harald.

"Mit Roco WLAN MultiMaus die DCC++Ex CS steuern"

Zu diesem Thema habe ich nichts im Internet gefunden. Kennt jemand derartige Projekte oder Lösungen?

Es muss doch möglich sein, die WLAN Maus mit einem WiFiServer zu verbinden, der die Befehle der WLAN Maus an DCC++EX weiterreicht? Oder kann die WLAN Maus wirklich nur mit der Z21?

Gruß Uli

Das hätten einige gern, wann bist du fertig?

Die Wlan Multimaus funktioniert mit dem sogenanntren Z21 LAN protocol (nach "Z21 LAN Protocol Specification" googeln). Das sieht aus wie in UDP verpackte X-Pressnet Daten wenn ich das richtig gesehen habe. Wieviel man davon implementieren muss damit man erste Erfolgsergebnisse verzeichnen kann weiss ich nicht.

Dafür bräuchte man einen Parser. Entweder direkt auf der DCC-EX CS oder woanders (z.B. wie bei WiThrottle über JMRI). Wenn jemand so einenen Parser weiss, am besten noch Open Source GPL, bitte melden.

Wenn direkt auf der CS, dann muss man für die jetzige Implementation mit dem ESP01 Shield nur eine Port gleichzeitig unterstützt. Also muss man sich entscheiden. Eine andere Möglichkeit wäre ein Translator von Z21 LAN auf DCC++ Serie auf einem ESP8266 oder ESP32.

DCC-EX kann heute DCC++ und WiThrottle. (DCCEXParser.cpp und WiThrottle.cpp) in der neusten Version sogar gleichzeitig. Darfür gibts sowohl Apps als auch Eigenbauhandregler.

Grüße,
Harald.

Vielleicht findet sich eine Interessengruppe...

Ich denke an Lösung mit einen ESP, der über WiFi mit der WLAN Maus und seriell mit der DCC-EX CS verbunden ist.

Einen Eigenbauhandregler der mit einer TV-Fernbedienung gesteuert wird hatte ich mal realisiert. Infrarot hat aber so seine Macken, vielleicht war auch die verwendet Empfangsdiode nicht optimal auf die FB abgestimmt.

Die meisten Probs hatte ich mit den verwendeten RC libraries, Die am besten funktionierte, lief leider nicht auf dem ESP.

Gruß
ULI

Neuer Release:
https://github.com/DCC-EX/CommandStation-EX/releases/tag/v4.0.0-Prod
Etwas ausfühlicher auf https://dcc-ex.com/
Grüße,
Harald.

PS: Wenn man Kommandos von der WiFi Maus empfangen will muss man als erstes das schreiben was die UDP Pakete und das darin enthaltene X-Bus Protokoll interprätiert. Aber vielleicht gibts das schon als GPL, wer weiss?

Hallo,

ich habe Probleme mit dem Ethernet bei der v4.0.0.

Konfiguration ist ein Mega + ein Sunfounder Ethernet Shield + ein Standard Arduino Motor Shield.

Mein Problem ist, das sich das Netzwerk  nach dem DHCP aufhängt, die zugewiesene IP-Addresse bekomme ich noch durch den Mega angezeigt, dann ist das Interface nicht mehr erreichbar.

während der "Ethernet waiting for link"-loop ist das Board kurzzeitig via ping erreichbar, danach nicht mehr

-->

License GPLv3 fsf.org (c) dcc-ex.com *>
<* LCD0:DCC++ EX v4.0.0 *>
<* LCD1:Lic GPLv3 *>
<* begin OK. *>
<* Ethernet waiting for link (1sec)  *>
<* Ethernet waiting for link (1sec)  *>
<* Ethernet waiting for link (1sec)  *>
<* Ethernet waiting for link (1sec)  *>
<* Ethernet waiting for link (1sec)  *>
<* Ethernet waiting for link (1sec)  *>
<* LCD4:IP: 192.168.1.75 *>
<* LCD5:Port:2560 *>
<* MotorDriver currentPin=A1, senseOffset=16, rawCurrentTripValue(relative to offset)=668 *>
<* MotorDriver currentPin=A0, senseOffset=14, rawCurrentTripValue(relative to offset)=668 *>
<iDCC-EX V-4.0.0 / MEGA / STANDARD_MOTOR_SHIELD G-a26d988>
<* I2C Device found at x3C *>
<* MCP23017 I2C:x20 Device not detected *>
<* MCP23017 I2C:x21 Device not detected *>
<* Signal pin config: high accuracy waveform *>
<* LCD3:Ready *>
<* LCD2:Power Off *>
<p0>
PPA0
<* LCD3:Free RAM= 2676b *>

<--

Ideen woran es liegen könnte ?

VG wassi

PS: Arduino IDE ist 1.8.19 mit direkt integrierter Ethernet-Bibliothek V2.0.0

und schon wieder die 100 erreicht.

hier geht es weiter https://www.1zu160.net/scripte/forum/forum_show.php?id=1302383