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

Hallo Harald,

Ich bin beim basteln und testen ...

Mein Setup (Fotos):
- Arduino Mega (China Clone)
- MotorShield L298P R3 (China Clone)
- W5100 Ethernet Shield (China Clone)
- eigenes Shield mit ESP8266 + HC-12 + OLED Display 128x64

Auf den Fotos ist eine angepasste Version vom CVReader aufgespielt, wo die Display Bibliotheken aus DCC++ EX eingebunden sind
Hier ist im Moment Alles am Laufen:
- USB Serial
- HC-12 Serial1 (Verbindung zum Arduino Throttle)
- Ethernet
- WiFi (Serial3)

Es lässt sich alles initialisieren und damit arbeiten

Ich hab gerade nochmal DCC++ Ex upgedatet, habe es aber zB nicht geschafft Ethernet zum Laufen zu bekommen.

WiFi läuft, das Init dauert recht lange, da alle Seriellen Ports durchprobiert werden ..

Durch die Display Bibliothek steige ich noch nicht so ganz durch, mein Mini Display könnte eigentlich mehr Spalten zeigen, das ist aber per Definition fest begrenzt.

Ich muss das mal ne Weile testen, um was genaueres sagen zu können.
Das Advanced Example lässt sich bei beiden Varianten nicht kompilieren.
-> DIAGSERIAL ist nicht declariert, das sollte wahrscheinlich ein Serial Object beinhalten.

Ich habe mir eine eigene Startdatei für den CVReader gebastelt, die jetzt funktioniert.

Danke an Alle für die Arbeit

Viele Grüße, Franzi

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

*  Commandstation-EX ist seit ein paar Wochen CVReader. Also auf das Commandstation-EX Repo umschwenken und da weitermachen. Sollte eigentlich ohne Probleme zu mergen sein.

* Ethernet: Wir sind gerade am Übelegen ob/wie wir das bis zum Release zum Funktionieren bringen. Ich hab kein Ethernetshield, kann also nicht testen. Das Blöde ist dass die Ethernetlib für das W5100 a) groß und b) buggy ist. Auch wär es gut wenn man die MAC-addr aus der Arduino-Board-ID ableiten würde anstelle dass alle die gleiche in ihre config reinschreiben.

* Display ist noch in den Kinderschuhen und man muss überlegen was eine gute Standardgröße ist damit man nicht zuviel RAM verschenkt. Ich glaube Chris hat da einfach mal 16 Spalten gemacht weil es das war was er hatte.

Patches welche die IP-Adresse und den Port auf dem Display anzeigen nehmen wir gerne entgegen Auch muss man noch mehr überlegen was man wie auf einem Display wo anzeigen will, vor allem weil es so viele Varianten (Zeilen/Spalten) gibt.  Aber das ist nicht so ein _technisches_ Problem, also wahrscheinlch _schwer_  zu lösen Mein Display ist z.B. 8x21 (mit der Standardfont). Ich denke wir werden da verschiedene Formate brauchen.

Z.B. für die Stromanzeige:

#define CURRENT_FORMAT_21 F("Main:%5d Prog:%5d")
#define CURRENT_FORMAT_15 F("M:%5d P:%5d")
#if DISPLAY_WIDTH <= 16
#define CURRENT_FORMAT CURRENT_FORMAT_15
#else
#define CURRENT_FORMAT CURRENT_FORMAT_21
#endif

Und das alles im Preprocessor, sonst frisst das zuviel Flash/RAM. Das ist dann halt eine Fleißarbeit.

Übrigends sehr hübsch gebaut, da wage ich ja kaum mehr meine Sachen zu zeigen. Baubeschreibungen sind auch willkommen.

Grüße,
Harald.

Hallo Harald,

bin auch am basteln und testen.

Da ich überlege eine andere Moba Software zu nutzen, teste ich gerade ob auch DCC++EX von dieser Software unterstützt wird.

Leider kommt es hier zu Problemen, obwohl von der Software DCC++ unterstützt wird und es
grundsätzlich funktioniert.

Woran kann das liegen? Gibt es da Unterschiede?

Grüße
Peter

Hallo Harald,

Danke für deine Antwort.
Ich hatte es schon geahnt, weil viele Dinge sich ähneln.
Die Ethernet Bibliothek im CVreader ist im Moment noch eine Andere ..
Die kann ich mit "NetworkInterface::setup(ETHERNET, TCP, 8888); // UDP or TCP are possible" initialisieren
und gibt auch im Betrieb Antwort, allerdings ist hier das Standard Timeout drin, wenn keine Verbindung zustande kommt, steht das Init für 60 Sekunden.

Der grösste Fallstrick beim Ethernet Shield ist, dass die Datenleitungen SCK, MISO und MOSI ausschließlich vom ISP Pin Header abgegriffen werden.
Wenn wie bei mir aus Platzgründen das Motorshield unten verbaut ist, bekommt das Ethernet Shield kein Signal, daher müssen die Leitungen direkt verbunden werden. Bei mir nicht so gut zu sehen, wird aber vom eigenen Shield von Oben auf den ISP-Header gebracht.

Die überall umherschwirrenden Ardiuno Throttles werden per Anleitung auf den Serial Port des USB mit aufgeklemmt, was ich als keine so gute Idee betrachte. Daher habe ich diese Verbindung als neues Objekt definiert und lasse es einzeln abfragen:

Definition:
DCCEXParser  serialParser;
DCCEXParser  throttleParser;

Setup:
Serial.begin(115200);
// serial throttle
Serial1.begin(115200);

Loop:
serialParser.loop(Serial);
throttleParser.loop(Serial1);

Viele Grüße, Franzi

Hallo  DCC++ Gemeinde

DCC++ Kenn ich schon. Ich benutze es zusammen mit Rocrail. Aber was ist DCC++EX ?
Gruß Leon

Da der Orginalauthor von DCC++ vom Internet verschwunden ist haben wir - also die Intressierten die sich gefunden haben - uns entschieden DCC++ neu (und hoffentlich mindestens genauso gut) zu machen. Das heisst jetzt DCC-EX.

Grüße,
Harald.

Wie ich schon in PM geschrieben habe wär es gut wenn sich jemand von Windigiped als Betatester melden würde wenn sie schon "DCC++" als unterstütztes System angeben. Weil die Entwicklung von DCC++ geht bei DCC-EX weiter. Da kann man dann auch mehr as 12 Loks und die Funktionen bekommen ein Refresh.

Wenn hier jemand mitliest der Intresse an oder Verbindung mit Windigiped hat dann gerne diese Info weitergeben.

Grüße,
Harald.

Hallo Harald,



Ich habe hier einen DCC++ zu Testzwecken liegen. Muß mich mal in DCC-EX einlesen und mal etwas mit spielen. Werde aber das Thema in Verbindung mit WDP an passender Stelle ansprechen.

Finde ich alle Infos hier im Vorgänger-Thread oder hast Du noch andere Quellen?

VG Sven Spiegelhauer

Es sollte eigentlich alles drin sein, sonst eben melden


Ist Opensource, alle Quellen da
Eine Neuerung ist das <#> Kommando wenn man wissen will wieviel Decoder im Refresh Platz haben.

Grüße,
Harald.

Es gibt seit neulich eine Branch "NetworkIntegration" im Git (von grbba), die könnte was für dich sein.

Grüße,
Harald.

Hallo,

Ich habe im Moment noch den Source vom CVReader weiter am Wickel.
Jetzt bin ich ersteinmal zufrieden.
Ich habe einen Handregler gebaut, der nun mit der Basistation eine BiDirektionale Kommunikation kann.
Soll bedeuten, der Handregler bekommt alle notwendigen Infos über Gleisspannung/Loks/Lok-Funktionen
Und wird auch beim Steuern der (gleichen) Lok von der APP aus upgedatet.
Leider kann die App die Änderungen an den Funktionen (noch) nicht.

@Harald: falls Ihr Interesse habt, schick ich dir den gesamten Source, ich mag das aber weder öffentlich hochladen, noch mag ich momentan am GIT mitarbeiten, für den Support Aufwand fehlt mir schlicht die Zeit

Als Kurz Info: ich habe den DCCEXParser erweitert, so dass mit dem Kommando "<G xx>" Daten angefordert werden können.

Der Handregler kann zB jede Funktion auch als Taster definieren, das bedeutet, die Funktion wird nach ca 1 Sekunde wieder automatisch abgeschaltet. (ich meine gesehen zu haben, dass sowas auch im DCC++ Ex begonnen wurde, dort habe ich aber noch nicht gesehen, wie man beim Übertragen der Funktion mitteilen kann, dass es Schalter/Taster ist)

Im Anhang ein paar meiner "Bauwerke"

Viele Grüße, Franzi

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

Hallo Ihr,
bin neu in DCC++ex und frage mich gerade, was der Unterschied
zwischen den "Select Base Station Types" der Installation:
- Base Station Extended
- Base Station Classic
- CommandStation Test
ist?
Gruß,
Chris

Ach ich nehme an im Installer. Alles was Base Station heisst ist veraltet und sollte nach dem Release am Monatsende verschwinden, so ist zumindest der Plan. Eigentlich sollte da CommandStation-EX Beta 3.0.0 stehen und wenn du CommandStation wählst solltest du das bekommen. Teste gerne mal den Installer, ich hoffe Dex (der den Installer betreut) hat da etwas nachgelegt dass es jetzt funktioniert. Sonst ohne Installer der Schritt-für-Schritt Anleitung folgen. Was die meisten da überlesen ist "copy config.example.h config.h", so komisch das wirkt, aber so isses.

Grüße,
Harald.

Ich weiss nicht inwieweit der CVReader die neusten Verbesserungen, vor allem Ringbuffer beim Lesen vom ESP drin hat. Ich empfehle deswegen die CommandStation-EX source wo alles vom CVReader was gut war kopiert wurde.


Ich würde mir das schon gern ansehen und da du von der Zeit redest wäre es am effektivsten wenn das irgendwo als git zugreifbar wäre, weil wenn du mir was gibst was kein git ist, dann ist das Erste was ich dann machen muss ist das zumindest auf meiner Festplatte mit git hantieren damit ich enigermaßen rationell vergleichen kann. Weil darin (Vergleich also) ist git allen anderen Methoden überlegen. Github nimmt man weil man faul ist. Support braucht man deswegen ja nicht machen. Natürlich kann man auch ein zip über ein git ziehen, ist aber umständlicher als ein git fork auf github. Ich weiss, am Anfang hab ich git auch am liebsten nur mit der Zange angefasst, aber glaub mir da kommt man dann schon rein.


Kann man bis jetzt im DCC-EX noch nicht. Welche Funktionen was sind kann EngineDriver (die App) von JMRI holen. Wie wir das exakt mit DCC-EX verquicken müssen wir noch näher überlegen weil das ist ja von der Lok abhängig. Bis jetzt haben wir a la Digitrax F2 als Momenttaster. So wer soll sich wo merken wie die Funktionen sich benehmen sollen? EngineDriver sendet z.B. nur "Taste runter" und "Taste rauf" im WiFiThrottle Protokoll. JMRI sendet Funktion an/aus im DCC++ Protokoll. Da ist noch was zu tun (nach diesem Release).

Grüße,
Harald.

Hallo Harald,

Ich hatte dir eine Nachricht geschickt, die scheint wohl nicht angekommen zu sein.
Ich habe meinen Handregler soweit am Laufen, einfache CV Programmierung auf dem Prog Gleis sowie POM scheinen zu funktionieren

Was im Moment nicht geht: Alle Devices (USB, Serial Funk, Ethernet, WiFi) gleichzeitig fkt nicht.
Eventuell muss ich meinem Handregler mehr Zeit geben

Da es ja nun nichts besonders Geheimnisvolles ist, setz ich meine Änderungen, die ich mit dem aktuellen Source nochmal probiert habe hier rein. @Alle Anderen, die keine Draht hierzu haben: einfach überlesen

Da mein Source am SVN hängt, will ich das nicht mt dem Git verquicken, keine Ahnung ob die durcheinander kommen, ich habe es nicht probiert.



Viele Grüße, Franzi

Hallo Harald oder andere DCC-ler,
habe heute DCC++EX ans laufen bekommen. Echt genial, konnte mit meiner Lok schön fahren. Dankeschön an alle Entwickler, die sich da eingebracht haben!!!!

Eine Sache konnte ich jetzt noch nicht lösen. Um bei meiner Lok mit Sound zu fahren muss ich dauernd F1 drücken (in exwebthrottle mit mit "Bell" bezeichnet). Wenn man die Taste loslässt, geht dann blöderweise der Sound aus. Kann man die Einstellung wie ein Schalter irgendwie fixieren?
Gruß,
Chris

Ich glaube das ist ein Exwebthrottle Problem und kein DCC-EX Problem. Da Exwebthrottle nur Funktion/An-Aus an DCC-EX mitteilt kann DCC-EX gar nicht wissen was für eine Art vpn Knopf es ist. Kannst du EngineDriver ausprobieren? Dazu braucht man aber entweder für eine direkte Verbindung Wifi auf dem Arduino oder ein JMRI dazwischen. Bei der Direktverbindung sind alle Tasten außer F2 fixierende Schalte und nur F2 har eine "Feder". Bei der Verbindung über JMRI macht das alles JMRI mit Enginedriver aus über Einträge in der Fahrzeugliste. Alles klar oder noch mehr verwirrt?

Grüße,
Harald.

Doch ist angekommen, muss mich jetzt aber gerade erstmal um Sachen kümmern die im Release funktionieren sollten, z.B. dass die Leute die (leider) schon ein Pololu Motor Shield haben nicht im Regen stehen.

Ja, ich guck mir das noch näher an aber ich glaube die Veränderungen die du für



brauchst sind nicht ganz so einfach weil die Antwort richtig (an den Richtigen) zurückgegeben werden muss. Aber ich glaube auch für das haben sich Chris und Gregor was einfallen lassen, das ist aber in CommandStaton-EX branch NetworkIntegration glaube ich. Aber im Grunde braucht man meiner Meinung nach a bissel mehr als einen uCPU ohne OS, Displatch zwischen Handreglern auf verschiedenen Netzwerktechnologieen ist definitiv Zukuftsmusik, wenn es überhaupt geht. Also erstmal krabbeln, laufen. Fliegen kommt später.

Ich weiss dass svn->git geht aber ob git->svn->git zielführend ist glaube ich nicht. Rcs, cvs, hg (mercurial), svn, git: Ich glaube das ist jetzt alles was ich bis jetzt angewendet habe.

Grüße,
Harald.

Danke, mach bloß keine Hektik

Was bei mir auf jeden Fall funktioniert, wenn ich die EngineDriver APP nutze, bekommt mein eigener Handregler alle Änderungen der Lok (Speed, Direction, Functions) mit -> in die Gegenrichtung bekommt die APP auch Geschwindigkeit / Richtung mit.
Es gibt ja im Moment offiziell keine Möglichkeit die Funktionen aus der Zentrale abzufragen.

Was im Moment eben wenigstens parallel funktioniert, dass die Regler nicht gegeneinander arbeiten.
"Dispatch" funktioniert definitiv nicht, das wäre ja die Luxus Variante, um dem Regler mitzuteilen, ist schon in Benutzung

Nochmals: Vielen Dank an Alle für die Arbeit!

Viele Grüße, Franzi

Hallo Harald,
stimmt, liegt an der Exwebthrottle. Man kann dort über das Mapping einstellen, ob man einen Schalter oder Taster haben will. Das Feature ist also vorgehalten und mein Problem gelöst. Will aber eh auf Wifi umsatteln und über mein Smartphone steuern, wenn ich das hinbekomme. .
Hierfür brauche ich ein ESP-01s (z.B. https://www.amazon.de/AZDelivery-ESP8266-ESP-0...4319860&sr=8-4), oder gibt es ein passendes steckbares Shield hier in Deutschland (z.B. https://www.amazon.de/AZDelivery-Board-NodeMCU...320115&sr=8-10)?
Gruß,
Chris

Ich hab schon Shields mit WiFi gesehen aber noch nicht eins in der Kombination ESP-AT-Kommandos + Steckbar auf Mega + Preislich intressant in EU. Ich hab meine ESP01 von https://www.lawicel-shop.se/ da kosten sie so um die EUR5. Ich hab dann ein Bandkabel aus einem alten PC geschlachtet, das hatte schon die passende Buchse für den 8-pin Stecker des ESP01. Ein D1 Mini sollte sich auch mit der passenden Firmware flashen lassen (hat ja sogar USB) dann muss man aber RX/TX und Strom anlöten. Auch so in der Preislage. Hab ich aber noch nicht probiert, meine D1 sind in anderem Einsatz, Temperaturüberwachung in Aquarium und Gefrierschrank. Doch wahrscheinlich besser weil beim Flashen von einem ESP01 ist manchmal irgendwie der Hund drin wenn man sich nicht einen Flashadapter anschafft aber der kostet dann auch wieder extra.

https://www.reichelt.de/d1-mini-esp8266-v3-0-d1-mini-p253978.html

Edit: Das NodeMCU board (amazon link oben im vorigen Beitrag) sollte wie das D1 mini funktionieren. Da muss man aber auch RX/TX vom Shield mit Serial 1 RX/TX vom Arduino verbinden. Ich bin halt nicht Amazonkunde und bis jetzt auch noch nicht in Amazonland. In den USA wird das Makerfab shield verwendet https://www.makerfabs.com/esp8266-wifi-shield.html

Grüße,
Harald.

Hallo Chris,

DIe Anleitung für WiFi ist hier zu finden:
https://dcc-ex.com/start/wifi-setup/

Das Board, was du verlinkt hast, ist nicht geeignet
Es ist ein "Der AZ-Delivery D1 ist ein NodeMCU WiFi-Board basierend auf einem ESP-8266MOD-12F", kein Shield für einen Arduino

Wenn es nicht ganz so schnell gehen muss:
https://www.ebay.de/itm/Mega-WiFi-R3-ATmega2560...p2060353.m2749.l2649

Dort ist das WiFi Modul bereits auf dem Arduino Mega drauf

Da es etwas schwierig ist, die korrekten Einstellungen zu finden, ein Bild mit den Einstellungen im Anhang
Buttons 1 - 4 ON
Buttons 5 - 8 OFF
einzelner Schalter auf RX3/TX3


Viele Grüße, Franzi

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

Aber man könnte es doch mit der AT-Firmware flashen, oder?

Ich würde aber trotzdem eher das ESP-01 nehmen, mit etwas Glück ist die Firmware modern genug und man braucht nicht flashen.
Wobei was ich auf meinen ESP-01 bekommen hab war Methusalem.

Grüße,
Harald.

Ja na klar, auf den Meisten ESPs ist die Firmware auch schon drauf.
Bei dem Board besteht das Problem darin, dass der ESP als "Main Board" angeschlossen ist und sämtliche Pins auf den Steckern aufgelegt sind.
Wenn man es möchte, dann lieber ein Prototype Shield kaufen und Alles selber auflöten.
Das Stecken habe ich schnell seinlassen, es gibt massiv Wackelkontakte

Uno oder auch Mega Prototype Shield:
https://www.ebay.de/itm/Prototyp-Shield-V3-Mit-...0:g:5iQAAOSw0fFZhF74

Gibt es natürlich auch zu höherem Preis in D


Viele Grüße, Franzi

Stimmt, da muss man vor dem Aufstecken 1. überlegen und 2. umbiegen oder abknipsen.

Grüße,
Harald.

Hallo,
danke für die Antworten.

Warum geht das Board nicht https://www.amazon.de/AZDelivery-Board-NodeMCU...p;tag=webcom0524-21. Es ist doch ein ESP8266, allerdings in 12F Ausführung. Das Pinning habe ich gerade überfolgen und scheint dem Mega zu gleichen. Sorry für meine Fragen, aber ich bin noch rech neu in der Arduino ESP Welt.


Verstehe ich es richtig, das D1 Mini ist quasi ein ESP-01 nur mit USB-Anschluss und lässt sich somit besser Updaten wenn nötig?

Habe auch gerade die Wifi Anleitung überflogen, und da steht ja gar nichts, dass man auf das ESP-01 etwas draufzuladen hat. Das ESP-01 braucht man nur anzuschließen, korrekt?
Gruß,
Chris

Ja, aber wenn man zwei aktive Output Pins zusammenschließt dann ist das vielleicht nicht so dolle. Auch sollten Pins wie RX mit TX und umgekehrt angeschlossen werden.


Sollte so sein. Ich hab meine aber nicht mit der AT firmware benützt sondern was anderes draufgeschrieben. Leider hab ich vor dem Überschreiben nicht nachgeguckt ob die AT firmware und in welcher Version drauf war und jetzt isses zu spät.



Die meisten (alle? wer kann das wissen?) ESP-01 kommen mit irgendeiner Version der AT firmware.

Wie alle uCPU macht auch ein ESP-01 ohne irgendeine Firmware nix.

Grüße,
Harald.

Hab ich glatt übersehen. Rx/Tx sollte ja kreuzweise angeschlossen werden.
Hab jetzt diese ESP's bestellt:
https://www.amazon.de/AZDelivery-NodeMCU-ESP826...604565846&sr=8-3
Danke nochmal!
Gruß
Chris

Ich bin gerade superfrustriert. Da klont Velleman das "standard" Arduinoshield mit dem "Standardchip" und sie schaffen es sogar die Wärmeabführung anzulöten (was viele Chinesen nicht schaffen) aber dann haben sie die Komponenten für den Stromfühler einfach weggelassen.

https://www.velleman.eu/images/products/0/ka03-5.jpg
https://www.velleman.eu/downloads/0/illustrated...mbly_manual_ka03.pdf

Also für unsere Zwecke unbrauchbar

Grüße,
Harald.

Moin,

Das ist ja echt Bescheiden ...

Das Einzige, was mir zum Thema einfällt wäre OpenDCC, die ja einen Booster mit BiDi (RailCom) entwickelt haben.
Ob das brauchbar wäre kann ich so nicht beurteilen.
https://www.opendcc.de/elektronik/booster2/booster2.html
Es scheint nicht so ganz trivial zu sein, die Austastlücke korrekt zu erzeugen.

Viele Grüße, Franzi

Eine simple Austastlücke bekomme ich auch mit einem Uno und einem Standardshield hin, aber das Auslesen der keinen RailCom-Ströme ist etwas mehr "tricky", vor allem wenn es nicht nur funktionieren soll sondern auch standardkonform gemacht werden soll. Da braucht man dann sowohl eine MosFet Endstufe und einen sensiblen Stromfühler. Mal sehen was aus Daves neuster Idee wird: Eine Hardware der man über i2c sagt was für ein DCC Paket raus soll und wo auch alles andere drin ist was man braucht.

Oder man muss sich ein eigenen Shield stricken. Ich bin aber kein HW-Designer, also HW-Designer bitte vorreten.
Und ich hab gerade das mit dem Guard Interval auf der OpenDCC Seite gelesen. Super, muss man sich merken, wichtig.

Grüße,
Harald.

Hallo Harald,

Wenn man bei Standard Kompenenten bleiben will (was in meinen Augen sinnvoll ist), aber Railcom einbauen möchte, benötigt man denke ich zumindest zusätzliche Hardware für die Rückantwort. Bisher habe ich mich mit der Technik noch nicht befasst, finde es aber interessant. Ich denke mal, man benötigt sowas in der Art wie diesen Schnüffel:
https://www.opendcc.de/elektronik/dcc_sniffer/dcc_sniffer.html
Bestimmt auch hilfreich beim Entwickeln der Software mit LED oder Display ausgerüstet, um die Rückmeldungen zu verifizieren.

Ich bin auch der Meinung, es auf Standard Boards, wie Arduino oder ESP zu entwickeln. Das spart enormen Aufwand Platinen zu entwickeln.
Kleinere Zusatzschaltungen sind ja recht fix testweise auch auf Lochraster gebaut.

Viele Grüße, Franzi

Hallo,

jedenfalls muss die Motorbrücke "Brake Mode" können, das geht nicht bei jeder. Die Brücke muss die Railcom Austastlücke erzeugen können, indem ein Kurzschluss zwischen den Schienen erzeugt wird. Dann lässt der Decoder einen Strom fließen.

Auswertung siehe:
http://www.hoerndlein.de/cms/index.php/railcom-und-arduino

Grüße, Peter W

Moin,

Der Sketch funktioniert nicht wirklich, gibt dazu eine Diskussion im Stummi Forum
irgendwo aus diesem Thread heraus hatte ich was gefunden:
https://www.stummiforum.de/viewtopic.php?f=21&a...7c0c773&start=25

für DCC++ wäre es wohl sinnvoll, falls der Break Mode verfügbar ist, das CutOut Signal auch dem auswertenden Board mitzuteilen, damit spart man sich erheblichen Aufwand die Antwort aus dem Datenstrom zu filtern
Also auf einem GPIO Pin der Zentrale den Zeitpunkt des CutOuts verfügbar machen

Viele Grüße, Franzi

Eine RailCom-Lücke hab ich schon mal mit meinem modifizierten alten DCC++ erzeugt. Das Problem ist die Motorshield Hardware.

* Standardshield: Hat Brake aber einen hohen internen Spannungsabfall, also nach Standard nicht geeignet.

* Pololu: Geht ohne Modifikation immer in den Brake Modus beim Abschalten außer wenn man das Boad modifiziert. Der eingebaute Stromfühler ist für RailCom ungeeignet.

Bei externen Stromfühlern hab ich mehrere Designs gesehen. Welches ist eigentlich das Beste? Ich bin nicht so der Hardwaretyp.



Ja, für die Fehlersuche mit dem Oszi will man das sowieso. Bei DCC++EX das sich bei der Generierung des DCC Signals
von Classic unterscheidet gibt es nach meiner Meinung 2 Methoden den RailCom Cutout in DCC++EX zu timen:

1. Man verdoppelt die Interruptfreqeunz des Timers den man sowieso für DCC anwendet. Das DCC Signal in DCC++EX wird
    so generiert dass der Timer bei jeder möglichen DCC-Flanke feuert und man dann entscheidet wo in der Welle man gerade
    ist und je nachdem die Polarität umschaltet (Ende eines Bits) oder nix macht (Mitte eines 0-Bits).

2. Man nimmt einen extra Timer den man an der richtigen Stelle der Präambel setzt.

Ein Uno hat keinen Extratimer übrig denk ich, Also Methode 2 ist also nur für Mega, aber trotzdem bin ich für Methode 2 weil man sonst sehr viel Resourcen verschwendet.

Ihr könnt ja schon mal Tüfteln ob ihr einen GPIO zur richtigen Zeit feuern könnt, vor dem Release von DCC++EX komm ich nicht dazu.

Grüße,
Harald.

Da ich kein Anwalt bin und mir auch keinen leisten will: Nicht alle Software die man im Internet so findet kann man auch für DCC++EX verwenden. Die muss nämlich die richtige Lizenz haben, sonst darf man dann das Resultat nicht unter die Leute bringen. Und so wischi-waschi "you may use this but not make money" und was es da alles gibt ist leider nicht gut genug. So, wenn ihr was bei DCC++EX einbringt dann ist das zwingend GPL (für den genauen Text siehe die GPL des Projekts). Da muss man konsequent sein. Was man leider nicht über alle Software die ich zum Thema DCC im Netz gefunden habe sagen kann. Also ich meine dass alle Teile Lizenzen haben die sich nicht widersprechen. Ist ja ein Unterschied ob ich das für meine Moba verwende oder ob ich das in ein Projekt einbringe. Ich hab keine Lust dass mir (oder jemand anderem) dann in X Jahren Probleme gemacht werden.

Grüße,
Harald.

Guten Morgen,

Ich versuche das Ganze auch erst zu verstehen ...

Man benötigt 2 Dinge: Zum Einen den "Sender", der den CutOut erzeugt.
Zum Anderen den Detector, der die Antwort auswertet.

Nun meine Fragen dazu:
Wenn mehrere Booster betrieben werden, wer ist für den CutOut zuständig?
Die Zentrale? Es müssen die Booster ja irgendwie zeitgleich den CutOut erzeugen (war ja oben im OpenDCC Link schon Thema)

Zum Anderen: Wer wertet die Rückgaben aus und wie werden diese zur Zentrale zurückgesendet?

Im Moment haben wir die Zentrale mit integriertem Booster (MotorShield)

und es kann in diesem Zusammenhang der Rückweg in der Zentrale ausgewertet werden. Mit mehreren Boostern klappt das aber nicht mehr.

Hier ist eine etwas detailiertere Erklärung zu einem Railcom Detector:
https://www.rmweb.co.uk/community/index.php?/topic/123719-handmade-railcom/

Dieser Schaltvorschlag ist auch im Dokument der NMRA in ähnlicher Weise vorhanden:
https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf

Nach dieser Lektüre ist für mich die Folgerung für Railcom mindestens einen Arduino Mega zu nutzen.
dort könnte man das Signal der Detector Schaltung über einen echten Serial Port einlesen.
Wobei ich mir nicht sicher bin, ob es hinzubekommen ist, die vielen zeitkritischen Dinge im Griff zu behalten.

Irgendwann ist mit Interrupts und Timern auch ein Punkt erreicht, der nicht mehr zu handeln ist.

Wenn man bei den Standard Motorshields bleiben möchte, benötigt man wahrscheinlich auch einen Railcom Generator, der dem Motorshield nachgeschaltet wird.

Ob das nun Alles so korrekt ist, weiss ich nicht, ist so meine Vorstellung von der Sache.

Viele Grüße, Franzi

Jeder Booster oder integrieter Booster muss einerseits einen Cutout erzeugen (am besten ungefähr gleichzeitig aber kleine Variationen sind OK wenn man an den Enden des Cutouts kurz (OpenDCC: 4us) ausschaltet) andererseits einen so kleinen Innenwiderstand haben dass der Detektor der ja in Serie liegt immer noch funktioniert. Der Booster kan das "wann" entweder selber ausrechnen oder von der Zentrale die alle Zeiten des Signals weiss mitgeteilt bekommen.

Wo die Antwort vom Detektor oder den Detektoren dann hin soll und wieviel Bandbreite dafür gebraucht wird ist wieder eine andere Frage.

Grüße,
Harald.

Hallo,

irgendwann ist halt mit den Standard Motorshields Schluss. Ich verstehe sowieso nicht, warum da immer das gleiche mit dem alten L298 produziert wird. Aber es gibt auch Break Out Boards mit MOS Motortreibern am Markt, die das vielleicht beherrschen.

Zum Detektor: Es wird unterschieden zwischen einem Global Detector (in Zentrale/Booster eingebaut) und einem Local Detector, der an beliebiger Stelle in die Anlage eingebaut werden kann, z.B. Lenz LS120 Anzeige oder Uhlenbrock Marco Empfänger. Steht die Lok im Bereich des lokalen Detektors, ist vermutlich nicht garantiert dass der globale Detektor noch etwas empfängt.

Grüße, Peter W

Sind die nicht beide im gleichen Stromkreis?
Grüße,
Harald.

Hallo,

Ich habe mir meine Gedanken zu Railcom (Standard, ohne Plus) gemacht:
Alle vorhandenen Decoder auf dem gleichen Gleisabschnitt antworten beim Erkennen des Cutout Signals.
eigentlich ist das doch schon nicht auswertbar, wenn mehr als ein Decoder zur gleichen Zeit Daten sendet?

Das bedeutet - für mich - es kann von einem RC Detector auch nur genau ein Decoder gelesen werden.

Daher auch der Aufbau, den ich nun öfter gesehen habe, den RC Detector jeweils im GBM für einen Gleisabschnitt unterzubringen.

Zum Anderen würden wahrscheinlich? mehrere Detectoren hintereinander auch nichts mehr auswerten, es kommen ja nur minimale Spannungen zurück, die dann irgendwann mal "vernichtet" sind.

Die Plus Variante muss, was ich bei OpenDCC gelesen habe, lizensiert werden ..
https://www.opendcc.de/info/railcom/railcom.html

Also die einfache Variante würde zumindest pro Gleisabschnitt einen Detector benötigen.
Hmm .. korrigiert mich, wenn ich völlig daneben liege ..

Viele Grüße, Franzi

Hallo,

es gibt einen Unterschied zwischen RC Broadcast Daten in Kanal 1 und anderen Daten, die adressbezogen beantwortet werden z.B. CV PoM Read etc. in Kanal 2.

Sonst wäre ja ein Global Detector sinnlos.

Grüße, Peter W

Jo, deshalb ja die Frage .. für das Projekt müsste dafür aber eine Lizenz beantragt werden.
Kanal2 ist die Lizenzpflichtige Erweiterung, die man zu Hause für sich selber nutzen kann, aber eben nicht in solch einem Projekt.

Viele Grüße, Franzi

Hmm, gilt das auch wenn man das eh selbst compilieren muss? Ich kann gerne mal bei den DCC Granden nachfragen.

Grüße, Peter W

Die Frage ist welchen Schutz RailComPlus hat und ob dieser Schutz auch kompatible Implementationen eines Protokolls in Open Source verbietet. Das muss man dann sich genau ansehen. Es gibt aus dem Computerumfeld Parallelen z.B. bei der Implementarion von File Sharing Protokollen. Da gibt es ja auch große Firmen die gerne viele Rechte bei sich behalten.

Grüße,
Harald.

Vielleicht gibt es da ein Missverständnis was Railcom+ überhaupt ist. Diverse Kanal 2 Daten wie Verbrauchsinfornationen, PoM CV Read usw. sind doch Teil der öffentlichen Norm (RCN/NMRA). Das kann nicht geschützt sein.
IMHO ist RailcomPlus das automatische Anmelden.

Grüße, Peter W

Ich will jetzt hier kein juristisches Fass aufmachen aber auch öffentliche Informationen können von bestimmter Anwendung geschützt sein, siehe Patent. Wenn ich das mal laienhaft ausdrücke, ich bin ja kein Anwalt: Ein Patent schützt ja dass jemand anderer mit meiner Erfindung Geld verdient. Es schützt aber nicht die Anwendung der Idee. Dann gibts noch den Schutz der Marke und eingetragenes Wahrenzeichen und was auch immer. Ich habe aber noch keine Regelung gefunden die es verbietet die Baupläne oder Programme zu veröffentlichen, wie man RailCom oder auch RailComPlus auswertet und anwendet. Ich habe auch nicht vor einen Detektor zu verkaufen. Es ist auch intressant wie erst der Mangel an guten Produkten (und da meine ich nicht mal die Preisfrage) diese Entwicklung erst ermöglicht hat.




Leider steht die Patentnummer nicht daneben. So wenn die jemand weiss, her damit.

Eventuelle geschützte Bezeichnungen im Text gehören natürlich den respektiven Firmen.

Grüße,
Harald.

Folks!
AFAIK hat Lenz die RailCom Patente nicht verlängert, das Warenzeichen ist meiner Info nach weiterhin registriert.

Die Lok Anmeldung ist eine Erweiterung, eine Anwendung, von RC, das bedeutet das "Plus" dabei. Da gibt es mehrere Ansätze. Da man nicht alleine auf der Welt ist muß auch auf Befindlichkeiten Rücksicht genommen werden, das verzögert eben. Dazu zählt die Anzahl der Bytes eines DCC Pakets. Wäre schön wenn man beim anmelden mehr Platz hätte. Es gibt eine Reihe von Decodern die abstürzen bei längeren DCC Paketen. Klar verletzt das bereits uralte DCC Normen, dennoch wäre es nicht gut viele Decoder damit zu bricken. Das betrifft vor allem den USA Bereich. Ein Europa, hat soviel ich weiß, keinen solchen Unfug auf den Markt gebracht.

Da gibt's derzeit Diskussionen und daher ist eine Norm zur Anmeldung von Decodern noch nicht verabschiedet. RailCom Plus ist nicht freigegeben. Es wird aufgrund von Mängeln wohl auch nicht mehr weiter verfolgt werden, wiewohl derzeit das einzig benutzbare Verfahren.

Zur Frage Kanal 1/2. Kanal 1 ist ein Broadcast Kanal, da sendet jeder Decoder seine Adresse, außer das wird abgeschaltet. Die laufen natürlich ineinander wenn da mehrere am gleichen Empfänger ankommen. Da gibt's aber Verfahren um das zu trennen. Kanal 2 wird nur gesendet wenn der Decoder gefragt wird. Daher kann man diese Daten auch mit Detectoren im Bosster/Zentrale leicht auseinander halten. Es gibt die Erwartung mit diesen globalen Detectoren volles RailCom zu erhalten. Leider nein, damit bekommt man bestenfalls 25%. Dieses nicht akzeptieren der RC Konzepte führt zu viel Frust bei Anwendern.

Für RC im Vollausbau zur Benutzung braucht man auf jedem Abschnitt einen RC Leser. Ja natürlich sind auch Teilimplementierungen möglich. Da das heutzutage nicht viel kostet (niedrige einstellige Eurobeträge) sind Besetztmelder die auch RC lokal lesen kein Thema. Das Problem ist was macht man mit der Info? Wohin senden. In diesem Forum wurde oft argumentiert daß man keine leistungsfähigen Bussysteme braucht. Nun: das schließt auch RailCom aus. Egal wie lustig S88, LocoNet oder X-Press Net auch sein mögen. Da nur wenige BiDiB oder CAN Bus nutzen dauert es. ZIMO hat mit dem StEin Modul was Schönes geschaffen >€600,- für 8 Abschnitte sind wohl auch nicht wirklich praktikabel. Das wissen alle außer ZIMO. Es gibt aber Alternativen und es werden mehr.
-AH-

@All:

Danke für die Infos.

Das bestätigt mich eigentlich in meinem Denken:
Als Erstes gibts irgendwie kein einheitliches Vorgehen, was man benötigt und wie man einen möglichst störungsfreien Betrieb hinbekommt.
Dieses Mysterium die Zentrale "kann" RC ist nicht so besonders hilfreich.

Die RC Informationen, ob nun nur Kanal 1 oder auch Kanal 2 müssen ja irgendwohin zurück, um verarbeitet zu werden.

Mene Gedanken für DCC++:
Wenn man RC integrieren möchte, dann wahrscheinlich erst einmal die Grundfunktionen, mit dem Gedanken daran, wie man die Rückmeldung mehrerer Sensoren/Detectoren organisieren möchte.

Ich werde mal, dem Spieltrieb folgend, versuchen einen Detector auf Arduino Basis zu bauen, mal sehen was dabei herauskommt ..

Viele Grüße, Franzi

Schon mal gespannt

AH: Das mit dem Rückmeldebus wird sich lösen (mit oder ohne Einmischung der Moba-Industrie).

Grüße,
Harald.

Hallo Harald,

Ich habe jetzt erstmal eine Bestellung bei Reichelt aufgegeben .. ich habe Conrad vor der Nase, kann es abholen, aber der Laden ist ja immer noch teurer als Andere ...
Ich habe vor mich an der Schaltung der NMRA zu versuchen.
https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf

dort wird ja am Ende ein Signal erzeugt, das am UART des Arduino (auch ESP) direkt verarbeitet werden kann.
Mal schauen, was dabei rauskommt.

Inzwischen habe ich meinen Handregler von allen Delays im Source befreit, ich denke, dadurch bekomme ich die Rückmeldungen von der Zentrale besser ausgewertet. CV lesen/schreiben funktioniert inzwischen recht zuverlässig.
POM fkt auch ..
feines Spielzeug


Viele Grüße, Franzi

Moin,

Ein kleiner Tipp für den Betrieb des Ethernet Shields W5100:
Falls es beim Start des Arduino mit dem Shield zu Problemen kommt:
- z.B. bleibt das Init hängen und der Arduino startet sein eigentliches Programm nicht:
zwischen den Pins RESET und GND einen Widerstand 200Ohm in Reihe zu einem Elko (220µF Minus an GND) schalten.
damit wird der Start des Arduino leicht verzögert, dass das Ethernet Shield genügend Zeit hat, um sich zu initialisieren.

Infos zB von Hier:
https://chrisramsay.co.uk/posts/2015/08/some-f.../#a-working-solution

Bei mir tritt das Problem nur am Mega WiFi auf und konnte auf die Art behoben werden.
Ich habe nur einen Kondensator von 100µF verbaut, etwas Anderes war gerade nicht in Reichweite

Viele Grüße, Franzi

Hallo Ihr,
bekomme mit dem letzten Stand (v2.3) des Installers folgenden Fehler (siehe Bild). Versuche es morgen dann noch mal mit der Arduinoinstallationsvariante,
Gruß,
Chris

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

Sieht aus als findet der Installer eine Bibliothek nicht, aber vielleicht wird gerade die je nach Shield(s) gar nicht gebraucht. Mal von Hand vom ArduinoIDE aus versuchen, ist robuster als der Installer (ich bin von dem Installer nicht so überzeugt wie ihr vielleicht raushört).

Grüße,
Harald.

Hallo Harald,

muss ich in der "config.example.h" die folgende WIFI Konfiguration lassen, wenn ich direkt über AP (und nicht über mein lokales W-lan) auf zugreifen will:

// The IP port to talk to a WIFI or Ethernet shield.
//
#define IP_PORT 2560

/////////////////////////////////////////////////////////////////////////////////////
//
// NOTE: Only supported on Arduino Mega
// Set to false if you not even want it on the Arduino Mega
//
#define ENABLE_WIFI true

/////////////////////////////////////////////////////////////////////////////////////
//
// DEFINE WiFi Parameters (only in effect if WIFI is on)
//
#define WIFI_SSID "Your network name"
#define WIFI_PASSWORD "Your network passwd"
#define WIFI_HOSTNAME "dccex"

/////////////////////////////////////////////////////////////////////////////////////

Gruß,
Chris

Hallo Harald,
die Frage oben sollte sich erledigt haben, hab auf der DCC++ex Webseite gelesen, dass man keine Änderungen machen muss.
Allerdings funzt mein Wlan-Zugang über die Nomode MCU immer noch nicht.
Habe Tx/Rx und Gnd und 3,3V an die NomodMCU angelegt. Den Chipselect CH_PD brauche ich ja vermutlich bei der NodeMCU nicht, oder?
Das Terminal gibt mir dann folgendes aus:

DCC++ EX v3.0.0
++ Wifi Setup Try 1 ++

Wifi Check: [+IPD]
TIMEOUT after 200ms

Wifi Check: [rnOKrn]
TIMEOUT after 200ms

++ Wifi Setup NO AT ++

++ Wifi Setup Try 2 ++

Wifi Check: [+IPD]
TIMEOUT after 200ms

Wifi Check: [rnOKrn]
TIMEOUT after 200ms

++ Wifi Setup NO AT ++

++ Wifi Setup Try 3 ++

Wifi Check: [+IPD]
TIMEOUT after 200ms

Wifi Check: [rnOKrn]
TIMEOUT after 200ms

++ Wifi Setup NO AT ++
<iDCC-EX V-3.0.0 / MEGA / STANDARD_MOTOR_SHIELD G-9db6d36>

LCD1:Ready

Auch als AP-Name finde ich kein DCCEX_xxxx Wlan sondern nur FaryLink_xxxx.
Hast Du eine Idee was schief geht? U.U. ist die Firmware auf der NodeMCU ja auch fehlerhaft und interpretiert die Befehle zum Aufbau des Wlan AP vom AT-Mega nicht richtig.
Gruß,
Chris

NO AT  bedeutet keine Antwort auf AT über Serial, warum auch immer.

Z.B.

1. Shield nicht an
2. Falscher Anschluss Rx/Tx (das muss vom Shield Rx/Tx zum Arduino Tx/Rx Serial 1, 2 oder 3. Also über Kreuz)
3. Falsche Baudrate

Kannst du mit dem Shield wenn du es direkt anschliesst über Serie kommunizieren? Also wenn du "AT" sagst, kommt dann ein OK zurück?


Dann ist das Shiled wahrscheinlich an aber noch in Fabrikseinstellung.

Grüsse,
Harald.

Hallo Harald,
Meinst du das Shield über USB an den PC und in der Arduinoplattform "AT" über das Terminal senden?

Hab das jetzt probiert.
AT liefert nichts, aber der LUA Interpreter scheint irgendwie zu gehen. Kenn mich da aber nicht aus.
Angehängt findest Du einen Screenshot des Terminals mit verschiedenen Befehlen.
Gruß,
Chris

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

Ich glaub auf deinem WifiShield ist eine Software drauf die gar nicht die AT-Kommandos versteht wie z.B. die ESP-01 boards sondern die LUA Variante.

So, wie bekommen wir jetzt das das richtige draufgeflasht?

Siehe auch: https://robertoostenveld.nl/esp8266-at-firmware/

Sollte ja gehen, ich hab meine ESP-01 schon mit esptool.py geflashed. Und die hatten kein USB :-/

Grüße,
Harald.

Moin,

Da ich mich auch mit der AT Firmware beschäftigen musste, meine Aufzeichnungen dazu:

Links, von denen ich meine Infos bekam:
https://www.az-delivery.de/blogs/azdelivery-blo...date-fur-esp8266-01s
http://stefanfrings.de/esp8266/#fwupdate

Hier sind die offiziellen Downloads:
https://www.espressif.com/en/products/hardware/esp8266ex/resources

-> welche Firmware funktioniert, kann man nur ausprobieren ..
für mich haben hauptsächlich
ESP8266_AT_Bin_V1.6.2_0 oder ESP8266_AT_Bin_V1.7
funktioniert


Meine Aufzeichnung, dass ich es auch in nem halben Jahr wieder hinbekomme:


Download Adressen für Tool und Firmware:
---------------------------------------------------------

https://www.espressif.com/en/products/hardware/esp8266ex/resources
https://github.com/espressif/ESP8266_AT

Nach unten Scrollen, unter dem Punkt "Tools" das Flash Tool herunterladen:
- Flash Download Tools (ESP8266 & ESP32 & ESP32-S2)

unter dem Punkt "AT"
- die benötigte Firmware herunterladen


AT Firmware Version auslesen:
-----------------------------------------

in seriellem Terminal Verbindung mit 115200 Baud
AT+GMR

senden


Flash Tools
---------------

entpacken und starten
- "Developer Mode" auswählen
- danach das passende Tool -> ESP8266 Download Tool
- unten den COM Port einstellen
- START um den korrekten Chip zu ermitteln
  -> unter DETECTED INFO stehen die ermittelten Werte
     in Flash Size wird der ermittelt Flash Speicher eingetragen

- die gewünschte Firmware entpacken
  
- im Ordner xxx\ESPxxxVxxx\bin\at
  die Datei readme.md öffnen
  Hier sind die benötigten Informationen zu finden, welches Stück Firmware an welche Adresse geflasht werden muss

- mit diesen Werten oben die verschiedenen Teile der Firmware
  und die Startadressen eintragen

- Den Vorgang mit START beginnen
  -> bei Adapterboards mit Flash Taster den Flash Taster gedrückt halten
  -> jedes Teil einzeln senden


Viele Grüße, Franzi

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

Hallo,
danke euch für die Hilfe. Es ist wirklich etwas steinig den ESP8266 ans laufen zu kriegen. Infos hierzu sind ganz schön verstreut. Dachte wenn ich eine SDK Firmware flashe, funktioniert auch die serielle Schnittstelle. Man muss also eine spezielle AT Firmware flashen und dann auch eine spezielle Version. Mache mich dann mal ans Werk und werde berichten ,
Gruß,
Chris

Nja, die Schnittstelle funktioniert schon, doch leider die falsche Sprache sozusagen

Am Anfang wurden die ESP-Dinger immer mit AT-Firmware ausgeliefert. Deswegen viel die Wahl auch auf die weil
eigentlich will man dem Anwender das Flashen ja nicht antun. Inzwischen gibts aber da:



Da die AT-Firmware etwas beschränkt ist müssen wir vielleicht in Zukunft was anderes auf den ESP flashen. Aber das ist bis jetzt noch Zukuftsmusik für DCC++EX sagen wir mal so 3.2. Jetzt und heute gilt für DCC++EX die AT-Firmware. Welche spielt da keine so große Rolle (DCC++EX versucht sich da anzupassen) aber wenn man schon beim Flashen ist kann man auch gleich 1.7.4 nehmen.

https://www.espressif.com/sites/default/files/ap/ESP8266_NonOS_AT_Bin_V1.7.4.zip

Ich hab daraus den boot_v1.7.bin und den user1.1024.new.2.bin genommen weil mein ESP ist 1024 groß (also klein).
Dann noch die Initdaten aus esp_init_data_default_v08.bin

Das dann an folgende Plätze im Speicher geflasht:

Falls es nicht funktioniert kann auch noch der falsche "Flash-mode" schuld sein. Bei mir musste ich da "DOUT" einstellen.

Achja, die neusten Firmwares können sich vielleicht selber über WiFi  aus dem Internet updaten ("OTA") aber das klappt natürlich nur wenn es
die Adresse von der das ESP sich selber updaten will noch im Internet existiert. Das war bei mir nicht der Fall.

Grüße,
Harald.

Hallo Ihr,
habe jetzt das W-lan am Laufen. Und kann DCC++EX kabellos mit Engine Driver steuern.
Das Problem war wirklich das Flashen der richtigen Firmware auf die NodeMCU.
Hab aktuell die Teile aus der NONOS_SDK3.0 so geflasht, wie Franzi in seinem Anhang gezeigt hat.
Dann hatte ich noch Probleme mit der Verkabelung, GND muss an der Arduino Mega auch verbunden werden. Aber nun ist alles schick.
Nächste Baustelle wäre das Programmieren des Decoders auf dem Programmiergleis.

Viele Grüße,
Chris

Fein.

Während die anderen im Team gerade Release Notes für 3.0.0 schreiben bin ich gerade dran die Diagroutinen für ACK beim Programmieren noch etwas auszubauen. Falls man mal wieder einen Decoder hat der die Norm etwas großzügig auslegt.

Grüße,
Harald.

Moin,

Das ist cool zu Hören...
Franzi kommt von Franziska (auch im Profil zu finden) ... DANKE  ...

Viele Grüße, Franzi

Moin,

Ansonsten habe ich gerade ein Stück weit meinen Handregler insofern erweitert, dass er mir die Decoder Infos ausliest und anzeigt.
Mit dem besseren ACK klingt cool .. vor allem beim Auslesen der ESU Decoder lauf ich ab und an in einen Lesefehler :)

Für die SD-Card Bibliothek musste ich dann aber einen Arduino Mega einbauen, der Nano hat dafür etwas zu wenig Speicher.

Viele Grüße, Franzi

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

Hallo,

das ist Mega

Interessant dass Esu abweicht. Habe mit keiner kommerziellen Zentrale Probleme beim Auslesen von Esu.

Falls eine/r von Euch eine Piko Soundlok habt, bitte checkt mal den Unterschied beim ACK Timing zwischen Fahrdecoder-CVs und Susi-CVs.

Grüße, Peter W

Auf Serial kann man
<D ACK ON>
<R 8>
Dann bekommt man cv8 mit Diagnose ausgelesen.
Wenn was nicht geht dann hab ich gern den Output.

Grüße,
Harald.

Hallo,

Ich bin mir gar nicht so sicher, ob die Lesefehler von der Software stammen ...
Zum Einen habe ich so einige Modelle, die nach einem Jahr in der Verpackung einen sanften Druck benötigen um überhaupt wieder zu antworten.
Zum Anderen:
Die Art, wie die Decoder Infos gelesen werden trägt dazu bestimmt auch bei ..
Bei ESU: Es müssen erst 2 Register geschrieben werden und anschließend müssen 6 CVs ausgelesen werden um Typ und Build Number zu ermitteln. Bei jedem Vorgang ruckelt sich die Lok auf dem Gleis entlang. Wenn dort nicht 100% Kontakt vorhanden ist, gibts halt einen Lesefehler.

Gibt es eigentlich noch andere Hersteller außer ESU, die solchen "Zirkus" veranstalten, nur um den Decodertyp herauszufinden?

Ich habe Decoder von D&H, ESU, Zimo und irgendwo noch einen alten MTX
im Moment versuche ich auch um Piko Decoder einen Bogen zu machen, es ist schon echt heftig, für jeden Hersteller einen eigenen Programmer/Updater zu kaufen. Es geht ja nicht nur darum ein paar CVs zu programmieren, sondern bei Bedarf die Firmware zu aktualisieren und Soundprojekte auf den Decoder zu bringen.

Viele Grüße, Franzi

Hallo,

naja ich denke bei allen komplexeren muss man in eine CV Bank schalten, um an die Hersteller/Decoder spezifischen Infos zu kommen.
Die Banking CVs kannst ja auch per PoM schreiben.

Grüße, Peter W

Hm naja ... da es gerade um DCC++ geht .. POM MainTrack -> Fahrgleis, CV Lesen/Schreiben -> Programmiergleis

Da macht POM irgendwie keinen Sinn ...

Es ist soweit! Lang genug wurde ja dran rumgedrückt aber jetzt ist endlich die erste offizielle Version von DCC-EX gelandet. Aus historischen Gründen heisst die Version 3.0.0 (das ist größer als alle offiziellen DCC++ Versionen) und ich denke nicht dass ein ein Magenplatscher wird. Da ich die letzten Veränderungen am Code gemacht hab vor dem Release bin ich trotzdem etwas nervös. Wir auch immer, ein Zurück gibts jetzt nimmer:

https://github.com/DCC-EX/CommandStation-EX/releases/tag/v3.0.0-Prod

Eine Homepage gibts natürlich auch https://dcc-ex.com/ und für das allererste Release gar nicht mal so schlecht wenn ich das man so sagen darf. Am wackeligsten auf den Beinen steht meiner Meinung nach der Installer, aber den braucht Mann/Frau ja nicht, so ich würde den einfach bleiben lassen und nach der händischen Anleitung verfahren. config.example.h auf config.h kopieren nicht vergessen. Sonst nur Arduino IDE und alle ZIP-Dateien runterladen, klicken, fertig. https://dcc-ex.com/get-started/arduino-ide.html Support gibts in erster Linie auf Discord (Standardsprache zwar englisch aber keiner wird sauer wenn man mit einer anderen Sprache daherkommt). Aber ihr wisst ja dass ich hier auch helfe, nur auf Discord gibts halt noch mehr als mich.

Und die Ideen was alles in 3.1 drin sein sollte sprudeln schon.

Grüße,
Harald.

Hallo Harald,

leider für einen Anfänger mit großen Schwierigkeiten und Problemen möglich.

Gruß

Peter

Also dann beschreib doch mal wo die großen Schwierigkeiten liegen. Es gibt github issues und es gibt den Discord #support Channel. Da haben wir schon einiges gelöst. Ich kenne Leute die haben große Schwierigkeiten beim Entpacken von einer ZIP-Datei. Andere haben Probleme einen Motorshield auf einen Arduino aufzustecken, andere finden nicht den richtigen COM. Wieder andere haben Pech mit der "Qualität" die man manchmal bei den Komponenten untergeschoben bekommt. Wie gesagt war DCC-EX bis jetzt "Beta" und auch ein erstes Release wird nicht perfekt sein. Dass der Installer nicht 100% bulletproof ist - kann ich nix machen (Ich mag weder Installer noch Windows) .Doch haben wir durch Betatests vor dem Release schon einige Fehler gefunden und ausgemerzt. So mit so 15 registrierten Testern ist es ist nicht nur "Test beim Anwender". Wieviele Tester hat eine Komerzielle Zentrale und da hat man immer die gleiche Hardware, so es ist einfacher.

Wenn man DCC-EX mit anderer Software zusammen anwendet, dann kann es natürlich dazu kommen dass etwas nicht kompatibel ist. Ein Beispiel sind die Geschwindigkeitsstufen im <t> Kommando. RocRail war der Meinung das ist 0 bis 127 mit 1=Notstopp so wie bei DCC auf dem Gleis. Ist es aber nicht. Es ist im DCC++ Kommando eben -1 bis 126 mit  -1 = Notstopp. Wenn es irgendwelche Fragen dazu gibt kann man uns ja ansprechen. Ich finde es fein wenn DCC-EX von vielen anderen Softwarepaketen unterstützt wird. Es ist aber jetzt nicht die Verantwortung von uns zu nachzusehen ob das jetzt i dem Release auch noch mit aller Software der Fall ist. Wir kennen ja nicht mal alles. Die Tests inkludieren z.Z. zwei Open Source Softwares: JMRI und EngineDriver.

Grüße,
Harald.

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

Hallo,

nach dem einbinden der .zip Datei in IDE, gehe ich über -> öffnen zur CommanStation-EX.ino und öffne diese.
Hier werden aber nur 2 Dateien #include angezeigt.

Auch bekomme ich ungültige Bibliothek angezeigt.

Auch der Installer, der vieles "erleichtern" soll, bringt hier leider gar nichts.

Wenn ich nach der händischen Anleitung vorgehe, komme ich auch nicht zum Ziel.

Da stehe ich doch mächtig auf dem Schlauch.

Gruß

Peter

Hallo,

Hast du denn überhaupt die Anleitung gelesen?

Wenn es mit englisch nicht klappt, kann man sich die Seite übersetzen lassen
https://www.translatetheweb.com/?ref=TVert&...d%2Farduino-ide.html

Das *.zip File lässt sich nicht "einbinden"
Die Datei entpacken und in dem Ordner die *.ino entweder doppelt anklicken, oder über den öffnen Dialog auswählen.

Grüße, Franzi

Hallo,

naja, ich weiß ja nicht ob Du die richtige Übersetzung gelesen hast? Oder ob das mit Englisch bei Dir so klappt?

Natürlich lässt sich eine .zip Bibliothek in IDE einbinden. Klappt problemlos.
Nachdem öffnen der .ino Datei, wird man gefragt ob die Datei in einen eigenen Sketch Ordner verschoben und gespeichert werden soll..

Grüße   Peter

Moin,

dann probiere weiter erfolglos vor dich hin ...

Viele Grüße, Franzi

Moin,

wenn Du nichts konkretes zu der Frage beitragen kannst oder willst, warum schreibst Du dann hier?

Außerdem war das nicht meine frage, sondern was im nächsten Schritt mit den ganzen andren .h Dateien passiert?
Kann das ganze zwar hochladen, aber es funktioniert nicht wirklich.

Gruß

Peter

Ich glaube, ich bin DIR keine Rechenschaft schuldig, ob ich hier schreiben darf ...

Hallo,

Ich habe die Anpassungen v3.0 bei mir direkt eingefügt.
Es funktioniert bisher echt gut.
Das WiFi wird wirklich schneller initialisiert, hat was gebracht.

Bei meinem Aufbau ist oben noch ein StepDown Regler dazugekommen, dass ich nur ein Netzteil für das Motorshield benötige.
Die Spannung für den Arduino wird auf 7 Volt heruntergeregelt und über Vin eingespeist.

@Harald:
Ich bin zwar mit GIT immer noch am Üben, habe aber im Moment alles aktuell, bei Neugierde auch den Throttle
... interessanterweise kann man mit den HC-12 Modulen auch mehrere auf einmal betreiben.
Im Moment habe ich zwei Regler, die ihre Aufgabe erfüllen.

p.s.: Die Lok steht irgendwie mehr schlecht als Recht auf dem Programmiergleis .. fürs Foto

Viele Grüße,
Franzi

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

Die von Franzi gezeigte automatische Übersetzung der Anleitung ist ja überraschend (erschreckend?) gut. Da wir es so wie beschrieben ausprobiert haben empfehle ich dass man am Anfang es so macht und keine "Abkürzungen" nimmt. Wenn man alles an einer Stelle entpackt und dazu die beschriebenen Bibliotheken installiert dann kommt die Arduio IDE damit eigentlich zurecht und kann daraus was kompilieren und hochladen. Wenn nicht dann bitte doch eine Beschreibung wie lang es ging und welche Fehlermitteilung dann auftrat.


Meine Glaskugel funktioniert aber leider auch nicht.

Grüße,
Harald.

Alles vom ZIP muss in den Sketchordner, sonst wird das nix.

Problem ist folgendes, nach dem Download heisst der Ordner aus dem ZIP CommandStation-EX-3.0.0-Prod
Darin liegt ein CommandStation-EX.ino

Da wird dann das Arduino IDE rabiat und meint das darf nicht sein und macht einen _neuen_ Ordner CommandStation-EX mit _nur_ CommandStation-EX.ino drin. *FACEPALM*

Wenn man entweder alles aus CommandStation-EX-3.0.0-Prod ins CommandStation-EX verschiebt oder gleich CommandStation-EX-3.0.0-Prod in  CommandStation-EX umbenennt dann gehts auf Anhieb. Das Arduino IDE will Foo mit Foo.ino drin haben, basta (und alle anderen Dateien auch in Foo).

Und jetzt hab ich einen "neuen" ZIP gemacht ohne Version im Namen, der sollte das Problem nicht haben, also den nehmen.

https://github.com/DCC-EX/CommandStation-EX/files/5611333/CommandStation-EX.zip

Grüße,
Harald.

Naja, das mit der Übersetzung, mag ja gut funktionieren. Aber es nützt mir wenig, wenn das nicht drin steht, was ich suche um das Problem zu lösen.

Wenn ich das jetzt richtig verstanden habe, müssen die entsprechenden Bibliotheken aus der langen Liste der .h Dateien, zusätzlich in IDE eingebunden werden. Damit es dann hoffentlich funktioniert.

Alles was unter -> Bibliotheken einbinden  -> Beigetragen Bibliotheken -> CommandStationEX  #include  aufgelistet ist?

Grüße
Peter

Hallo,
nun habe ich mir auch mal diesen Sketch gestartet. Nach einigen anfänglichen Problemen habe ich es schon mal soweit gebracht, dass die IDE damit startet. Aus derzeitigem Mangel eines Mega2560 habe ich die Compilierung nur in "Überprüfen" versucht. Endet leider mit der Fehlermeldung: exit status 1
'class EthernetClass' has no member named 'hardwareStatus'
Sämtliche entpackte Dateien aus der Zip sind im gleichen Ordner wie die Ino. Datei. Config.h habe ich auch umbenannt. Wo liegt der Fehler?
Hatte die DCC++ Version schon am Laufen. Doch diese scheint immer nur ein DCC- Kommando in ihrem Loop zu haben, also die anderen vorher aktiven Lokadressen nach Adresswechsel nicht mehr zu wiederholen. Ist dies in dieser EX anders gelöst?
Gruß Holger

Das hört sich falsch an. CommandStation-EX ist das Hauptprojekt und keine eingebundene Bibliothek. So falls ComandStationEX als Bibliothek erscheint muss das da wieder raus.

Die Bibliotheken die eingebunden werden müssen sind DIO2 und dann haben wir scheinbar noch Mist gebaut weil ich glaube auch Ethernet wird benötigt auch wenn es dann nicht angewendet wird. Also im Library Manager sowohl DIO2 als auch Ethernet installieren. So gehts wenn keiner der Entewickler oder Tester mit einer _leeren_ Umgebung testet. Ich glaube da muss ein "hotfix" her damit man nicht mit Ethernet rumtun muss wenn man gar keines hat...



Das sollte aus Ethernet Bibliothek kommen. Was ich hier installiert habe hat ganz klar in der Datei
Ethernet.cpp ein "EthernetHardwareStatus EthernetClass::hardwareStatus()"



Also ich hab schon DCC++ (Classic) mit mehr als einer Lok im Loop gehabt aber das ist Schnee von gestern da das intern in DCC-EX ganz ganz anders gelöst ist. Jetzt gibt es sowohl alle Lokadressen als auch alle Funktionen bis F28 im Loop.

Ich kümmer mich mal um Ethernet.h und melde mich dann wieder.

Grüße,
Harald.

Hall Harald,
Danke für die Mühen! Ich finde es super, was hier von allen Beteiligten geleistet wird! Hut ab!
Sobald ich wieder aus meiner Reha zurück bin, werde ich mit DCC-EX weiter testen. Allerdings nutze ich einen Funkhandregler per HC12 Modul drahtlos.
Gruß Holger

Ich hab mal schnell was zusammengekocht:
https://github.com/DCC-EX/CommandStation-EX/archive/ethernetdefine.zip
Das entpackt sich als CommandStation-EX-ethernetdefine.  Muss man dann umbenennen in CommandStation-EX und sich den config.h nochmal einrichten aber dann probiert mal, das sollte ohne die Ethernet Bibliothek gehen.

Grüße,
Harald.

Hallo Harald,
das ging ja flott! Habs gleich mal probiert und: Alles gut! Zumindest im "Überprüfen".

Der Sketch verwendet 35606 Bytes (14%) des Programmspeicherplatzes. Das Maximum sind 253952 Bytes.
Globale Variablen verwenden 1718 Bytes (20%) des dynamischen Speichers, 6474 Bytes für lokale Variablen verbleiben. Das Maximum sind 8192 Bytes.

Hochladen dann, wenn ich wieder zu Hause bin

Hi,
bin Anfang 2018 auf "digital" gewechselt und habe dann recht bald nach einem Ersatz für die CS2 (miniTrix) gesucht und bin dann auf DCC++ gestossen. Ich fahre bis heute mit dem "original" und das fahren auf dem "Main-Track"war nie ein Problem! Anders sah das beim programmieren auf dem "Prog-Track" aus, da hatte ich oft Probleme das z.B. ein Decoder nicht erkannt wurde.
Mit DCC-Ex gehört das nun der Vergangenheit an (jedenfalls bei mir...) sogar der Piko-Sounddecoder
wird sauber gelesen und geschrieben. Deshalb mal an dieser Stelle ein ganz großes DANKE @haba
und an all die anderen, die dieses tolle Project jetzt in die Hand genommen haben
Man sollte jedoch immer bedenken, das es keine fertige "Plug&Play" Lösung ist. Auch wenn der neue
"Installer" das suggeriert. Das eigentliche Programm ist gerade mal knapp 100 KiB groß. das Installer-Zip umfasst 137 MiB, sicherlich ok für unbedarfte Windows-User, aber wie man an einigen Fragen hier erkennen kann, ist eine gewisse Grundkenntnis des Arduino Uno/Mega und der dazugehörigen IDE von Vorteil. Auf der neuen Webseite des Projects wird nicht umsonst expliziet darauf verwiesen
siehe hier: https://dcc-ex.com/get-started/arduino-ide.html
Ich freue mich jedenfalls sehr über diesen "Fork" und was mich sehr begeistert ist die einfache "WiFi" Anbindung, damit kann ich jetzt mal ganz ohne PC/JMRI einfach einige Runden drehen...

Also nochmal: Thank You und viel Spass beim weitermachen!

Gruß, Günter

Hallo, nachdem ich ja auch schon ein bisschen mit dem "alten" DCC++ herumgespielt habe und aus dieser Zeit ein eigen entworfener "Motorshield" stammt, wollte ich DCC-ex testen. Zunächst klappte das nicht. Ich musste dann in #motordrivers.h den Port von 12 auf 10 ändern, weil ich das hardwaremäßig bei meiner "Kreation" so fest hatte. Es wird dort auch nur der Atmega 328P stand allone verwendet. Sense über Operationsverstärker ist vorhanden, aber noch nicht getestet.
Funktioniert nun einwandfrei. Insbesondere hatte ich mit dem alten DCC++ das Problem, dass hier im Loop immer nur die letztgesendete Adresse bzw. Befehl war. Nun ist das offensichtlich behoben. In einer Testanwendung bei mir ist das explizit notwendig. Da bekommen die Loks von der Zentrale unabhängig zwischendurch von einem anderen Modul nach je nach Anlagensituation andere Geschwindigkeiten bzw. Halt im Broadcastformat gesendet. Wenn sie dann wieder die normalen Digitalsignale empfangen und nicht ihr Befehl dabei ist, passiert nichts-->Stillstand. Mit DCC Ex gelöst!
Bedient wird derzeit mittels eines funkangebundenen Hanbedienteils. Damit ist CV-Auslesen bzw. programmieren (noch) nicht möglich. Daher auch kein Test diesbezüglich.
Danke nochmal an Harald und alle anderen! Noch schöne Feiertage!
Gruß Holger

Die Idee ist dass du in config.h einen eigenen Namen definierst (MY_MOTOR_SHIELD) wo dann die Pins so sind wie du es haben willst. Dann auch im confg.h #define MOTOR_SHIELD_TYPE MY_MOTOR_SHIELD. So brauchst du im Motordrivers.h nix ändern und beim nächsten Update bist du fein raus weil alles immer noch funktioniert (sofern wir nicht den Define grundlegend anders machen).


Kurzschlussschutz würde ich empfehlen, auch brauchst du Sense zum CV-Lesen. Ich empfehle Ackdiag <D ACK ON> beim Einstellen von Sense, der Output entällt den Wert am ADC (0 bis 1023) vor dem "/" und in mA umgerechnet danach.



Ist alles neu geschrieben, vom alten Code *räusper* ist da nix mehr drin. Hat als Nebeneffekt dass man jetzt, obwohl auch noch  die Funktionstasten im Refresh sind, insgesamt weniger RAM pro Lok im Refresh verbraucht als vorher. Beim Uno ist das definitiv ein Argument, beim Mega braucht man sich nicht so anstrengen. Aber wir wollen dass es zumindest in der Grundfunktionalität auch auf dem Uno funktioniert weil viele eben noch einen Uno rumliegen haben den man dann anweden kann.


Grundlegende Tests kann du vom Terminal aus machen.
Read: <R cv x x>
Write: <W cv wert x x>
(die beiden x sind beliebige Ziffern wegen Kompabilität mit altem DCC++)

Grüße,
Harald.

Hallo zusammen,

inzwischen habe ich ein wenig mit DCC++ rumgespielt. Die Ergebnisse mit dem Installer und über die Arduino IDE unterscheiden sich doch recht deutlich:

Über den Installer meldet sich mein Arduino auf dem 20x4 Display als v3.0.3 und zeigt mir die vorgegebene IP auch an - zumindest teilweise, weil das Display trotz 20 Spalten nur 16 anzeigt. Bei Systemstart ist das Programmiergleis immer an, das kann ich auch nicht ausschalten.

Mit der IDE wird mir v3.0.0 angezeigt, die IP wird verschwiegen. Dafür sind beim Systemstart beide Gleisausgänge aus und lassen sich dann in JMRI wie gewünscht schalten. Ob das Display hier komplett angesprochen wird kann ich nicht sagen, dafür sind die angezeigten Infos zu kurz.

Nutzbar ist das Ganze nur wirklich nach Installation über die IDE, da auf dem Allways.On-Programmiergleis die Loks immer gleich anfahren - da scheint tatsächlich irgendein interpretierbares Signal rauszukommen.

Eine Verbindung von JMRI auf die Command Station ist aber nur über USB möglich - bei Netzwerkverbindung kommt immer eine Fehlermeldung beim Programmstart. Wenn ich über den Installer installiert habe, kann ich aber mein Netzwerkshield anpingen, dann antwortet es; Wenn ich über die IDE installiere, ist das Netzwershield irgendwie tot oder zumindest stumm. Da das Fahren und Programmieren aber wichtiger ist, kann ich erst mal mit der USB-Verbindung leben; irgendwann wird das Netzwerk schon laufen

Jetzt fehlt eigentlich nur noch der Handregler - zum Programmieren ist der PC daneben ja ideal, aber zum Fahren fehlt da einfach das richtige Feeling. Aber da bin ich noch zuversichtlich, dass hier irgendwann noch was nachkommt - Franzi hat ja gezeigt dass es geht (und WAS so ein Handregler alles kann!).


LG - Tom

Also wenn du schon über das IDE unterwegs bist kannst du auch gleich deinen config.h von Hand so anpassen wie du willst. Ich finde dann ist der Installer mehr im Weg als das er bringt. Guck dir dazu den config.example.h an und übernehme was du brauchst ins config.h (*).

Zu den Versionen: Seit heute Nacht ist die aktuelle Version 3.0.4 mit github sha ID 7706e65 online. Lade dir die mal runter bevor du weiter mit 3.0.0 oder 3.0.3 Fehler findest die wir schon gelöst haben.

Zum Display sag ich mal: Da haben die Leute sehr verschiedene Displays und es ist schwer es allen recht zu machen. Auch muss man bedenken dass ein Display update von den cycles her recht aufwendig ist. Auch da ist 3.0.4 sparsamer geworden. Ich glaube es ist sehr schwer da eine fertig packetierte Lösung anzubieten, sondern da muss man mit etwas Programmieren selber ran wenn man mehr haben will. Aber solche Sachen wie Kurzschlussmeldung auf dem Display sind schon angedacht aber noch nicht implementiert.

Grüße,
Harald.

(*) Siehe http://dcc-ex.com/ web.

Hallo Harald,

die config.h hab ich natürlich angepasst bei den Versuchen über die IDE. Die ist ja auch ausführlich kommentiert und damit selbsterklärend. Nur wird per IDE die IP nicht angezeigt, daher weiß ich nicht ob das Display wirklich als 20x4 angesprochen wird oder nur mit 16 Spalten und 2 Zeilen.

Als IP habe ich auch mehrere versucht - zuerst eine die in mein Netzwerk passt, und nachdem das nicht funktioniert hat auch mal die in JMRI voreingestellte. Aber das war alles erfolglos, ich konnte die DCC-EX weder aus JMRI ansprechen noch in meinem Router als aktives Gerät sehen - nur anpingen ging...

Sei's drum, ich teste mal die v3.0.4 an und werde berichten!


LG - Tom

Versuchs zuerst mit 3.0.4 und dann sehn wir weiter, da sollte dann auch die WiFi IP angezeigt werden. Wenn du das USB angesteckt hast, dann ist da beim Start auch Info zu finden welche IP gewählt wurde.

> Als IP habe ich auch mehrere versucht

Also IP wählen im config.h geht nur für Ethernet, nicht für ESP-Wifi. Aber warum denn nicht DHCP?

Wenn anpingen geht dann solle es auch auf den _einen_ Port antworten. Mehr kann das kleine Teil nämlich nicht.

Grüße,
Harald.

DCC++EX 3.0.4 und 3.0.5 haben einen Bug der verhindert dass 5 Bytes große DCC Packets (u.a. PoM für lange Adressen) gesendet werden. Bitte das 3.0.6 (das gibt es seit kurzem auf github) downloaden und anwenden.

Grüße,
Harald.

Hallo Harald,

ich habe gerade mal die aktuelle v3.0.6 aufgespielt. Jetzt wird im Display ja plötzlich deutlich mehr angezeigt: Da laufen plötzlich freier Speicher, IP-Adresse und Port durch, gemeinsam mit der gewohnten Versionsnummer und dem Status ready - schöne Spielerei!

Das Display ist aber immer noch auf 16 Zeichen begrenzt, trotz Definition in der config.h als 20x4. Aber jetzt weiß ich auch warum: In der LCDDisplay.h ist eine Zeile

#define MAX_MSG_SIZE 16

die offensichtlich die Länge der ausgegebenen Nachrichten begrenzt. Wenn die definierte IP-Adresse mehr Zeichen hat (zusammen mir dem IP: davor) wird einfach abgeschnitten. Ich habe für mich das Ganze mal pragmatisch gelöst und den Wert auf 20 gesetzt, damit wird mein Display jetzt auch in voller Breite genutzt.

Mit DHCP holt sich die CommandStation eine IP ab, die auch korrekt angezeigt wird; jetzt finde ich sie auch in meinem Netzwerk. Aber mehr als anpingen geht leider noch nicht, zumindest weigert sich mein JMRI immer noch die CommandStation per Ethernet anzusprechen. Aber das ist eigentlich nur ein Schönheitsfehler, solange die USB-Verbindung funktioniert kann ich damit leben.


LG - Tom

Hallo Harald,

habe gerade die Version 3.0.6 aufgespielt.

Jetzt habe ich keine Ethernet Verbindung mehr.

IP Adresse ist geändert. // bei ENABLE_Ethernet ist entfernt.

Gibt es keine MAC Adresse mehr die ich anpassen kann?

Grüße
Peter

Hallo Peter,

was meinst du mit
?

Die IP kannst du angeben oder dir per DHCP geben lassen, der Rest heißt bei mir
#define ENABLE_ETHERNET true

Eine MAC-Adresse muss wohl nicht sein...Kann ja sowieso frei vergeben werden, daher ist der Gedanke der Einmaligkeit hinfällig

Hast du gar kei Ethernet mehr oder bekommst du nur keine Verbindung mit JMRI hin? Kannst du die Command Station anpingen?


LG - Tom

PS: Um Tante Edit zu schonen mache ich gleich mal den nächsten Faden auf, der ist ja schon wieder voll:
https://www.1zu160.net/scripte/forum/forum_show.php?id=1232970