Forum Replies Created
-
Posts
-
Hi Matthias,
this works perfectly. And it is even more convient than a single config-file. Thank you.
Have a nice sunday.
DirkHi Ray,
that sounds great. Thank you.
Yes, f1 or higher works. It is f0 and autolights while driving that are not working. I tested it with several AZDelivery ESP32 NodeMCUs and three different PU hubs where the result was always the same.
Cheers,
RayHi everybody,
in the meantime I tried another ESP32 I previously used as a MTC4PU (AZDelivery ESP32 NodeMCU Module WLAN WiFi Dev Kit C) and programmed it with the MTC4BT firmware and the config-file above including the correct direction. The result was the same as before (motors running, but no light).
Then I connected the ESP32 to my standard power supply (5V, 3A) and connected two LEDs to pins 0 and 23. Pin 23 is already assigned to the status LED in the config file. Additionally, I assigned pin 0 of the ESP32 to function F3 and I changed the functions of the lights of the PU-Hubs to F1 and F2. This means that functions F1, F2 and F3 are assigned. This resulted in the following:
1. With functions F1 and F2 the lights attached to the PU Hubs can be activated manually.
2. No lights are activated while driving.
3. Activating function F3 has no effect on the LED at ESP-Pin 0.
4. When I accidentially activated function F0 the following message in the serial monitor appeared:
“[1] MQTT: Received ‘fn’ command’ but couldn’t read ‘fnchangedstate’ attribute.”This is a progress as I can now activate the lights on the trains and the problem is reduced to the function F0 and the autolights while driving.
May the fact that I am using an older version of ROCRAIL server (v2.1.1332 of January 2021) have an effect on this?
Kind regards,
DirkHi Raymond,
thank you for your answer.
Yes, I uploaded and tested the configuration and it worked well for the motors (both engines running in the same direction). But your right, it should be “reverse” and not “reward”. I think I mixed this up during the testing. I will correct that in the config file and check what happens.
Meanwhile, I tested it for onl one locomotive with PU and one motor and one light, but the result was the same. Do I have to configure something other than the address of the locomotive in ROCRAIL?
Dear Joos,
thank you for your answer. These are great news and will make life easier (at least in terms of running LEGO trains 🙂
After getting used to the VSC I managed to get the first MTC4BT running. I was a bit struggling with a train with two PU Hubs, but succedded. Looking forward to extend this to my other trains.
Kind regards,
DirkDear Matthias,
First of all, happy new year and thank you for the information and all the great work you and your team put into this project and share it with us.
For the MTC4PU-Controllers the PU-Hubs have to be started in the order in which they are listed in the configuration file, so, if you have two locomotivess in your config-file and you want to drive the second locomotive, you have to start both locomotives. Does this also apply for the MTC4BT-Controller or is it independent of the order in the list?
Dirk
Hallo,
ich hatte letzte Woche auch ein Problem beim Upload der Firmware, das auch auf die Version 3.0.0 des ESP8266 zurückzuführen war:
https://mattzobricks.com/forums/topic/firmware-upload-issues#post-3300
Scheint noch nicht ganz ausgereift zu sein, die V 3.0.0
Viele Grüße
DirkHallo,
ich habe gestern in der ARDUINO IDE (v1.8.15) das Paket für den esp8266 von der Version 2.7.4 auf die Version 3.0.0 geupdated. Das Resultat war, dass beim Update der MattzoLayoutContoller folgender Fehler in einer ganzen Reihe von Zeilen auftrat:
“call of overloaded ‘abs(unsigned int)’ is ambiguous”
z.B. in Zeile 671:
levelCrossing.servoAngleIncrementPerMS = (float)abs(LC_BOOM_BARRIER_ANGLE_PRIMARY_UP – LC_BOOM_BARRIER_ANGLE_PRIMARY_DOWN) / LC_BOOM_BARRIER_OPENING_PERIOD_MS;
Der Fehler liegt wohl darin, dass die abs-Funktion mit “unsigned integer” nicht klar kommt und lieber int, float oder double hätte. Warum das erst bei Version 3.0.0 ein Thema ist, habe ich nicht ergründet. Da in der mattzo-Firmware die Variablen und Konstanten mehrfach direkt als “unsigned integer” und nicht als “integer” deklariert werden, und ich nicht weiß, warum, habe ich die Deklarationen so gelassen und bin für die esp8266 auf die Version 2.7.4 zurück. Jetzt funktioniert das Update der Firmware wieder. Never change a running system.
Vielleicht hat der ein oder andere mal das gleiche Problem…
VG
DirkHallo Max,
ich hatte die Einstellung/Justage der Servos wie oben beschrieben durchgeführt und war eigentlich der Meinung, dass das schon ziemlich genau ist, da ich jeden Servo erst ohne Weiche und dann nochmal auf der Weiche eingestellt habe. Es wäre hilfreich, wenn Du mir einen Vorschlag machen könntest, wie man die Servos noch genauer justiert.
Tritt das Problem denn auch bei den Layout Controller mit PCA9685 auf, wenn man über OE die Stromzufuhr der Servos abschaltet? Ich hatte eigentlich die Hoffnung, dass das dieses Problem weitestgehend aus der Welt schafft, da die Einschaltzeit des Servos verglichen zur gesamten Betriebszeit der Steuerung eher gering ist. Die Servos, die bei mir “durchgedreht” sind, taten das nicht während eines Stellvorgangs, sondern immer in den Pausen zwischen den Stellvorgängen.
Die Einstellung der Min- und Max-Werte in der INO hatte ich auch schon auf dem Schirm, aber wenn man acht oder mehr Servos an einem Controller hat und darunter auch Servo für LEGO-Weichen sind, die einen deutlich kleineren Winkelbereich haben als Servos für TrixBrix-Weichen, dann hilft das auch nur bedingt.
Hi,
@Kevin: Dein Projekt ist sehr beeindruckend, insbesondere die Boards für die einzelnen Controller finde ich sehr gut. Danke für den Tipp mit den Papierstreifen. Den werde ich bei der nächsten Kalibration ausprobieren, wenn ich meine Controller-Boxen alle mit den PCA ausgestattet habe.Ich hatte die Einstellungen der Servos bisher so vorgenommen, dass ich in Rocrail erst einen unteren Grenzwert von 70° und einen oberen Grenzwert von 80° eingegeben habe und dann über das RocRail-Interface (Schaltfläche “…” hinter der Parametereingabe) sukzessive die Werte vergrößert und verkleinert habe, bis ich gehört und gesehen habe, dass der Servo am Anschlag ist. Dann habe ich nochmal 2° vom oberen Grenzwert abgezogen bzw. zum unteren Grenzwert hinzuaddiert. Das habe ich für jeden Servo durchgeführt und das ganze in einer Excel-Tabelle dokumentiert, um bei der Menge an Servos nicht den Überblick zu verlieren und um für die Doppelweichen passende Servo-Paare zu finden. Beim Aufsetzen auf die Weiche habe ich die Werte dann innerhalb der ermittelten Gernzwerte so angepasst, dass die Weiche sauber schaltet. Bei den Servos für die TrixBrix-Weichen habe ich so in der Regel Grenzwerte von 65° und 90° +-2°-3° ermittelt. Bei den Servos für die LEGO-Weichen Grenzwerte von 68° und 82° +- 2°-3°. Einzelne Servos weichen aber auch schon mal deutlich davon ab.
Hallo,
ich habe ein ähnliches Problem mit den TrixBrix-Servos mit dem MattzoSwitchControllern unter Rocrail. Ich habe für unsere Anlage insgesamt 52 Servos, von denen mittlerweile 9 den Weg in die ewigen Jagdgründe gegangen sind, d.h. ca. 17%. Bei meiner Recherche in diversen Foren habe ich gelesen, dass das bei diesen billigen Servos wohl keine Seltenheit ist und Ausfallraten von 20% durchaus vorkommen. Wirklich glücklich macht mich das aber nicht, da das mit der Zeit ordentlich ins Geld geht. Alle Servos waren so kalibriert, dass die Weiche ordentlich schaltet, der Arm aber noch nicht am Anschlag des Gehäuses ist. Bei mir stellt sich das meist so dar, dass nach ein paar Minuten Betrieb ohne das der Servo in diesem Moment angesteuert wird der Servo plötzlich ein laut surrendes Geräusch von sich gibt, als wenn er versuchen würde, eine Position anzufahren, er dabei aber an den Anschlag fahren würde und nicht weiterkommt. Erst durch Abschalten der Stromversorgung verstummt der Servo wieder. Ich betreibe maximal acht Servos und einen Switch-/LayoutController über ein 5V-3A-Netzteil, wobei die Servos direkt mit Strom versorgt werden und nur die Steuerleitungen und Ground am ESP angeschlossen sind.
Ich hatte zwischenzeitlich durch die Verwendung der Attach-/Detach-Befehle im Sketch vor bzw. nach jedem Schaltvorgang versucht, dieses Phänomen in den Griff zu bekommen, was subjektiv betrachtet auch funktioniert hat. Nachdem nun die Firmware für die MattzoLayoutController verfügbar ist, statte ich alle meine Controller-Kästen mit PWM-Servo-Treibern PCA9685 aus, um standardmäßig die Stromversorgung der Servos bei Nichtgebrauch über den OE-Pin abzuschalten. Ich hoffe das führt langfristig zu einer geringeren Ausfallrate.
Ich habe für den Ersatz der Servos bei den Antrieben für die TrixBrix-Weichen folgende Servos verwendet: HD-1800A oder SG92R, je nach Alter des Antriebs. Für die Antriebe der LEGO-Weichen werden, wie Meinhard geschrieben hat, die HD-1160A verwendet. Von denen hat sich aber bei mir noch keiner verabschiedet.