Paul ..I know it seems silly but have you double checked that you have un-commented //#include "Config_Nextion.h" in cfg.h ...... I always start at step one when trying to trace down a problem.
Hi Paul, Somewhere down the line we seem to have "lost" the "baud=115200" as a preinitialization event on page 0. It might be that your using a new Nextion this value has not been set. You can test using the Nextion Editor in Debug mode and connect to your Nextion with a USB to Serial adapter... Norm
I'll go through the files this morning and update them if needed. I need to do that anyway as I just received my 5" basic screen yesterday. Sent from my ONEPLUS A5010 using Tapatalk
Lucky you .... mine ordered 1/1/19 still shows "in transit" .... Mike any further work on wireless..... maybe websocket connection ...... still having delays and errors from wireless Nextion.
I guess that is one benefit of living near a major international "hub", but it does come with a cost!
Seems like a global problem:-( I ordered some 3.2in Basic Nextions on 31 December, and they're also still not here. This morning I called the post office and they told me they're still on the way from Johannesburg to Cape Town - for 3 weeks? Maybe they're using Ox Wagons (again)...
I have pushed an updated version of the HMI files for the 3.2" displays to master. These were the only displays impacted from what I could tell. v1.2.2 posted on GitHub, this also includes the fix for the JMRI power bug. https://github.com/atanisoft/DCCppESP32/releases/tag/v1.2.2
Hello Mike, Norm and esfeld: I've managed to get the display working with v1.2.2, although I get the following message on an esp32 reset: .... [DCCppESP32.cpp:187] setup(): DCC++ ESP starting up [E][NextionInterfaceBasePage.cpp:52] display(): display of page 0 was not successful. [DCCSignalGenerator.cpp:124] SignalGenerator(): [OPS] Configuring signal pin 19 [DCCSignalGenerator.cpp:124] SignalGenerator(): [PROG] Configuring signal pin 18 .... Otherwise the display appears to be working, now to run an actual locomotive ... Best Regards, Paul
This is likely a bug in the nextion code that we have fixed already. I'll do some digging and see what I can find. Sent from my ONEPLUS A5010 using Tapatalk
I've managed to get everything running, ... but at a cost ... I ended up frying two EzSBC-esp32 modules via the IBT-2 H-bridge's R_IS pin sitting at about 18V (no idea why), I had a spare IBT-2 on hand and verified voltages (ie 0v) on all pins prior to connecting it to my last (good) EzSBC module... and all worked seems to be working well. Now for some testing... I really appreciate everyone's work on this DCC++esp32 project. BR Paul
Yikes! You might try and save the "fried" boards by feeding 3v3 power to the 3v3 pin, it is possible the 18V supply ended up frying just the voltage regulator IC. Which circuit did you use for interfacing with the IBT_2?
Any news on the loco functions? Is it a problem only for some users? Atani you mention that you have made the change to Esp32 on your layout, does this mean loco functions work on your layout? Best regards Kim
Sorry I have not had a chance to dig into it too deeply just yet. I did a quick test this morning and there is definitely a bug in the function commands coming from JMRI. The function data bytes are not being interpreted correctly from what I can tell. If you hit "F1" in the JMRI throttle it sends "<f ID 129>" which is correct for F1 being enabled but the DCC++ESP32 code is misinterpreting it as: Code: [I][LocomotiveManager.cpp:52] processFunction(): function: 3, 129 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 9 to 1 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 10 to 0 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 11 to 0 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 12 to 0 So I'll need to dig into this later today and get a fix prepared. I thought I had tested this area but it would seem it still has a few bugs. There is also a pretty ugly bug in JMRI in that it will kick out function commands for any locomotive that was active in a throttle, I have not tested to see if releasing the locomotive stops the constant push of functions or not (this functionality is needed for the AVR DCC++ but is not necessary for the ESP32 code) EDIT: JMRI does *NOT* stop sending function packets if you release a locomotive from the throttle UI.
Good to hear that you have narrowed it down somewhat. Regarding the ever repeating commands I can confirm that they keep on being sent, even after releasing the loco, this function was added in the november 2018 jmri update IIRC and for who knows what reason there is no option to turn it off. When testing DCC++ESP32 this avalanche of commands seem to slow down and eventually crash the code/mcu, first resulting in delayed throttle commands and when crashed, the ESP32 needs a powercycle (no watchdog function?). JMRI also needs a restart.
I haven't seen that sort of crash but I wouldn't doubt that there is going to be an eventual crash due to overload of data coming in from JMRI. This "feature" is being tracked here and as shown in that issue there are a lot of problems with it. As for the crash without WDT, that is very unusual and usually indicates some sort of memory corruption going on where the stack end up in a hung state even though it should be restarting. If you can capture a stack trace or console output showing it I might be able to narrow it down a bit. Turns out the fix is a lot simpler than I expected and I will be pushing the fix out shortly. EDIT: v1.2.3 posted: https://github.com/atanisoft/DCCppESP32/releases/tag/v1.2.3
Hi Mike, the EzSBC esp32 modules are definitely toast, the shield over the wroom-32 module gets pretty hot when a supply is connected. I've used the "dcc-signal-split" transistor circuit for interfacing the IBT_2 to the esp32. Also, I've just noticed that the OLED display becomes corrupted after a while: ie instead of TRACK POWER: OFF it shows TRACK POWER: OF(with a bunch of gibberish...). This happens after track power is applied, eventually lines 1 thru 3 also become corrupted. Has this been noticed this before...? BR Paul
I've seen this once or twice but not seen it consistently to be able to narrow it down. I suspect it is actually a bug in the arduino-esp32 I2C code. I'll see if I can reproduce this in further testing. This sounds like a short of some sort on the board, rather unfortunate. Likely related to the voltage regulator being dead and leaving a dead short. Ok great, just wanted to confirm.
This is great! I tested it today and sure enough; lights and engine sound on! However I found that F5-F8 did not work so looking into the LocomotiveManager.cpp code I changed the order of which functions to get checked first and now all functions work! (tested F0-F13) Code: // this is a request for functions FL,F1-F12 // for safety this guarantees that first nibble of function byte will always // be of binary form 10XX which should always be the case for FL,F1-F12 if((functionByte & 0xB0) == 0xB0) { for(uint8_t funcID = 5; funcID <= 8; funcID++) { loco->setFunction(funcID, bitRead(functionByte, funcID-5)); } } else if((functionByte & 0xA0) == 0xA0) { for(uint8_t funcID = 9; funcID <= 12; funcID++) { loco->setFunction(funcID, bitRead(functionByte, funcID-9)); } } else { loco->setFunction(0, bitRead(functionByte, 4)); for(uint8_t funcID = 1; funcID <= 4; funcID++) { loco->setFunction(funcID, bitRead(functionByte, funcID-1)); } } Another apparent bug is that when acquiring a loc in JMRI it seems that when a command is sent, it is sent to both register 0 and 1, resulting in a very confused locomotive that is constantly told two speeds (0 and something else) and two function states (lights are blinking) I captured this in the serial monitor: Code: [I][Locomotive.cpp:66] showStatus(): Loco(1) locoNumber: 2, speed: 43, direction: FWD [I][Locomotive.cpp:66] showStatus(): Loco(0) locoNumber: 2, speed: 0, direction: FWD [I][Locomotive.cpp:66] showStatus(): Loco(1) locoNumber: 2, speed: 43, direction: FWD [I][MotorBoard.cpp:193] powerOffAll(): Disabling DCC Signal for all boards [I][MotorBoard.cpp:58] powerOff(): [OPS] Disabling DCC Signal [I][MotorBoard.cpp:58] powerOff(): [PROG] Disabling DCC Signal One last thing: how do you monitor functions like this? Code: [I][LocomotiveManager.cpp:52] processFunction(): function: 3, 129 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 9 to 1 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 10 to 0 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 11 to 0 [I][Locomotive.h:72] setFunction(): Loco (Addr 3) setting function 12 to 0 In my serial monitor, only track power status and locomotive speed/direction commands are shown.
I'll check the reordered check when I get home. I'll also check the loco 0 and 1 issue. It should only set it up as one instance, likely it is a bug somewhere still to be narrowed down. Sent from my ONEPLUS A5010 using Tapatalk
