ESP32 Command Station

Atani Dec 10, 2017

  1. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    On the development branch everything had moved over to IDF v4.0 which uses cmake. Setup your build env via https://docs.espressif.com/projects/esp-idf/en/v4.0/get-started/index.html. make sure to use the v4.0 branch/version.

    After setting up IDF v4.0 you can run: idf.py menuconfg build flash monitor

    I haven't fixed up the Nextion code yet (compiles but will likely crash at runtime). LocoNet will not compile (and in the near future won't be usable, will be disabled for v1.5.0). I believe all other functionality is wired up and functional now.

    I'll be doing more testing this weekend now that I have a working build env and will be doing final testing of the PCBs, there will be a delay in restock of parts due to sourcing of some components being problematic. I'll be placing some orders soon but no eta for availability.

    Sent from my ONEPLUS A5010 using Tapatalk
     
  2. John Flanagan

    John Flanagan TrainBoard Member

    38
    5
    4
    I managed a build of the new code. The idf code is not easy to load. It appears it assumes that you have loaded it before. I.e. things got a lot better after I deleted all of the downloaded code, but left cmake etc. and started fresh.
     
  3. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    Yeah, it isn't 100% easy just yet. I'm working on an updated set of instructions and working on porting a few areas over still, Nextion will crash and LocoNet is not yet ported. I will be making a few more major tweaks to the config process to hide known broken parts and see if I can speed up the builds, it seems that the compilation of at least four or five cpp files take up to 10min to compile whereas the same files compiled in under a minute previously. I'm also actively working on compatibility updates after testing with the new TCS UWT-100, the throttle usually works but there are a few issues with timeouts that need to be sorted out still.

    On a positive note though, the CS seems a lot more stable with the updated LwIP build and the LCC hub works pretty well now. It isn't 100% speed but reasonable for small usages.

    Sent from my ONEPLUS A5010 using Tapatalk
     
  4. Jason Willeford

    Jason Willeford New Member

    3
    0
    1
    Atani,
    New TB user here. I couldn't decide on starting a new thread or adding to this one, I hope I'm not breaking any etiquette here.

    First, love this ESP32 Command Station! Wireless, when it works, is always preferred over a wired connection. I've completed a build, readme file is well done, thanks! Seems everything is working as it should...until I try to use a standard JMRI throttle, I can't get it to do anything to the CS. I know JMRI is communicating to CS because the DCC++ traffic monitor is reporting good data. Any thoughts? I have used JMRI before, currently Loconet PR3 is also connected to JMRI, but I know just enough to be dangerous.

    Thanks,
    Jason
     
  5. Jason Willeford

    Jason Willeford New Member

    3
    0
    1
    Well, as a test I disabled the Loconet connection so I could rule that out. Doing so allowed me to control a locomotive with the JMRI throttle. However, the throttle speed is not correct, at 100% throttle the locomotive seems to be running at 7-10%. In addition, the locomotive responds very slowly to throttle and function commands. It takes about 5-6 seconds for a function command to be registered by the locomotive. In contrast, the web throttle?, is more responsive and the correct speed, however, functions are not working. FL (forward light?) does not light up the locomotive, JMRI throttle light function does work.
     
  6. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    JMRI has configuration options to define how it should handle certain activities, such as the throttle commands. You might need to reconfigure JMRI to send commands primarily to the DCC++ connection.

    can you capture the DCC++ monitor output from JMRI to see what it is sending to the CS? It should be defaulting to 128 speed steps but it might be sending them as 28 speed steps instead.

    Are you using the latest "master" code or v1.2.3? If you are using master I would suggest switching back to v1.2.3 as it is the last stable release.

    This likely is a case where the web throttle failed or timed out sending a command to the CS. This can be confirmed via the browser console (typically this can be brought up by hitting F12), you likely will see a few failed requests in the request list.
     
  7. Jason Willeford

    Jason Willeford New Member

    3
    0
    1
    Thanks! I figured I could point the throttle at a specific connection...I'll keep reading documentation.

    I'll check that.

    I downloaded "master" however I feel I saw v.1.2.3 somewhere, but the zip file is labeled "master".

    Ok, thanks, I'll check that too.
     
  8. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    Hi,
    should it work with S88 enabled too? As I am getting this error: https://paste.ubuntu.com/p/bWWj4ZkC6f/

    At the moment it seems I am able to build with with WiFi (haven't tried flashing it yet since I have only now been able to make the code to build on my computer), but when I enable S88 and reuse the same pin numbers as here: https://github.com/atanisoft/ESP32CommandStation/blob/master/include/Config_S88.h then it fails with the above ^ errors.

    Thank you
     
  9. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    I haven't tested with S88 outside of compilation yet, I did run into some compilation issues a bit ago with splitting up the content but I do not see those issues at this time. I'll do some further testing and have any needed fixes pushed to GitHub soon.

    The default pin mappings should have been carried over to the menuconfig entries automatically. I suspect there are some lingering bugs in the S88 code since I have fully dropped the Arduino dependencies so there may be a few things to fix up in S88 still. I'll do some further tests.
     
    zubozrout likes this.
  10. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    It could be that I have perhaps selected something wrong in the menuconfig, maybe it needs more than just enabling GPIO pins to be used as sensors + enabling S88 and setting the pins as noted above.

    By default these are empty and if kept empty I am getting this:

    Code:
    warning: the value '' is invalid for S88_CLOCK_PIN, which has type int
    warning: the value '' is invalid for S88_RESET_PIN, which has type int
    warning: the value '' is invalid for S88_LOAD_PIN, which has type int
     
  11. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    Looks like the defaults got missed somehow. Let me add those in.
     
    zubozrout likes this.
  12. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    I've tried to look into it a bit but it seems it is out of my reach. I haven't been able to find the cause of this error:
    Code:
    error: 'S88BusManager' has not been declared
    in the main/ESP32CommandStation.cpp file :(

    Although it is interesting that:
    Code:
    S88BusManager::init();
    doesn't trigger as CONFIG_SENSORS is not true. So the above error only applies to S88BusManager mentions later in the file.
    (I've pasted the whole log earlier ^)

    If I overwrite CONFIG_SENSORS to true at the top of the file
    Code:
    S88BusManager::init();
    also triggers the undefined error message.

    It feels like CONFIG_SENSORS should be set to true if it has anything to do with the "Enable GPIO pins as sensors" menuconfig option - and that option seems to be turned on in there as well as its nested S88 setting. But maybe it works differently, I don't know.

    Anyway, I've updated to the latest development branch. The S88 values now seem predefined correctly (at least these refill if I clean it, re-save, exit menuconfig and enter it again). Thank you :). Unfortunately building it with S88 enabled still doesn't seem to work for some reason :(.

    I am now also attaching my sdkconfig (remove the ".txt" extension if used as it was a requirement for the local forum attachment) in case it is in any way useful. And to be honest I am unable to find anything sensors/S88 related in there so maybe the file was wrongly generated using menuconfig :(.

    Best regards,
    Martin
     

    Attached Files:

  13. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    The sdkconfig.h looks correct, there seems to be a missing include file at the top of the ESP32CommandStation.h file.
    Near the top of the file locate the Sensors.h line and add the following after it:
    Code:
    #include <S88Sensors.h>
    
    That should fix it up.

    The naming is CONFIG_ENABLE_SENSORS since I wasn't sure if CONFIG_SENSORS was used by IDF but I don't think it is. I will very likely shorten this before v1.5.0 is released to just CONFIG_SENSORS and CONFIG_OUTPUTS, perhaps even combining these into a single set CONFIG_GPIO or similar.
     
  14. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    Hi,
    thank you very much for your reply. I actually tried including S88Sensors.h at the top of the main ESP32CommandStation.cpp file, but am getting these errors then:

    Code:
    ../components/GPIOSensors/include/S88Sensors.h:101:36: error: redefinition of 'class S88BusCommandAdapter'
    A more complex log here, didn't want to flood it in here: https://paste.ubuntu.com/p/CFXMVnN8Gy/
     
  15. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    That is an interesting one, not sure how it got missed before when I was testing.. You can fix it by removing this line, I will push this change shortly. I will also be updating the sdkconfig.defaults file for CONFIG_DISPLAY_SDA which is currently defaulted to 23 and boards other than TTGO-T1 use this pin by default (TTGO-T1 has an LED on that pin and it sometimes causes I2C corruption).

    EDIT: looks like there are a few other issues with enabling this. I will have an update on GitHub shortly...
     
    Last edited: Mar 15, 2020
  16. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    Thank you very much :).
    It now builds just fine and I can flash it.

    Apparently though when flashed (and I have completely cleaned both the local repo on my pc [and fetched it again, including build directory], as well as the ESP32 board flash using the `erase_flash` command) ESP32 reboots itself in a loop when connected only via USB and I am trying to monitor it. Then I am getting the attached error: panic.log.txt - but I suppose it may need more power or there is just something unexpected going on when accessing the unpowered motor shield or whatever. Anyway, it works when powered directly with my 12V input so am attaching this just in case you are interested to see what may be wrong but it doesn't seem to be a blocker in any way :).

    But I am afraid I still seem unable to power the DCC track. On my motor shield: "L298P Shield R3 DC Motor Driver" board the DCC track output LED indicators light up just fine, but none of the accessories attached powers up with it :(.

    Maybe it has something to do with this?

    Code:
    [Config] Found existing CS config file, attempting to load...
    [Config] H-Bridge configuration not found.
    [Config] Existing configuration failed one (or more) validation(s) and will be regenerated!
    [Config] Generating default configuration...
    but L298 is the default in menuconfig and I have not changed that. So should have the right board configured. I can also safely say that with the older versions of the ESP32 Command Station it worked just fine on my end.

    I am also getting a 404 answer for the S88 tab in the web UI:

    Code:
    Incoming connection from 192.168.1.29, fd 51.
    [Httpd fd:51,uri:/s88sensors] Unknown URI, sending 404
    [Httpd fd:51,uri:/s88sensors] Processed in 12 ms (404).
    But that may work in JMRI, though haven't tried because of the above track power issues.
     

    Attached Files:

  17. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    This usually means there is a problem with the cached config or something that is expected to be present is not..

    The error in panic.log.txt looks like a bug, it is looking for an HC12 config node that doesn't exist in the config map. I'll have an update for it shortly.

    This is a bug, there was a couple checks in place that were no longer relevant and needed to be dropped. I've dropped these and will push the update shortly with the other fixes above.

    I'll check this out, I suspect it is something very basic missing to enable the S88 endpoint.

    JMRI doesn't know anything about S88 via DCC++ protocol. S88 sensors will be reported to JMRI as a standard sensor so you will be able to use them in JMRI but you will not be able to configure them within JMRI, you will need to use the web interface to set them up.
     
  18. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    This is great, thank you. Now I have the power on :).
    But still, switches doesn't seem to turn (I haven't tried running an engine yet). Unfortunately though this is the only thing that I can see when monitoring:

    Code:
    Incoming connection from 192.168.1.29, fd 51.
    [Httpd fd:51,uri:/turnouts] Processed in 14 ms (200).
    Incoming connection from 192.168.1.29, fd 51.
    [Httpd fd:51,uri:/turnouts] Processed in 15 ms (200).
    [OPS]      0 mA / 2000 mA
    [...]
    [TaskMon] uptime: 00:02:15 freeHeap: 170092, largest free block: 113792, tasks: 15, mainBufferPool: 464
    Incoming connection from 192.168.1.29, fd 51.
    [Httpd fd:51,uri:/turnouts] Processed in 14 ms (200).
    [OPS]      0 mA / 2000 mA
    [...]
    Incoming connection from 192.168.1.29, fd 52.
    [Httpd fd:52,uri:/turnouts] Processed in 70 ms (200).
    [OPS]      0 mA / 2000 mA
    [TaskMon] uptime: 00:05:15 freeHeap: 168808, largest free block: 113792, tasks: 15, mainBufferPool: 464
    [RMT] Shutting down RMT for OPS
    [OPS] Disabling track output
    [RMT] Starting RMT for OPS
    [OPS] Enabling track output
    Incoming connection from 192.168.1.29, fd 52.
    [Httpd fd:52,uri:/turnouts] Processed in 76 ms (200).
    [OPS]      0 mA / 2000 mA
    As for the S88 part, this now seems not to fail, thank you. I haven't been able to test that yet though as my settings won't save (could be that my wiring is not correct or I am not entering the correct values, though I've been trying to make the wiring right). At least the power is working on the S88, but that's unrelated to the software on the ESP32.
     

    Attached Files:

  19. Atani

    Atani TrainBoard Member

    1,132
    679
    23
    What are the settings you are using and how are you setting them?

    Modify this line from VERBOSE to INFO and it should print out when turnouts are being set (thrown or closed), I'll add this a few other pieces to menuconfig shortly to make some of these sort of things easier to debug. How are you defining the turnouts and throwing them, is it via the web interface?
     
  20. zubozrout

    zubozrout TrainBoard Member

    20
    1
    2
    Hi,
    first of all I'd like to apologize for the delay, but have been quite busy lately.

    As for your questions:
    I am leaving everything default, except changing data pin to 13 which is where I have this connected, have also tried data pin 12. And have tried altering the sensors count but that didn't help. The log doesn't seem to give me any errors, just
    Code:
    [S88 Bus-0] Created using data pin 13 with 0 sensors starting at id 512
    but the web UI always pops this alert once saved or upon hitting the S88 refresh list button: "Failed to load url:" and I have this in the web dev console:
    Code:
    Failed to load url: parsererror index.html:653:45
    refreshing: Sensors (S88) index.html:1303:10
    Could be that I am setting something wrong but am not sure what.

    Yes, it is via the web interface. Then for every turnout no matter the ID I get this:

    Code:
    [Turnout 2] Set to Closed
    [Httpd fd:52,uri:/turnouts] Processed in 71 ms (200).
    Incoming connection from 192.168.1.29, fd 52.
    [Turnout 2] Set to Thrown
    [Httpd fd:52,uri:/turnouts] Processed in 81 ms (200).
    Incoming connection from 192.168.1.29, fd 52.
    So it seems no exception is thrown yet the switches won't move despite them being powered up. Each DCC decoder has a red light on it so the power is in but there seems to be no signal coming to them. Same settings work on older DCCppESP32.

    Switching via JMRI is the same too:
    Code:
    [Turnout 1] Set to Thrown
    [Turnout 1] Set to Closed
    
    No error but switches not thrown.

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

    Then I've tried to run my engine to test it a bit further and am unable to power the tracks at all now. The LEDs on the motor shield shine but no power goes to the tracks. And that even despite this log entry:
    Code:
    [Track] Enabling track output: OPS
    I don't see any error for that either. But in the Web interface the Status doesn't change from Off. JRMI also displays the same Off status when closed and launched again.

    To avoid any collisions I've disconnected everything from the ESP32 board and only connected my single piece of track directly with no sensors and still there was no power in my tracks so engine didn't run. But even my more complex setup with everything connected does work with the older version of DCCppESP32 (not counting in S88 sensors, that I have not been able to make work anywhere yet).

    I wonder if the fact switches don't turn for me is not still related to the tracks powering problem :(. I am not sure why the switch decoder lights were shining for a while after flashing but disconnecting and connecting the ESP32 to power again seems to have broken it and from now on I don't seem to be able to power anything up (not even after re-fashing again). And I have experienced that earlier too and also haven't been able to fix it but when I got to it now it again worked for a while.

    So apparently there is something going on wrong with the development branch but I don't even have a vague idea what could it be. This was all tested with the latest code out there in the development branch.
     

Share This Page