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

Hallo,

ich habe einige "0815" Zubehördecoder, die NRMA-kompatibel sind (WDecN-TN)
siehe auch hier:
https://mobatron.4lima.de/2020/03/nmra-kompatibler-zubehoerdecoder
Diese Decoder werden über diverse CV-Parameter parametriert. Das habe ich, leider erfolglos, über JMRI --> neue Lok --> NMRA --> accessory Decoder versucht.
Hinter diesem Decoder scheint sich auch ein Lokdecoder zu verbergen, denn es gibt Reiter für Motor usw. und damit nicht geeignet um einen Funktionsdecoder zu bearbeiten.

Hat jemand eine Idee, wie das geht und ob überhaupt DCC Zubehördecoder parametrierbar sind?

Viele Grüße
Christian

Hallo Christian,

welche Version von JMRI benutzt Du denn?
Hier ein "Snapshot" aus der Version 5.5.7,
da gibt es unter ---> NMRA accesory decoders
keine Reiter für Motor!
Es gibt dort genau drei Reiter: "Lokparkeintrag", "Basis", "CV-Tabelle" , das ist alles!
Hat auch erstmal nichts mit DCC++ zu tun.
Falls Du das benutzt, wäre dann auch die Hardwarekonfiguration interessant

Gruß, Günter

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

Hallo Günter,

so etwas hätte ich erwartet. Offensichtlich mache ich da was falsch.

Ich habe Decoder Pro Version 5.6+R89a87446 eben noch einmal neu installiert und vorher alle backup gelöscht.
Bei mir sieht das Bild vollkommen anders aus. Erreicht über +neue Lok --> NMRA--> NMRA Accesserydecoders

siehe Bild.

Ups. Was mache ich falsch?

Viele Grüße
Christian

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

Lasst mich Mal wissen exakt welche DCC Befehle ihr meint.

Die meisten DCC Befehle sind in DCCEX implementiert aber nicht alle. Da kann man sich überlegen ob man die braucht und dann ob man sie in DCCEX implementiert oder ob man sie vom Computerprogramm aus als Hex Bytes schickt. Dazu müsste JMRI das können.

Wir implementieren gern neue nützliche DCC Befehle, ältere (14 Fahrstufen jemand?) eher nicht so gern, da darf der sie braucht gern selber ran. Ist ja open source.

Grüße,
Harald.

PS: Die anderen Entwickler hängen alle auf unserem Discord rum.

Hallo Günter,

hier noch die Hardwarekonfiguration

ARDUINO UNO
StandardMotorshield (Deek.Robot)

über USB vom UNO zum PC verbunden, dort läuft WIN11

Viele Grüße
Christian

Achja, JMRI 5.7.1 funzt nicht mit DCCEX über USB serial, da haben sie was verkorxt, ist schon bekannt. Geht aber lustigerweise über IP.

Grüße,
Harald.

Hallo Harald,

als Anlage ein Auszug aus dem Handbuch des Decoders WDecN-TN, entwickelt von Herrn Gerhard Clemens.

Ich glaube aber, dass ich zunächst ein  JMRI-Problem habe und ich überhaupt keinen NRMA-kompatiblen Zubehördecoder anwählen kann. Damit kommt natürlich auch ein falsches Protokoll zum Arduino.

Viele Grüße
Christian

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

Hallo Harald,

gibt es eine Version, die mit USB seriell funktioniert? Die JMRI Decoder Pro Bilder sind in 5.6 und 5.5.7 bei mir gleich falsch.

Deshalb glaube ich, dass das Problem vorm Monitor sitzt.

Viele Grüße
Christian

Also alle JMRI 5.5 und 5.6 haben Verbindung mit DCCEX, aber wenn JMRI mit der Art von Decoder nix anfangen kann dann bringt das nix.

Ich weiss nicht so viel über JMRI wie andere, vor allem in unserem Discord haben wir ein paar Experten.

Grüße,
Harald.

Hallo,

habe jetzt das Fenster so wie Christian, lag wohl an meinen Einstellungen,
so gesehen scheint also alles ok...

Die nächste Frage wäre jetzt mal, ob du irgendwelche CVs auslesen kannst,
also  zunächst ---> "Neue Lok"  und dann in diesem Fenster unten --->"Typ aus Decoder auslesen" drücken

Tut sich dann etwas?

Gruß,
Günter

... ach und noch etwas:
Welche Version von DCC-EX benutzt Du? Aktuell ist 5.0.0

Bis jetzt kann DCCEX noch nix mit den Kommandos für die Signalbilder. Da müsste man zuerst einmal festlegen as denn im DCCEX Protokoll an die Zentrale geschickt wird damit am anderen Ende solch DCC rauskommt.

Vorschläge?

Grüße,
Harald.

Hallo Günter,

ich habe DCC++Ex in Version 5.0.7 aufgespielt. Das Fensterthema hat sich aus meiner Sicht geklärt. Es gibt in den Voreinstellungen Lokpark-->Programmierer die Möglichkeit zu Abwahl leerer Reiter, das hatte ich vorher nicht gesehen.

Ich habe deine Aktivitäten versucht. Nach neue Lok --> Typ aus Decoder auslesen wird im Fenster unten links angezeigt "read MFG ID CV8", was ich auch erwartet habe. Die Proggleis- LED (Klemmen B) auf dem Motorshield bleiben aus. Es kommt also der Befehl nicht durch, aus meiner Sicht.

Weitere CV-Werte lassen sich nicht auslesen, da meldet sich "Programmer in use"

Harald,

der Decoder und DCC++ funktionieren, mit den Werkseinstellungen, wenn ich diese über iTrain ansteuere ohne Probleme. Man muss aber die Eigenschaften, wie sich der Decoder verhalten soll, in diversen CV eintragen. Natürlich auch die Adressen. Das möchte ich mit JMRI erreichen .

Mit freundlichem Gruß
Christian

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

Hallo Christian,
ich denke ich bin dann mal raus ...  
Falls Du noch weitere Versuche anstellen willst, es gibt im JMRI unter dem Register DCC++
den "DCC++ Trafic Monitor", evtl. liefert der Dir nützliche Informationen.

Gruß,
Günter

Hallo Günter,

ich bin schon lange raus und hoffe auf Harald und seine Freunde.

Vielen Dank trotzdem für deinen Versuch zur Unterstützung.

Mit freundlichem Gruß
Christian

Das Proggleis ist normal B.

Der Monitor zeigt an was los ist. CV lesen und schreiben sollte wie bei allen anderen Decodern auch gehen.

Man kann auch einzelne Kommandos im DCC Kommandofenster geben, z b. R 8.

Kann gerade nur begrenzt testen, da Urlaub.

Grüße ,
Harald.

Nachdem ich die Anleitung vom Decoder durchgelesen habe denk ich dass man den Decoder von MobaTrain CV für CV programmieren muss und dass "NMRA Accessory Decoder" von JMRI nix bringt. Es gibt da ja die Auswahl "Raw" für sowas.

Grüße,
Harald.

Hallo Harald,

ich wünsche einen schönen Urlaub.

Ich habe alle möglichen Varianten zu NMRA-Decodern (auch die RAW) getestet. Ohne Erfolg. Es erfolgt keine Rückmeldung.

Ich habe heute aber versucht einen Lokdecoder, den ich vor einiger Zeit mal auslas. Leider musste ich feststellen, dass das Auslesen eines Lokdecoders weder auf dem Hauptgleis noch auf dem Proggleis funktioniert (weder über JMRI noch iTrain). Das verblüfft mich. Kann das jemand probieren? Daraus kann ich schlussfolgern, ob auf meinem System irgendetwas nicht klappt,

Vielen Dank.

Auf dem Hauptgleis ist nix mit Auslesen.

Zuerst man rausfinden ob die Rückmeldung/Stromfühlung einen Huscher weg hat. Dazu braucht man den DCC++ Traffic Monitor und das DCC++ Kommandofenster von JMRI oder eben irgend ein Program für Serielle Kommunikaton (Arduino IDE, EX-Installer, PuTTY...). Ich mach das lieber mit einem normalen Seriellen Terminal weil da bin ich dann sicher dass sich JMRI nicht einmischt.

Kommandos sind z.B <1> (alle Gleise an) oder <R 8> (CV 8 auslesen) und im JMRI Kommandofenster kann man die <> weglassen.

Mein erster Test ist <1> und dann 1 Sekunde Kurzschluss auf MAIN und PROG und mal nachsehen ob der Kurzschluss im Monitor gemeldet wird. Wenn ja, dann ist zumindest der Stromfühler OK. Damit kann man auch rausbekommen welches Gleis welches ist (also PROG und MAIN). Das wird auch mit <=> angezeigt (seit DCCEX 5.0).

Mein zweiter Test wäre dann Lok aufs PROG Gleis und dann <D ACK ON><R 8> und das sollte einen ganzen Haufen Diagnostik erzeugen wo man sieht was passiert.

Dann mal herzeigen was die Diagnostik so ausspuckt.

Grüße,
Harald.

Ich wünsche Euch noch ein Frohes Neues Jahr !

DCC-EX unterstützt  eine Vielzahl von Pins als Input z.B. zur Verwendung als Belegtmelder.

Nun möchte ich gerne bei einem Wechsel von 0 auf 1  und von 1 auf 0 auf einem Input einen DCC-Befehl senden.

Pin X1 von 0 -> 1  = Weiche Y gerade
Pin X1 von 1  -> 0 = Weiche Y abzweigend

oder

Pin X2 = 1   ->  Lokfunktion Fx dauerhaft an, Pin Z = 0   ->  Lokfunktion Fx dauerhaft aus.

oder

Pin X3 von 0 -> 1 = DCC Befehl Funktion für xSekunden aktiv, dann wieder inaktiv (z.B. zum Abkuppeln)

Kann man so etwas heute schon Konfigurieren (event. über ExRail) oder wäre das etwas für eine zukünftige Weiterentwicklung von DCC-Ex? Was haltet ihr von solch einer Funktionalität?

Man könnte über ein paar einfache Taster, Schalter oder GBM  verschiedene DCC Funktionen aktivieren. (z.B. Bei allen Loks Licht an

Gruß Uli

Das kann EXRAIL.

https://dcc-ex.com/ex-rail/overview.html#gsc.tab=0

Aus dem Stehgreif:

AUTOSTART SEQUENCE(1)
AT(X1) //AT blockiert die Sequenz
IFTHROWN(Y) CLOSE(Y)
FOLLOW(1)

AUTOSTART SEQUENCE(2)
AT(-X1)
IFCLOSED(Y) THROW(Y)
FOLLOW(2)

Vielleicht solltem man noch ein DELAY reinstecken.
Man braucht keine Angst haben viele Sequenzen zu starten. Eine pro Sensor ist kein Problem. Die laufen alle pseudo-gleichzeitig.

Bei dem Beispiel mit der Lok... Immer die Frage: Welche Loknummer solls denn sein? Aber ja, man kann eine Loknummer in eine AUTOMATION geben und DANN wird die "abgefahren". Sollte man mit einem Knöpfchen in EngineDriver verknüpfen können. Aber frag den Chris im Discord, der ist der Experte für EXRAIL.

Bei allen Loks Licht an geht nicht so gut da EXRAIL sozusagen nicht weiss welche Loks es gibt.

Aber les dich mal ein. Vor allem die Beispiele. Man muss andersrum denken, aus Sicht der Lokführers.

Grüße,
Harald.

Harald, Vielen Dank für die Tipps. Jetzt weiß ich wie  ich einsteigen kann.

Nun muss ich erst mal eine Testumgebung aufbauen.

Viele Grüße Uli

Hallo Harald,

alles Gute zum neuen Jahr. Zurück vom Urlaub über Weihnachten und den Jahreswechsel habe ich wieder Zeit mich mit DCC++ zu beschäftigen.

Entsprechend deinem Rat habe ich mit dem JMRI Traffic-Monitor und SEND DCC beschäftigt und dabei unerwartetes festgestellt.

Hier die Ausgabe nach <1> und <=>
15:00:58.226: [1]  TX: Track Power ON Cmd
15:00:58.232: [* Track A sensOffset=0 *]   RX: DIAG: Track A sensOffset=0
15:00:58.235: [* Track B sensOffset=0 *]   RX: DIAG: Track B sensOffset=0
15:00:58.236: [p1 MAIN]   RX: Power Status: Name:MAIN Status:ON
15:00:58.238: [* LCD2:Power On MAIN *]   RX: DIAG: LCD2:Power On MAIN
15:01:18.911: [=]  TX: Request TrackManager Config: '='
15:01:18.911: [= A MAIN]   RX: TrackManager:= A MAIN
15:01:18.911: [= B MAIN]   RX: TrackManager:= B MAIN

Ich hätte in der letzten Zeile B PROG erwartet. Möglicherweise interpretiere ich das auch falsch.

Ebenfalls führte ich den Kurzschlusstest, wie empfohlen durch.
Hier das Ergebnis bei Kurzschluss auf B:

15:10:12.455: [* TRACK B ALERT  2223mA *]   RX: DIAG: TRACK B ALERT  2223mA
15:10:12.466: [* TRACK B CURRENT (100msec ignore) 2226mA *]   RX: DIAG: TRACK B CURRENT (100msec ignore) 2226mA
15:10:12.566: [* TRACK B POWER OVERLOAD 2226mA (max 1497mA) detected after  100msec. Pause   40msec *]   RX: DIAG: TRACK B POWER OVERLOAD 2226mA (max 1497mA) detected after  100msec. Pause   40msec
15:10:12.612: [* TRACK B POWER RESTORE (after   40msec) *]   RX: DIAG: TRACK B POWER RESTORE (after   40msec)

Das stimmt so nach meiner Meinung.

Bei Kurzschluss auf A passiert nichts im Monitor, auf der Motorplatine dunkeln sich aber die LED leicht ein.

Ist meine Platine im "Eimer" oder habe ich das noch etwas falsch eingestellt?

Eine weitere Frage habe ich noch zu den Befehlen. Ich habe noch keine Liste zu den Befehlen finden können, immer nur Beispiele. Über einen Hinweis wäre ich dankbar.

Viele Grüße
Christian

Hallo Christian,

suchst du so etwas?

https://github.com/DCC-EX/CommandStation-EX/wiki/DCC-EX-Command-Reference

VG Uli

Ich nehm auch gern die Ausgabe von Anfang an mit Version und Motorshield.


Hast du den Installer angewendet und da "kein PROG" oder so gewählt? Dann kann der Sketch der generiert wird kein PROG.
Ist das ein Uno?

Bei Kutzschluss sollte sowohl bei A als auch bei B eine Warnung erscheinen und das Gleis abgeschaltet werden.

Die Abschaltung wird gesteuert von der Spannung an A0 (für A) und A1 (für B) die bei Kurzschluss von nahe 0V auf so 4V oder so steigen sollte. Wenn das nicht geht wie es soll ist was am shield oder Arduino faul.

Die Analogeingänge kann man recht leicht versehentlich mit Spannung > 5V schrotten. Ja, ausprobiert. Wenn man einen Eingang oder Ausgang geschrottet hat kann man die Pins mit einer eigenen Definition des Motortreibers und ein paar Patchkabeln in Software und Hardware umlegen.

Beim Standardshield kann man A0-A2 und A1-A3 verbinden und dann kommt man in den Genuss von den Schutzdioden die bei A2 und A3 verbaut sind.

Grüße,
Harald.

Hallo Uli,

ja, genau das suchte ich. Ich habe auf der DCC++Ex Web-Seite gesucht und nicht im github. Danke.

Hallo Harald,

vielen Dank für deine Hinweise.
.
Ok, merke ich mir für das nächste Mal.


Ja.

Ja, habe ich. Aber ich kann mich nicht erinnern, ob es da eine Auswahlmöglichkeit gab. Das werde ich in den nächsten Tagen untersuchen. Ansonsten wiederhole ich die Ladeprozedur noch einmal, dann über die IDE.

Das Verhalten A0 werde ich mir ebenfalls in den nächsten Tagen ansehen. Falls A0 tot ist, beschäftige ich mich mit dem Umkonfigurieren der Analogein/-ausgänge.

Viele Grüße
Christian

Hallo Harald,

läuft es eigentlich auch auf dem Uno R4 mit onboard WLAN?

Grüße, Peter W

Hallo Peter (#27), lies hier:

https://dcc-ex.com/news/posts/20230728.html#gsc.tab=0

Hallo Harald,
Einfach eine Draht-Brücke zwischen A0-A2 und A1-A3? Gilt dies auch für andere Boards?

Ich habe folgende Motorshields:
a) Deek-Robot MOTOR SHIELD
b) DIY More L298NH Motor Shield
c) DCC-EX EX-MotorShield8874

V. Grüße Uli

Hallo,

ich habe versucht meine Problemchen in den Griff zu bekommen und bin einen Schritt weiter.

Ausgang : ARDUINO UNO, Deek-Robot Motor Shield

Ich benutzte den EX-Installer und stellte fest, dass im Fenster "Install Ex Station"  Track Manager ausgegraut ist und nicht zur Verfügung steht. Der Trackmanager lässt sich nicht aufrufen. Nach compilieren und laden findet man im DeviceMonitor:

<* License GPLv3 fsf.org (c) dcc-ex.com *>
<* NO HAL CONFIGURED! *>
<* Found PORTB pin 13 *>
<* Pin 15 Max 1497mA (501) *>
<* Found PORTB pin 12 *>
<* Pin 14 Max 1497mA (501) *>
<= A MAIN>
<= B MAIN>
<iDCC-EX V-5.0.7 / UNO / STANDARD_MOTOR_SHIELD G-3bddf4d>
<* LCD3:Ready *>
<p0>
<* LCD2:Power Off *>
<* LCD3:Free RAM=  491b *>

Beide Ausgänge des Motor Shield stehen auf MAIN.

Ich habe die gleiche Prozedur noch einmal wiederholt und einen MEGA 2560 benutzt.
Hier ist jetzt der TrackManager anwählbar und ich kann den Ausgängen A und B in gesonderten Fenster MAIN und PROG zuweisen. Im Device Monitor erhält man dann, die eigentlich von mir auch erwartete Eintragung für MAIN und PROG  für A und B
<* License GPLv3 fsf.org (c) dcc-ex.com *>
<* WARNING: Check I2C SCL line for short/pullup *>
<* No I2C Devices found *>
<* MCP23017 I2C:0x20 Device not detected *>
<* MCP23017 I2C:0x21 Device not detected *>
<* Found PORTB pin 13 *>
<* Pin 55 Max 1497mA (501) *>
<* Found PORTB pin 12 *>
<* Pin 54 Max 1497mA (501) *>
<= A MAIN>
<= B PROG>
<iDCC-EX V-5.0.7 / MEGA / STANDARD_MOTOR_SHIELD G-3bddf4d>
<* EXRAIL RoutCode at =FFFFCB54 *>
<* EXRAIL 24b, fl=256 *>
<* LCD3:Ready *>
<p0>
<* LCD2:Power Off *>
<* LCD3:Free RAM= 5203b *>
<= B PROG>
<= A MAIN>

Die Ausgänge lassen sich jetzt auch mit <1 MAIN> bzw <1 PROG> und entsprechend <0> bzw <1/0 JOIN> sauber schalten.

Es entsteht für mich die Schlussfolgerung, dass der UNO für PROG nicht konfigurierbar ist und keine Programmiermöglichkeit hat, jedenfalls nicht über den EX-Installer.

Im nächsten Schritt werde ich mich mit der Programmierung von Loks und meinem eigentlichem Problem, der Parametrierung von NMRA-Decodern widmen und die Ergebnisse berichten. Läuft das mit dem MEGA2560, werde ich versuchen den UNO über die IDE zu kompilieren und zu laden und testen, ob dort irgendwo eine Einstellung für PROG zu finden ist.

Viele Grüße
Christian

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

Hallo Uli (#28),

Danke für den Link. Schauen wir mal was die Zeit bringt, irgendwann wird man nicht drum herum kommen.
Einstweilen portiere ich erst einmal meinen eigenen DCC-Generator.

Grüße, Peter W.

Moin,

Ich kann es nicht nachvollziehen, warum um alles in der Welt steckt man seinen Ehrgeiz darein, unbedingt alle Module in den UNO zu quetschen?
Es reicht schon sich die Dokumentation zu DCC-EX durchzulesen, um festzustellen, dass man im UNO nicht unendlich Platz hat und demzufolge solche Module im Installer dann eben nicht auswählbar sind.
Selbst wenn du es selber noch so oft compilierst (VS Code ist im übrigen hilfreicher als die Arduino IDE) wirst du es nicht schaffen dies im UNO unterzubringen! - Der Vorhandene Speicher reicht irgendwann nicht mehr.
Wo ist das Problem statt eines UNO einen MEGA zu nutzen?

Viele Grüße, Franzi

Hallo Franzi,


Nirgendwo. Ich begann mit einem UNO und fand bisher nur Einschränkungen für WiFi und Ethernet. Ich fand bisher (zugegeben in lese nicht ständig und möglicherweise zu oberflächlich) keine Einschränkungen zum PROG-Betrieb. Wenn dem so ist, dann ist es auch gut. Meine Ausführungen dienen dazu, jedenfalls nach meiner Meinung, eine Klärung zu meinem Problem zu finden.

Viele Grüße
Christian

Zum Uno: Das alles im Uno unterzubringen ist knapp. Beim Compile steht ja am Schluss wieviel Platz angewendet wird, guckt es euch an. Es geht am meisten reinzupressen mit dem alten Arduino IDE 1.8.19 und dann auswählen im config.h (z.B. DISABLE_EEPROM) was man abschaltet wenn es nicht reicht. Das ist aber ein gefummel also hat der Author vom Installer da den konserativen Weg gewählt und als Default vielleicht etwas mehr abgeschaltet als nötig. Wenn man den Slider "Programmig Support" auf die andre Seite zieht sollte das aber gerade noch gehen. EEPROM und Programming Support gleichzeitig wahrscheinlich nicht. Den config.example.h durchlesen ist mein Tip für die Optimierer die am Uno festhalten.
Also die Info ist für die Version 5.0.7.



Zum Uno R4 Wifi: Das ist leider eine richtg bescheuerte Konstruktion. Zu wenig RAM und das Wifi über Serie angeschlossen (also ungefähr wie AT mit dem ESP8266), nicht mal via WifiNINA. Dann auch noch recht teuer. Nee, ich quetsch doch nicht die ganze Familie in die Weltklasse. setzt noch nen Schwiegermuttersarg drauf und dann fällt er um. Klar, ist auch ein Auto. Aber nicht für uns.


Wer Lust hat kann natürlich auch DCC-EX protieren und so dem Projekt beitragen, ich wüßte aber andere Baustellen die mehr Sinn machen (*). Das gleiche gilt übrgends für das Arduino Giga Dingens mit den 2 oder 3 (wie man jetzt zählt) CPUs. Da hat schon jemand portiert (unser Code is recht portabel) und dann haben wir festgestellt dass die Firmware auf dessen Ethernet nur maximal 3 TCP Verbindungen zulässt. Jubel! Beim der 4. WiThrottle App hat man dann die Supportcalls. Zum Vergleich: Mega+ESP8266: 5,  ESP32: 10.

Wenn ihr eine kompakte Zentrale mit Wifi wollt, nehmt einen ESPduino32 für 15 EUR (oder billiger) und lötet eien 300Ohm Widerstand drauf (das fixt einen HW bug).
https://dcc-ex.com/reference/hardware/microcont...32-espduino-32-board

Grüße,
Harald.

(*) Mehr Tester für das Ethernetshield, Entwicklung der Kombination Nucleo+ESP32 (WifiNINA),  Weiterentwicklung vom XpressNet Parser (so dass das mal ins Alphastadium kommt) u.s.w.

V5.0.7 auf UNO

Ich habe jetzt noch mal meinen UNO ausgegraben und die aktuelle Prod. Version installiert.
Mit dem DCC-EX Installer ist es mir nicht gelungen, bei Aktivierung des PROG-Modus kam die Meldung zu wenig Speicher. Mit der Arduino IDE 1.8.19 hat es dann geklappt. Nach der Deaktivierung der EEPROM Routinen habe ich noch Free RAM = 99 Byte. Bei den Versionen 4.1.x waren es ca. 500 Byte.

13:07:03.541 -> <* License GPLv3 fsf.org (c) dcc-ex.com *>
13:07:03.541 -> <* NO HAL CONFIGURED! *>
13:07:03.541 -> <* Found PORTB pin 13 *>
13:07:03.541 -> <* Pin 15 Max 1497mA (501) *>
13:07:03.541 -> <* Found PORTB pin 12 *>
13:07:03.541 -> <* Pin 14 Max 1497mA (501) *>
13:07:03.588 -> <= A MAIN>
13:07:03.588 -> <= B PROG>
13:07:03.588 -> <* I2C Device found at 0x27, GPIO Expander or LCD Display? *>
13:07:03.588 -> <* I2C clock speed set to 100000 Hz *>
13:07:03.588 -> <* 16x2 LCD configured on I2C:0x27 *>
13:07:03.682 -> <* LCD0:DCC-EX v5.0.7 *>
13:07:03.682 -> <* LCD1:Lic GPLv3 *>
13:07:03.728 -> <iDCC-EX V-5.0.7 / UNO / STANDARD_MOTOR_SHIELD G-3bddf4d>
13:07:03.728 -> <* LCD3:Ready *>
13:07:03.728 -> <p0>
13:07:03.728 -> <* LCD2:Power Off *>
13:07:03.728 -> <* LCD3:Free RAM=   99b *>

Du hast ein LCD steht da ... das braucht auch noch Speicherplatz.

Achtung: Daten im RAM und der Programmcode im Progmem sind auf AVR verschiedene Sachen.

Grüße,
Harald.

Hallo,

der AVR 328 ist für die Aufgabe schon etwas sehr klein.

Warum man sich sträubt mit dem Uno R4 zumindest Beta zu gehen ist mir noch nicht wirklich verständlich. Das Board kann man überall kaufen, ein Motorshield drauf stecken, fertig. Und das WLAN Modul ist auch schon drauf.
Als Vorteil sehe ich dass Vin jetzt bis 24 V möglich ist, weil jetzt ein Schaltregler drauf ist. Da kann man problemlos 18 V Startset Netzteil oder 19 V Laptop Netzteil anschließen ohne dass man die Platine himmelt und dann funktionieren auch die alten Motorshields mit der bipolaren Brücke problemlos - der Spannungsabfall ist dann auch wurscht.

Der Preis ist ja nicht wirklich ein Thema wenn man sich sowas einmal zulegt oder von mir aus 5x im Verein.

Grüße, Peter W

Jo, Peter, das Teil ist für das was es bringt zu teuer. Bei meinem Stammhändler kostet der R4Wifi SEK 369 und der ESPDUINO32 SEK 149. Der zweitere is billiger und funktioniert. Doch der Preis ist nicht der einzige Grund. Der ESP32 direkt ist auch schneller da sich die Netzwerkdaten nicht zwischen zwei CPUs durch ein Nadelöhr drücken müssen. Firmware von ESPRESSIF haben beide, so da ist man gleich aufgeschmissen, nur beim R4Wifi ist es halt hinter noch einer Extra-Firmware auf dem NetzwerkCPU versteckt.

Ich denke auch die Kinderkrankheiten der neuen "R4 USB Bridge" mit dem die neue Wififirmware auf dem ESP32-S3 angebunden wird darf sich gern jemand anderes antun. Beispiel: https://github.com/arduino/uno-r4-wifi-usb-bridge/pull/20 Ich versteh wirklich nicht warum die Leut von Arduino bei zwei CPUs die beide noch massig Pins übrig haben eine Verbindung über eine neue SERIELLE Schnittstelle (also nur 2 Pins) gewählt haben anstelle einfach wieder WifiNINA anzuwenden. Auch ist es ein ARM so dass man die Timer portieren müsste. Also wenn man sich neue CPUs antun will: Da gibts interresantere Chips.... RP-(2040)-PICO-W zum Beispiel. Außerdem läuft unser Kod schon auf STM32, wer soll das denn alles unterhalten?



Warum man vor allem beim Mega den ollen Linearregler nicht schon längst mit einem pinkompatiblen Schaltregler bis so 24V ersetzt hat weiss auch keiner. Wenn der dann abraucht (sogar bei erlaubten 12V in kommt da wegen der Verluste der Wärmetod recht früh wenn man nur die 5V etwas mehr belastet), dann ist Arduino nicht so die Premiummarke die sich im Preis von den Clones abhebt.

Klar, man möchte ein Laptop Netzteil nehmen (wenn das doppelte Quadrat drauf ist dann sogar abgesegnet) und mit dem EX-Motorshield das wir entwickelt haben geht das auch gut, weil das hat dann den Regler drauf. Das Standardshield macht sowieso wenn man in H0 oder noch größer unterwegs ist recht bald schlapp. Das EX-Shield, so populär es ist, kann man aber auch noch verbessern (einfacher, billiger, usw).  Ich schreib ja meistens Software aber unsere Hardwaregruppe ist schon wieder am Werkeln was man da noch machen könnte. Ich verrate es wenn es soweit ist.

Grüße,
Harald.

Hallo,

heute hatte ich nun endlich mal Zeit um das neu Shield "EX-MotorShield8874"
auszuprobieren, zusammen mit DCC-EX 5.0.7...
Wow ! Ich bin begeistert!
Per TrackManager den B-Ausgang von "Prog" auf "DC" geschaltet und
einwandfrei mit einer alten analogen Lok gefahren
digital gesteuert (via JMRI) - das ist einfach GENIAL.

Gruß,
Günter

Moin allerseits,

wenn man weder vor GIT noch vor dem ESP32 Angst hat, dann kann man ab heute die Branch devel-z21 runterladen, #define Z21_PROTOCOL im config.h anmachen und dann gleichzeitig mit der Z21 App mit sowohl Loks, Weichen und Sensoren kommunizieren. Die Weichen und Sensoren müssen in DCC-EX schon definiert sein. Das funktioniert zwar in meinen Tests, ist aber noch sehr im Beta, so es ist eine gute Idee sich auch im Discord anzumelden ( https://discord.gg/UWBuuWbP ) und sich den Kanal #beta-testers freischalten zu lassen. Über USB kommen auch jede Menge Mitteilungen die wenn was nicht funktioniert von Intresse sein können. Ich hab nicht die geringste Ahnung ob es mit der Wifi Multimaus auch funktioniert.

Aber wie gesagt, funktioniert nur mit dem ESP32 als CPU, nicht mit dem "normalen" Arduino.

Grüße,
Harald.

Kurzanleitung:
Loks:  In der Z21 einstellen mit DCC 128 Fahrstufen 1-127 kurz und 128-9999 lang
Weichen: In der Z21 auf die in DCC-EX mit <T...> definierte Weichenadresse stellen.
Sensoren: In der Z21 Uhl 63320 auswählen und beide Adressen auf die in DCC-EX mit <S....> definierte Sensoradresse stellen.

Sehr interessantes Projekt, leider habe ich gerade keinen ESP32 mit Motorschield zum Testen herumliegen und auch keine WLAN-MultiMaus.

Macht es Sinn für weitere DCC-EX Entwicklungen sich vom Arduino MEGA zu verabscheiden und auf den ESP32 zu wechseln oder wird es in naher Zukunft noch besser geeignete Hardware geben, die schon im Test ist ?

Die größte Spaßbremse beim Mega in der Hinsicht ist die Netzwerkanbindung die mit einem ESP8266 über AT doch sehr primitiv ausfällt. Z.B. kann so ein ESP8266 Rucksack nicht zwei Sachen gleichzeitig, also z.B. Withrottle über TCP und Z21 über UDP.

In naher Zukunft kommt ein neues Release, das beinhaltet dann alles was z.Z. im Devel zu finden ist. Mit den neuen Release kommt auch eine Liste von Hardware auf die wir und konzentrieren werden. Der ESP32-WROOM (aber nicht die anderen ESP32 Varianten) ist dabei. Auch wird eine Liste von STM32 CPUs dabei sein. STM32 mit Ethernet (also Kabel) ist zwar in der Entwicklung aber da muss noch mehr getan werden. Für STM32 und Wifi bräuchte man einen einfachen ESP32, da reicht auch der abgespeckte ESP32-C3.

Die einfachste Platform für mehr Funktionalität übers Netzwerk wird aber der ESP32-WROOM sein. So viel falsch machen kann man bei dem Preis doch eigentlich nicht, oder?

Grüße,
Harald.

Hallo in die Runde,
ich habe auch durch Zufall die DCC Ex gefunden und mit ESP32 und Motorschield eine Zentrale aufgebaut. Mit Engine Driver lassen sich die Lok's super fahren. Die Einrichtung hat einfach geklappt.
Nun zu meinem Anliegen, wie könnte ich 8 Rückmelder ( mit Optokopplern) an diese Hardware bekommen? Beim Mega gibt es ja jede Menge freie I/O pins, aber ich habe noch keine Schaltung oder Beschreibung für die ESP32 Variante gefunden.
Außerdem würde mich die Automatik sehr interessieren, einfacher Gleiskreis mit Bahnübergang und 2 Signalen, geht das zum Beispiel über Skript mit Tasten ohne PC Anbindung?
Ich meine Taste drücken und dann Schranke(Servo) zu, Signal(Servo)  auf Fahrt und der Zug fährt eine Runde.
Grüße an alle
Matthias

Mehr Ausgänge und Eingänge bekommt man mit l2C Erweiterungschips. Auf unserer Webpage steht welche unterstützt werden. Muss man etwas aufpassen weil der ESP32 is 3.3V und I2C gibt's in 5 oder 3.3V.

Wenn man I2C auf 3.3V angleicht kann man auch einen mega als pinextender nutzen.

Für Skripts seh dir Mal auf der dccex Seite EXRAIL an. Das löst solche Aufgaben einfach ohne angeschlossenen PC. Die Logik wird mit der Zentralensoftware verlinkt und auf die Zentrale geladen.

Grüße,
Harald.

Hallo Harald,
ich habe mich mal in die DCCEX eingelesen und auch Gleisbesetztmelder ( 7 Abschnitte) über einen MCP 23017 Baustein über I2C angeschlossen. Ging alles relativ einfach. Auch JMRI und Engine Driver funktioniert super, auch gleichzeitig.
Für so eine kleine Anlage optimal.
Nun meine Frage, kann DDCEX auch Servos ansprechen die an anderen Decodern aufgeschaltet sind?
Speziell meine ich die Moba Led Lib, da sind meine 2 Signale und eine Schranke über DCC Adressen 411-413 dran.
Steuern eines Zubehördecoders mit<a linear_address activate>, bin ich da richtig?
Oder muss ich da ein Modul mit PCA9685 verwenden und die Servopositionen neu einstellen?
Bei EXRAIL sind es ja ein paar Dateien die zu bearbeiten sind, um automatisch auf "Knopfdruck" zu fahren und da werde ich mich als nächstes "reinfuchsen".
Grüße
Matthias

Der PCA9685 steuert direkt die Servos an und ersetzt somit den DCC Decoder, welchen ja die Moba Led Lib im eigentlichen Sinne darstellt. Du musst DCC-EX nur dazu bringen den gleichen DCC Befehl zu senden, damit die Moba Led    Lib diesen versteht.

Hallo Harald,
hast du einen Link zum Branch devel-z21 bzw. kann ich diesen verwenden?
https://github.com/DCC-EX/CommandStation-EX/tree/devel-z21

Ja, hinter dem grünen Knopf gibs den Zipfile oder eben mit git Kommandos:

git clone https://github.com/DCC-EX/CommandStation-EX.git
git checkout devel-z21

Dann mit Arduino IDE oder PlatformIO für ESP32 kompilieren und uploaden (ach, Deutsch ist so schööön geworden).

Grüße,
Harald.

Habe es installiert bekommen, aber irgendwo ist noch der Fehlerteufel.

Mit der alten Roco z21 App bekomme ich eine Verbindung und der serielle Monitor zeigt auch sinnvolle Ausgaben, nur die Lok fährt nicht (die Track Power LEDs flackern nur etwas herum)

Mit der neuen z21 App (schwarzes Logo) klappt es auch nicht besser. Die Gleispannung lässt sich nicht einschalten.
Der POWER Status wechselt zwischen POWER SC <--> POWER Off

Es liegt wohl am ausgewählten Board in der Arduino IDE!? Ich habe mich für ESP32-WROOM-DA entschieden, aber die Pin-Zuordnung zum Motorshield ist wohl fehlerhaft.


++++ PS. Problemlösung gefunden: Board Wemos D1 R32

Die ersten Test sind absolviert. Hierbei gibt es noch Verbesserungspotential:
1. Betrifft nur die neue Schwarze Z21 App: Mit dem Stopp Button oben rechts kann man zwar die Gleispannung ausschalten, aber nicht wieder ein.
2. CV lesen klappt sowohl im Programmiermodus als auch im POM-Modus, wobei er dabei immer auf Track B zugreift, finde ich aber nicht ganz so schlimm. CVs schreiben klappt jedoch weder im Programmiermodus noch im POM-Modus.
3. Starte ich die APP  Engine Driver, so wird diese sofort wieder beendet.

Danke für den Feedback.

1. Wie ist jetzt die Strategie von Roco da, ersetzt die schwarze App Version 1.4.7 (200+MB) von Weihnachen 2022 zu 100% die rote Version 2.6.9 (12MB) von 2017?
Das mit der Gleisspannung seh ich mir an.

2. CV lesen sollte doch nur im Servicemodus gehen, PoM-lesen geht nur mit RailCom Detektor und das haben wir nicht. CV schreiben sollte in beiden Varianten funktionieren, seh ich mir mal an was da fehlt.

3. Ist seit Vorgestern erledigt (ich hab es glatt geschafft einen Bug in ED herauszukitzeln)

Grüße,
Harald.

Hallo,

ich dachte die alte App wäre schön längere Zeit obsolet? Wir im Verein benutzen jedenfalls ausschließlich die schwarze Version 1.4.7.

Grüße, Peter W

zu 1. Ich habe einfach mit beiden APPs getestet und dabei eben auch kleine Unterschiede entdeckt.

zu 2. Wenn ich im POM-Modus "CV lesen" drücke, fängt die Lok auf dem Programmiergleis an zu ruckeln und die CV wird ausgelesen.

zu 3. Dann warte ich mal auf die nächste Version von Engine Driver

Wenn jemand eine echte Z21 hat und mir einen UDP Packet trace (z.b. mir Wireshark) vom Ein- und Ausschalten der Gleisspannung sendet, dann bekomm ich das wahrscheinlich hin. Ich weiss gerade nicht welche Antworten die App erwartet wenn der Strom ein und ausgeschaltet wird, z B von der Multimaus aus.

Du brauchst nicht auf den nächsten ED warten, einfach dccex updaten (dann ist die Version nicht mehr 5.X.Y und ED ist happy). Oder in version.h 5.66.77 reinschreiben. Dann kann man auch gleichzeitig mit ED anschließen und da den Strom einschalten.

Grüße
Harald.

Das wäre LAN_X_SET_TRACK_POWER_ON und LAN_X_BC_TRACK_POWER_ON.

Verstehe ich das richtig, wenn ich devel-z21 neu downloade und in den ESP lade, ist der Absturzfehler in ED nicht mehr da?

Lag es nur am #define VERSION "5.X.Y"  ??

Grüße Uli

Wenn ich DCC-EX in Verbindung mit rocrail verwende, kann ich gleichzeitg nur 12 Loks ansteuern.
Sicher kann man dies ändern. Ich weiß nur nicht wo. Wäre vielleicht auch ein Punkt für die config.h

Gruß Uli

Ja, in RocRail.

Hintergrund: Vor Jahren konnte DCC++ nur 12 Loks. Seitdem gibt es aber ein Kommando mit dem RocRail oder JMRI rausbekommen kann wieviel Loks denn unerstützt werden von gerade der Version die man vor sich hat. Ich nehme an RocRail fragt nicht sondern geht immer noch von den antiken 12 aus.

Jede Lok braucht natürlich Speicherplatz so es ist eine Abwägung wieviele Loks man zulässt. Weil Weichen und Sensoren brauchen ja auch noch Speicher falls man solche haben will. Auf Uno/Nano ist die Anzahl normal 30 und auf allen anderen CPUs 50. Wenn 50 nicht reichen kann man sich DCC.h angucken und das hochsetzen. Ich will das aber nicht beliebig für alle hochsetzen weil ich weiss niemand der so viele gleichzeitige Loks getestet hat.


Grüße,
Harald.

Harald, vielen Dank.

Mein rocrail Version habe ich vor einiger Zeit eingefroren, es funktionierte alles zu meiner Zufriedenheit. Vielleicht hängt es damit zusammen.

In Summe komme ich auf 25 Weichen und 25 Loks wären nicht schlecht. Das ergibt dann 50. Die Sensoren ca.64, Signale und Entkuppler müsste ich auf einen weiteren Arduino auslagern.

Wie ist die Empfehlung der Verbindung von rocrail-PC bei mehreren Arduinos, alle mit USB? Oder ist ein Ethernet bei mehrern MEGAs mit entsprechendem Shield von Vorteil? Die ESP32 Version über WLAN oder USB?

Ob ein RocRail upgrade hilft weiss ich nicht. Mit der Software befasse ich mich nicht.

Um herauszubekommen ob das RAM im Mega reicht geht probieren über studieren. Wieviel RAM noch übrig ist wird ja angezeigt.


Ganz so einfach ist das nicht mit dem Zusammenzählen.

Um herauszubekommen ob das RAM im Mega reicht geht probieren über studieren. Wieviel RAM noch übrig ist wird ja angezeigt.

Was RAM braucht:
* Die Refreshliste für die Loks. Da das aber recht wenig ist, fix auf 50 (Uno 30) gesetzt.
* In der CS definierte Weichen (<T>)
* In der CS definierte Ausgänge (<O>)
* In der CS definierte Sensoren (<S>)
* Exrail Objekte

Was KEIN RAM braucht:
* Mit <a> geschaltete DCC Zubehörsdekoder

Wenn man alles RAM aufgebraucht hat man als Ausweg:
* Refreshliste kleiner machen (wenn es gerade so knapp nicht reicht)
* IO Buffer für WiThrottle kleiner machen (vor allem wenn man kein WiThrottle verwendet)
* Mehr als einen Arduino anschließen (aber dann muss man das irgendwie gescheit aufteilen)
* Auf ESP32 oder STM32 ausweichen (genau nachsehen welche Hardwarevarianten funktionieren)

Grüße,
Harald.

Da es gerade um Speicher geht, habe ich mal getestet:
Mega 2560 Free RAM =5409b
ESP32          Free RAM=226588b mit aktivem WLAN
frisch aufgespielt, der große Unterschied der beiden Shield's ist halt, dass der ESP nicht so viele zusätzliche I/O Anschlüsse hat,
aber das löst der I2C Bus.

Grüße
Matthias

Warum wollt ihr den Uno R4 partout nicht?

Grüße, Peter W.

Wenn es denn ein Uno wäre mehr als der Name... Also ich liste jetzt mal:

* Soo viel RAM hat er dann auch nicht
* Neuer, anderer Prozessor (man muss alles was Prozessorabhänging ist neu schreiben, wir haben etwas mehr als einen "Blink-Sketch").
* Blöd angeschlossenser Coprozessor für Netz/Wifi (Begrenzungen durch Serial und die Coprozessorfirmware)
* Preis
* LED sind ja lustig doch kommt da ein Shied drüber und wer guckt auf seine Zenrale wegen der Blinkenlights?
* Immer noch sehr wenige I/O (das hat er mit dem Uno gemeinsam)
* Wenn schon im Uno-Format warum dann nicht den ESPduino32 für die Hälfte
* Wahrscheinlich eine Sackgasse in der Entwicklung. Also ich rate es kommt kein kompatibler R5.

Ist das Ding nicht wie ein Doppelstock IC2?

Grüße,
Harald.

Wir bekommen an und zu Fragen zu S88. Könnte man mit einem extra Uno pro S88 der dann das S88 auf I2C übersetzt einfach machen. Den Driver für den Uno als Expander auf der CS Seite gibt es schon. Allerdings macht keiner von uns im Coreteam S88. So wenn ein S88 Fan Lust hat sich da zu beteiligen, es gibt noch was zu tun.

Man sieht sich im Discord.

Grüße,
Harald.

Ich habe leider kein S88. Meine Rückmelder arbeiten alle mit DCC-EX, zur Zeit noch ein ArduinoMEGA.

Bezüglich obiger Diskussion (Ressourcen und Speicher) plane ich jetzt "Fahren und Schalten" (ESP32) vom "Rückmelden" über Sensoren (ArduinoMEGA) zu trennen. Weitere Sensoren lassen sich durch zusätzliche ArduinoNanos über I2C mit installiertem I/OExpander anschließen.

Gruß Uli

Also das soll jetzt keine Aufforderung gewesen sein einen Dinosaurier (S88) anzuschaffen aber wenn man schon so ein Haustier hat....

Grüße,
Harald.

Hallo Namensvetter,
wenn du "Fahren und Schalten" und "Rückmelden" durch verschiedene Prozessoren trennst, wie machst du dann die Automatisierung (EX_RAIL)?
Ich plane z.B. folgendes  "wenn Rückmelder1, dann Geschwindigkeit Lok erhöhen..." Dies geht meiner Meinung nach nur, wenn beides auf einem Prozessor läuft. Oder liege ich da falsch?
Ich plane sowohl alle Ein- als auch alle Ausgänge über I2C. Dann werde ich vom Prozessor unabhängig.

Gruß Uli

In meinem Fall nutze ich dann eine zusätzliche Software, z.B. rocrail, die multi-CS-fähig ist. Für Ex-Rail musst du mit einem Prozessor arbeiten und alle Erweiterungen mit I2C anschließen. Funktioniert natürlich auch solange der I2C-Bus mitspielt.

Ich wollte mein kleines Oval auf einer Winteranlage gerne mit Tastern steuern, also Schranke zu, Ausfahrt Signal auf Fahrt und so weiter, noch paar Funktionen im Ferkeltaxi aufrufen (Abfahrtspfiff, Licht an, Innenlicht an...).
Für die Haus- und Strassenbeleuchtung ist unabhängig die Moba Led Lib verantwortlich. Gefahren wurde bisher mit einer Mini Zentrale nach PG.
Durch Zufall habe DCC Ex entdeckt und mit etwas Einarbeitung habe ich meine Wünsche erfüllen können.
Nutze einen ESPduino32 Klon und ein Motorshield von Deek-Robot, Am I2C Bus hängen über ein PCA9685 Modul
die Servos und am MCP23017 Modul die Rückmelder (Diodenschaltung und Optokoppler), ging alles super und über die Datei myAutmation.h lässt sich alles wunderbar steuern.
Und das beste für mich ist, es ist keine andere Software nötig, kein Rockrail oder sonstwas, aber ich kann über Engine Driver trotzdem die Loks fahren lassen.
Natürlich hat jeder andere Ansprüche und da gibt es halt viele Lösungen, für mich ist DCC Ex optimal, für jemand anderen geht das gar nicht, deshalb viel Erfolg bei eueren Projekten.

Grüße
Matthias

Wenn man einen ESP32 hat dann funktioniert der Install sei gestern nicht mit dem neusten  ESP32 Paket 3.0.0. Das muss man zur Zeit manuell auf 2.0.17 "downgraden" und mit IDE oder Platformio installieren. Denn auch der Installer der das neuste Paket wählt  ist davon betroffen. Wir arbeiten an einer Lösung, erstmal um immer automatisch 2.0.17 anzuwenden weil 3.0.0 ist nicht kompatibel, so wie Espressif IDF5 nicht zu IDF4 kompatibel ist. Jede Menge Arbeit und eigentlich für nix, weil die neue Version hat sonst nix was wir bräuchten.

Grüße,
Harald.

Hallo Harald,

Ich habe eben einen ESP32 in Betrieb genommen. Das Compilieren hat geklappt.
Plug And Play ist mit diesen ESPDUINO nicht möglich.
Ihr beschreibt, dass die Spannung das Pins "IO0" zu hoch ist .. dies war bei meinem Amazon Modell nicht der Fall.
Aber man sollte alles, was beschrieben ist, nachmessen, um sich die Hardware nicht zu killen.

Immer als Tipp: bei sämtlicher China Ware immer die Ankerpunkte der USB Buchsen nachlöten! Die reißen sonst nach recht kurzer Zeit aus/ab.

Zur Software: Der Master Branch (Default) fkt zum jetzigen Zeitpunkt nicht!
Ich habe den devel Branch genutzt, dort ist in der Platform.ini der entsprechende Eintrag korrekt gesetzt:



Das könntet Ihr im master ja auch eintragen ...

Viele Grüße, Franzi

Hallo Franzi,

ja die China Hardware,.. Das kann ich unterschreiben. Der Beschiss macht nicht einmal mehr vor dem großen Ceh halt, obwohl die im konkreten Fall nicht dafür können wenn der Lieferant zu doof oder zu faul ist, nachzuprüfen was sie in China so eingekauft haben.

Hatte mir testweise einen Arduino Micro Pro von Joy-It bei C gekauft, das ist eigentlich eine deutsche Firma, aber der 5 V Regler Made in China auf dem Board hat nur 6,5 V max. Eingangsspannung am Pin "RAW" anstatt 7-11 V wie in der BA angegeben. Hilfreich war dabei ausgerechnet der freundliche Ali, wo nach einigen Googeliaden eine genaue Zuordnung der SMD Markings und der Chip Type heraus kam.

Warnen möchte ich auch vor den Arduino Mega mit dem CH 340 USB-seriell Chip. Der ist zwar nicht prinzipiell böse, aber scheinbar empfindlich auf bestimmte USB Kabel, oder Übergangswiderstände, und/oder die Typ B Buchsen sind da teilweise schlecht. Da hatten wir im Verein schon mehrmals komische Effekte, dass der COM Port im Device Manager zwar angezeigt wird, aber der Upload fehl schlägt.

Für technisch weniger versierte ist das oft mit hohem Frustlevel verbunden.

Grüße, Peter W

Hallo Peter,

[OT]

Das ist echt Böse, damit rechnet ja eigentlich niemand.
Ich verlasse mich eigentlich nie darauf, dass die Chinesen die Spezifikationen einhalten.

Ich kaufe gerne die Hardware, immer in dem Wissen, dass man nacharbeiten muss.
Der erste etwas "schlimmere Ausfall" war das Display der Lötstation, was am Ende nicht einmal kaputt war, es war lediglich das Flachbandkabel vom Display zum Controller nicht ordentlich aufgelötet.

[/OT]

Viele Grüße, Franzi

Die Software funktioniert schon, aber nur wenn das ESP32 Paket nicht auf 3.0.x "upgegradet" wurde. Wie automatisch PlatformIO das macht weiss ich nicht. Bei einen neuen Install kommt natürlich das Neueste wenn man nix anderes sagt und dann gehts nicht.



Je nachdem welche der drei Methoden man anwendet um den Sketch auf den ESP32 zu bringen gibt es verschiedene Möglichkeiten die richtige Version vom ESP32 Paket zu bekommen.

1. Unser eigener Installer

Da arbeiten wir gerade daran den so hinzubiegen dass die richtige Version automatisch installiert wird. Da das aber arduino-cli im Hintergrund verwendet und arduino-cli sehr gern für dich ein Upgrade macht ist das nicht ganz trivial. Was man z.Z. machen kann ist den Installer so weit nehmen bis man kuz vor dem Upload ist und dann in einem Kommandofenster eingeben:

arduino-cli wird vom Installer vorinstalliert, so das muss man nur finden
Dann aufs Upload-Knöpfchen drücken.

2. Arduino IDE

Da geht es nur manuell indem man im Board manager das ESP32 Paket aufsucht und dann 2.0.17 (halt kein 3.irgendwas) auswählt. Wir arbeiten daran zumindest eine Fehlermitteilung auszugeben die sagt was zu tun ist.

3. PlatformIO

Da kann man mit platformio.ini arbeiten und das habe ich in Devel schon gemacht. Master kommt noch.

Da schreibt man im platforio,ini dann
platform = espressif32 @ 6.7.0
anstelle von
platform = espressif32

PlatformIO har "natürlich" seine eigene Versionsnummerierung wobei 6.7.0 ist Arduino ESP32 version 2.0.16 und das ist Espressif IDF version 4.4.7.

Das ganze ist recht ärgerlich weil die Maintainer des ESP32 Arduino Pakets haben ja nicht die Arbeit wenn jetzt alle Anwender von unserem Projekt zu uns kommen und uns sagen dass es nicht mehr geht und dass sie Hilfe brauchen. Die meisten sehen nämlich zu dem Zeitpunkt nicht ein wo das Problem liegt.

Grüße,
Harald.

So, jetzt haben wir einiges am Installer rumgebogen, also es gibt eine neue Version. War leider etwas mehr vertrackt as gedacht.

Hier: https://github.com/DCC-EX/EX-Installer/releases/tag/v0.0.19-Devel

Microsoft muss noch den 64-Bit Installer als harmlos befinden, warum das länger dauert als beim dem für 32-Bit wissen wir auch nicht.

Es gibt auch noch einen kleinen Bug im ESP32 Install für Linux (bei manchen Linuxinstalls). So wenn der Installer von der obigen URL nicht geht dann haben wir noch eine andere Alternative für unsere Opensourcefreunde:


An der DCCEX CS Software an sich hat sich in der Zwischenzeit nur wenig geändet (ja, es gibt ein neues v5.2.62-Devel aber nix weltbewegendes). Die beiden inkompatiblen Updates (arduino-cli von 2.x auf 3.x und Arduino ESP32 package von 2.X auf 3.X) haben sehr viel Zeit verbraten, weil unser Installer auf ein möglicherweise notwendiges Downgrade der toolchain nicht vorbereitet war.

Wir denken stark darüber nach die Toolchain im Hintergrund von arduino-cli auf platformIO zu wechseln wo man viel besser Versionen der Tools pro Projekt festlegen kann. Das geht aber leider auch nicht so im Handumdrehen. Für den Nullachtfuffzehnanwender sollte sich dadurch nix ändern.

Grüße,
Harald.

Hallo Harald,

Danke für Eure Arbeit. Der Devel hat schon v5.2.65

Wer mit Visual Studio Code klarkommt, kann den Source Code auch selber kompilieren.
Dies funktioniert bei mir auf verschiedenen Rechnern problemlos.

-----------------------------------------------------

Eine kleine Info zur Android App "Engine Driver"
Die Version im Google Playstore ist die 2.36.177 vom Februar 2021

Diese Version hat bei mir doch erstmal Frust ausgelöst:
Die Voreingestellten Funktionstasten (Bezeichnungen und Verhalten - Tasten rasten nicht ein) lassen sich (bei MIR)
nicht bearbeiten, bzw es wird nichts gespeichert.

Abhilfe gibt es hier:
https://enginedriver.mstevetodd.com/downloads

Hier werden auch die verfügbaren Beta Versionen angeboten, bei der im Moment letzten Beta v2.37.185
funktioniert diese Bearbeitung.


Viele Grüße, Franzi

Hallo Harald,

Gibt es etwas neues zum Branch devel-z21 oder wurde dieses Projekt eingestellt?

https://github.com/DCC-EX/CommandStation-EX/tree/devel-z21

Gruß Uli

Hallo,

an der Stelle möchte ich warnend informieren dass ich ein unerwartetes Verhalten des ~ bitwise Not Operators in avr-gcc gefunden habe.

Der Typ des Arguments wird ignoriert und das Ergebnis prinzipiell auf 32 Bit expandiert. Das ist auf einem 8bitter unnötig langsam und führt zu unerwarteten Ergebnissen.

~(uint8_t)0 ergibt FFFFFFFF

Drauf gekommen bin ich, weil z.B. ~PIND >> 4 nicht zu einem Wert im Bereich 0...F führt, sondern F0....FF ergibt, wenn das Ergebnis wieder in ein Byte geschrieben wird.

Das Verhalten deckt sich interessanterweise exakt mit Microsoft VS C++., wobei es bei 32bit oder 64bit CPU mitunter schneller sein kann, aber wer hat da von wem abgeschrieben?

Leider hat Arduino keine Methoden zum Schreiben und Lesen ganzer Ports.

Also falls ihr Arduino/AVR Eingänge am Stück in negativer Logik (Input mit Pull-up) einlesen wollt, benutzt bitte XOR:

uint8_t value = PIND^0xff.

Die Operatoren für AND (&), OR (|) und XOR (^) sind nicht betroffen und verändern den Typ nicht.

Grüße, Peter W

Hallo Peter,

das ist regelkonformes Verhalten des Compilers. Alle Datentypen werden mindestens auf int expandiert, bevor Operatoren angewendet werden.  Das gilt für den unären bitwise not-Operator genauso wie für die anderen bitwise Logik-Operatoren. Aber die heutigen Compiler sind ziemlich gut, das alles wegzuoptimieren. Wenn Du erst negierst und dann den Cast auf uint8_t machst, bekommst Du das gewünschte Ergebnis.

Zum Herumspielen mit Compilern übrigens ist der Compiler Explorer. ganz schön

https://godbolt.org/

Der Ausdruck

  ((uint8_t) ~num) >> 4

wird gerade einmal in drei Maschinen-Instruktionen umgesetzt:

        com r24
        swap r24
        andi r24,lo8(15)

Klaus

Hallo Klaus,

Danke für die Infos. Den Assembler Code schaue ich mir noch an. Das ist sehr interessant.



Das ist aber nicht durchgängig der Fall. AND, OR und XOR expandieren den Single Byte Typ nicht, sonst würden Pin Markierungen möglicherweise gar nicht richtig funktionieren. Insofern ist das NOT irgendwie inkonsistent.

PIND^0xff >> 4 ergibt ein Nibble. PINx ist ein Makro das als (volatile uint8_t *) definiert ist. Das ist auch korrekt so.
Da wird weder auf int noch auf long expandiert.

Wobei ich int (16bit) ja irgendwo verstanden hatte, aber welchen Sinn hat die Expansion auf 4 Byte bei einem Compiler für einen 8bitter? Gibt es dafür irgendeine C Spezifikation?

Grüße, Peter W

Wenn du dich im App Store als Beta Tester für die APP Engine Driver freischalten lässt, dann bekommst du immer die letzte Beta als Update. Du kannst das jeder Zeit wieder deaktivieren.

@Peter:

Ich weiß ja nicht, wie Du das ausgegeben hast… Was die Spezifikation angeht, bin ich aber auch nicht allwissend und sattelfest. Ich verwende zum Nachschlagen (und da habe ich vorhin auch nachgeschaut) die Site

     https://en.cppreference.com/

Nicht immer leicht zu verstehen, aber ich denke, daß die Information dort direkt aus dem C++-Standard stammt und somit eine echte Referenz ist. Es gibt dort auch eine Sektion für C selbst.

Klaus

Hallo Klaus,

laut der Spezifikation kann eine Operation nach int oder unsigned int konvertieren, aber nicht nach LONG.
https://en.cppreference.com/w/cpp/language/impl...n#Integral_promotion

Aber:

(uint8_t)(~PIND >> 4) != ((uint8_t)~PIND) >> 4

Grüße, Peter W.

Hallo Peter,

ein 16-Bit-Integer-Typ reicht ja schon aus, um ein unterschiedliches Verhalten zu bekommen. Warum Du da einen 32-Bit-Wert bei der Ausgabe bekommen hast, weiß ich nicht, ich kenne die AVR-Plattform und den Compiler nicht weiter. Und ich weiß auch nicht, wie Du Dir den Wert hast anzeigen lassen. Deshalb kann ich nur raten. Vielleicht wird er bei der Ausgabe noch auf 32 Bit erweitert und das mittels Sign Extension.

Klaus

Leider hat sich im 0.0.19 Installer ein Bug eingeschlichen. Beim Erstdownload von EX-CommandStation ist unter Windows das Zieldirectory falsch angegeben. So es gibt folgende Möglichkeiten:
1. Nicht Windows nehmen
2. Auf 0.0.20 warten
3. Folgender Workaround:

3a. 0.0.19 nehmen bis Fehlermeldung
3b. 0.0.18 nehmen Refresh-Cli **nicht** anrühren und duchklicken bis "Board Select", dann abbrechen
3c. 0.0.19 durchziehen (jetzt ohne Fehler)

4. Manuell git clone an die richtige Stelle, also unter eurem Windowsanwender in  ex-installer\CommandStation-EX

Grüße,
Harald.

Das mit der Z21 app hat mich so geärgert dass ich erstmal nicht weitergemacht habe und die blöden Probleme mit arduino-cli und ESP32 haben erstmal alle meine Zeit aufgebraucht.

Grüße,
Harald.

Hallo Klaus,

nochmals Danke für den Tipp mit dem Compiler Explorer.

Ergebnis eines Disassembly des echten Code zeigt übereinstimmend mit dem Explorer, dass im Fall eines Type Cast auf einen 8bit-Typ mittels eines Hilfsregisters Null Bits via Carry in einer Schleife hinein rotiert werden.

(uint8_t)~PIND >>4 oder ((uint8_t)~PIND) >>4

avr-gcc bis Version 9 ergibt:

608: 89 b1       in r24, 0x09 ; 9
60a: 80 95       com r24
60c: 90 e0       ldi r25, 0x00 ; 0
60e: 24 e0       ldi r18, 0x04 ; 4
610: 95 95       asr r25
612: 87 95       ror r24
614: 2a 95       dec r18
616: e1 f7           brne .-8       ;  0x610

Ab Version 10 ist es erst effizienter:

        in r24,0x10
        com r24
        swap r24
        andi r24,lo8(15)

Grüße, Peter W.

Mit dem Arduinopaket kommt normal avr-gcc 7.3.0, Neuere avr-gcc machen das Binary oft schneller aber dann ist es oft so groß dass es nicht mehr in den CPU passt (trotz -Os) und dann bringt uns das nix.

Grüße,
Harald.

Heureka! So lässt es sich doch auch mit avr-gcc 7.3.0 optimieren:

(PIND^0xff) / 16 (ist das gleiche wie >> 4) kommt mit genau den 3 Maschinenbefehlen und 1 Register aus:

        com r24
        swap r24
        andi r24,lo8(15)

Grüße, Peter W.

Ich nutze schon seit längerem die Arduinio IDE 1.8.19 für diverse Boards ohne Probleme. Welche Compiler Version die hat weiß ich leider nicht.

Hallo,

ich habe hier ein Mega 2560 mit einem Deek-Robot Motor Shield und W-Lan Modul.
Das Ding hat auch viele Tage funktioniert, nun wollte ich es nach längere Liegezeit mal wieder in Betrieb nehmen und habe auch die aktuellste Version drauf, nun bekomme ich aber den Shield nicht mehr an bzw. es blinken die 4 roten Leds kurz mal auf.... ich weiß das wenn die Versogung über Handy auf On gestellt wird die Leds eigentlich in Standlicht übergehen.
Ich bin da eher Laie, habe das damals nach der DCC Webseite zusammen gebaut

Ist das Shield ggf. defekt?

LG

1. Auseinanderziehen und wieder zusammenpressen dass die Pins alle gut sitzen.

2. Fehlermitteilung über USB Serie?

3. Nee, ist eigentlich nicht Standlicht sondern blinkt im Takt mit der DCC Frequenz, da kommt halt das Auge nicht mit.

Grüße,
Harald

Hallo Harald,

1. Habe ich gemacht, bringt leider nichts
2. Der Serial Monitor sagt alles okay, Verbindung mit Handy und Engine Driver funktioniert soweit auch
3. Das Standlicht "" war damals aber vorhanden und jetzt blinken die LEDs ca. alle 2-3 Sec. einmal.

So geht wieder, hab einfach eine älter Version drauf gespielt. Danke 😉
VG

Würde dann schon gern wissen welche Version funzt und welche nicht. Auch ein Log vom Startup wäre fein. Alle 2-10 Sek blinken deutet eigentlich darauf hin dass die Kurzschlussmeldung anspricht und wenn der Arduino den PowerStatus ändert dann wird das auch angezeigt, also im Monitor gemeldet bekommen. Wir können zwar nicht alle Varianten die unsere Anwender gebaut haben durchprobiren aber Mega mit DeekRobot ist nicht ungewöhnlich und wenn das nicht funzt dann merken wir das normal schon.

Grüße,
Harald.

Ich hab die letzte Version von 4.x.x genommen bevor die 5er anfängt.
Kurzschluss ist eigentlich ausgeschlossen da nichts weiteres angeschlossen gewesen ist, außer die Spannungsversorgung selbst.

Ich kann jetzt nicht behaupten dass das hilft den Fehler zu finden. Die stabilen Versionen sind z Z 5.0.x und Entwicklung ist 5.2.x.

Grüße,
Harald.

Bei meinem Testsystem hatte ich das Phänomen (blinkende LEDs auf dem Motorshield) auch, ich habe dann auf die neuste Development Version 5.2.65 gewechselt, dann ging es wieder. Ich weiß aber leider nicht mehr die Versionsnummer. Es könnte die Version 5.0.7 oder 5.0.9 in Verbindung mit dem Installer gewesen sein.

Bei meinem "Produktivsystem" nutze ich immer noch die Version 4.1.16 mit der Modifikation zur Anzeige der Stromstärke auf dem Display und in Verbindung mit rocrail.