Forum Replies Created
-
Posts
-
Das liegt einfach an unserem Code. Siehe Datei “main.cpp” irgendwo in einem MTC4PF Unterverzeichnis. Die Dateinamen sind dort hartkodiert:
#include “../conf/my/controller_config.h”
#include “../conf/my/network_config.h”Ich habe ganz viele Lokomotiven, die alle unterschiedliche Konfigurationsdateien haben. Die liegen alle mit unterschiedlichen Dateinamen bei mir im “my” Verzeichnis. Diejenige, die ich gerade auf einen Controller aufspielen will, kopiere ich jeweils über die controller_config.h Datei und starte den Kompiler. Kann aber jeder machen wie er möchte, da gibt es sicherlich unterschiedliche Wege, die alle zum Ziel führen.
Wir haben die weitere Abstraktion der Konfiguration vom Code projektiert. Ziel ist eine Webkonfiguration, so dass für die Konfiguration und Umkonfiguration die Firmware nicht mehr kompilieren muss. Er Controller muss nicht einmal mehr an den Computer angeschlossen sein, um die Konfiguration zu ändern. Uns fehlt aber derzeit die Zeit, das mal anzupacken.
Noch viel Erfolg bei Deinen weiteren Bemühungen!
1. (falls noch relevant)
In der Datei “network_config.h” bitte die Zeile:const int LOGLEVEL_SERIAL = LOG_INFO;
ändern in:
const int LOGLEVEL_SERIAL = LOG_DEBUG;
Ich denke, wir haben’s aber auch schon… denn:
2.
Die Controller-Konfigurationsdatei muss “controller_config.h” heißen und im “my” Verzeichnis liegen. Wenn das nicht so ist: lösch mal die bisherige und benenne die Datei “MTC4PF_conf_BR24.h” um in “controller_config.h”. Ich denke, dass es dann funktionieren sollte.Wunderbar. Dein Controller empfängt die Button-Klicks auf F1 und F2, aber er findet kein Mapping zu den LEDs auf D1 und D2.
Bitte:
1. Schalte mal in der network_config.h den debug mode für das serial log ein (const int LOGLEVEL_SERIAL = LOG_INFO;). Was gibt das Serial Log jetzt aus?
2. Prüfe bitte einmal, ob die controller_config.h Datei, die wie gesagt aus meiner Sicht eigentlich gut aussieht, wirklich im richtigen Verzeichnis liegt, so dass der Compiler sie beim Kompilieren auch findet und verwendet.https://mattzobricks.com/automation/controllers/general -> “The Serial Monitor”
Der Abschnitt ist etwas veraltet, da wir die Arduino IDE nicht mehr verwenden. In Visual Studio (genauer: PlatformIO) ist auch ein Serial Monitor. Dazu ganz unten auf das Stecker-Symbol klicken (Tooltip: PlatformIO: Serial Monitor).
Die Konfiguration sieht auf den ersten Blick nicht schlecht aus. Kannst Du mal den Controller an den Rechner anschließen, F1 oder F2 in Rocrail drücken und das Serial Log posten? Kommen die FN-Events durch? Sonst teste mal bitte, ob die LEDs funktionieren und richte angeschlossen sind (z.B. mit einem einfachen, angepassten Arduino Blink-Sketch).
Ah, we had this before in a different topic. Do not copy the files! Check them out from the git repository directly!
Danke, Hilbert.
Stephan, hast Du einmal versucht, den Controller nur mit der Konfigurations-Datei für die Fernbedienung zu konfigurieren, also ohne Loks? Wie ist das Ergebnis dann?
Und wie Hilbert schon sagte, das Serial Log wäre hilfreich.
Ja, ich muss mich korrigieren. Die Bluebrixx-Weiche scheint tatsächlich einzelne Schaltwerke zu haben. Wie man die Weiche antreibt, entzieht sich trotzdem meiner Kenntnis.
1. Antriebe
Trixbrix hat jede Menge Weichenantriebe auch für LEGO-Weichen.Alternative: 4DBrix Weichenantriebe! Ich habe selbst noch welche von 4DBrix, die ich Dir gern verkaufen kann. Die haben eine extrem hohe Stellkraft und sind m.E. die besten, die es gibt – oder vielmehr: gab, denn 4DBrix ist mittlerweile nicht mehr im Geschäft.
Beide Varianten sind vollständig kompatibel mit Mattzobricks.
2. “Doppelweichen”
Wie diese Bluebrixx Doppel-Weiche angetrieben wird, weiß ich nicht. Aber noch wichtiger: die Bluebrixx “Doppelweiche”, wie auch schon die LEGO-Weiche Nr. 7996, haben einen gravierenden Konstruktions-Mangel: Züge können die geraden Strecken nicht gleichzeitig in der selben Richtung benutzen, da sich jeweils zwei Einzelweichen ein Stellwerk teilen.Eine Einbindung in das Mattzobricks Train Automation System ist möglich, allerdings nur mit Tricks.
Ich würde empfehlen, statt den genannten Doppelweichen die Variante von Trixbrix einzusetzen:
trixbrix.eu/en_US/p/Double-Crossover/58
Hier existieren die beschriebenen Nachteile nicht.
Attachments gehen in diesem Forum leider nicht – tut mir leid. Schick mir die Bilder mal bitte per E-Mail zu, ich werde sehen was ich tun kann.
Wiring LEDs in series is absolutely no problem.
Example: the V100 that you have seen in some of my videos. It has three white LEDs that are wired in series, and attached to the motorshield. I have also added a small additional resistor in the chain.
When connecting electrical consumers to terminals, only the voltage difference between the terminals is relevant, not the potential of the terminals. That means that “high/high” and “low/low” is precisely the same – no current will flow.
Happy building!
Got it. If you just connect LEDs to the motor shield without any resistors or other protection, they will inevitably burn out immediately and create magic smoke. The motor shield provides up to 9V, with a stronger battery even more. That is the instand end of lifecycle of any LED.
What’s you hardware setup? Did you actually build a MTC4PF mini with the PCB and the case? Or did you buy an ESP8266 development board and use it “bare” as it is? As you are referring to using D1, D2, D3 and D5 for your LEDs, I assume the latter.
Have a look at the other configuration files like the ones for TGV, SFE, METRO etc. I will also add a light configuration for the MTC4PF mini standard configuration file (MTC4PF_conf_mini.h). Before I merge it to develop, it needs some testing (don’t have the time for that this weekend, I think). If you hang yourself in here, you well be notified when it’s done and tested:
https://github.com/Mattzobricks/MattzoControllers/issues/150
Hello Ulrich,
I hope I understand your problem correctly. Do you want to connect lights to the motor shield?If yes, have a look at the example file “MTC4PF_conf_V100.h” (included in firmware version V1.2.1 and some earlier versions). There you’ll find a train light of type ‘TrainLightType::POWER_FUNCTIONS’. Is that what you are looking for?
The example loco has just a simple front light. It can be controlled via F1 in Rocrail, and it also triggered when the train starts to move.
Does that help?
Cheers,
MattzeGut, freut mich. Dein Durchhaltevermögen ist offenbar enorm, daher gehe ich davon aus, dass Du noch länger am Ball bleibst. Daher wirst Du in jedem Falle mehrere MTC4BTs benötigen. Das aktuelle Limit liegt bei 5 Hubs pro MTC4BT.
Grundsätzlich brauchst Du nur die jeweiligen Infos in den Konfigurationsdateien im data Verzeichnis bereitstellen und die Dateien auf den jeweiligen Controller hochladen. Vorher natürlich die Firmware hochladen.
Hier noch ein paar Tipps für Fortgeschrittene zum MTC4BT, wenn man groß hinaus will:
– Finde alle MAC-Adressen Deiner Hubs heraus und klebe Dir kleine Aufkleber mit den MAC-Adressen an die Hubs. Glaube mir, das hilft… 🙂
– Abstrahiere Deine loco Konfigurationen ab der ersten Sekunde von den controller_config.json Dateien. Das heißt: lege Dir eigene loco_* files an und referenziere diese von den controller_config.json Dateien. Sichere die in einem eigenen Verzeichnis irgendwo. Mach von diesem Verzeichnis regelmäßige Backups. Die loco files sind wichtiger und aufwendiger wieder herzustellen als die controller_config.json Dateien.
– Lege Dir im data Verzeichnis Unterverzeichnisse für Deine MTC4BT controller an. Kopiere die jeweiligen loco Files in diese Verzeichnisse und referenziere sie von den controller_config.json Dateien. Damit platform.ui die Konfigurationen von diesem Verzeichnis hochlädt, muss die data_dir Variable in Deiner my_platformio.ini Datei angepasst werden.
– Bringe OTA bzw. OTW zum laufen (Update des Controllers per Wifi / Ethernet, also ohne USB-Kabel).Das dürften erst einmal genug Aufgaben sein. Musst Du auch nicht alle sofort erledigen.
Versuch mal bitte, die MAC-Adressen der PU hubs kleinzuschreiben (z.B. 90:84:2b:0c:d2:05 statt 90:84:2B:0C:D2:05).
Du benötigst in der Konfigurationsdatei mindestens einen Trigger, um die Lampen anzubekommen. Schau Dir dazu mal ein Beispiel an, z.B. loco_EST.json. Das findest Du in src/MTC4BT/data_example/loco_examples.
Interessant, danke für die Info. Das Problem kannten wir bislang nur von anderen ESP32-S3 boards. Die beschriebene Problemlösung ist bei diesen Boards tatsächlich korrekt. Der Hersteller würde vermutlich sagen: Bootloader Taste gedrückt halten, dann kurz Reset drücken. 🙂
Finde ich gut, dass so schnell nach dem Release schon die ersten Leute mit dem Seeed ESP32-S3 auftauchen. Bin auf weiteres Feedback gespannt!
Thorsten, vielen Dank für diesen hilfreichen Report.
Hier ist eine Prozedur, die helfen sollte:
– my_platformio.ini neu mit der Beispieldatei my_platformio.ini.example überschreiben (vorher Backup falls dort etwas wichtiges drin stand).
– Das Semikolon vor “DRIVERTASKDELAY” entfernen.
– Das platform ui Projekt neu auswählen (in der Toolbar unten auf “env:…” klicken.Dann sollte es funktionieren.
Wir werden das mit V1.2.1 und nachfolgend abmildern. Die genannte Anpassung wird dann nicht mehr notwendig sein.
Deine Konfigurationsdateien hast Du sicherlich nach der Anleitung in ein eigenes Verzeichnis kopiert. Dieses Verzeichnis unterliegt nicht der Versionskontrolle und wird beim Aktualisieren des Sources Codes nicht geändert. Regelmäßige Backups sind vorsichtshalber natürlich trotzdem immer sinnvoll, v.a. wenn man sich mit moderner Software-Entwicklung, git und VSCode noch nicht so gut auskennt.
Schau bitte, dass die Dateien in Firmware 1.2 noch richtig funktionieren. Da haben sich ein paar Details geändert. Schau einfach mal in die Beispieldateien von Firmware 1.2 und in die Doku, dann siehst Du das schon.
Zwei identische Loks haben selten die gleiche Geschwindigkeit. Das hat viele Gründe, und unterschiedliche elektrische Spannungen sind nur einer davon. Du wirst wahrscheinlich feststellen, dass Deine “Ein Stromkreis” Lösung auch nicht dazu führen wird, dass die Loks gleich schnell sind. Wenn sie aber in die selbe Richtung ziehen, gibt es da kein Problem. Der ganze Zug fährt natürlich viel besser wenn hinten auch geschoben wird, da die Tangentialkräfte in Kurven viel gerinter sind, und daher die Radflanken der Waggons auch viel weniger Reibung erzeugen. Daher brauchen Pendelzüge mit Loks vorn und hinten auch weniger Power als Loks, die ähnlich lange und schwere Züge ziehen. Daher kann man Pendelzüge auch sehr lang bauen, ohne dass sie in Kurven stecken bleiben. Allerdings sind meine Pendelzüge über 2m lang. Ich habe da keine Kabel durchgelegt, sondern vorn und hinten einen Motor mit eigener Steuerung und Batterie verbaut.
Zu Rocrail-Fragen bitte die Rocrail Website und das Rocrail Forum befragen. Wenn wir das auch noch machen, schaffen wir sonst nichts mehr.