GrblHAL WebUI 3.0 unable to parse $$ settings from controller

[troth530]

Hi @terjeio
Using ESP32 device with WebUI 3.0.0.a37.GH2
grblHAL firmware 1.1f-20230501

Device is ESP32 Wroom dev board
Using 4 axis WebUI is unable to parse data.

If 4th axis is used as Ganged (for instance Y2) parsing will report the settings for 3 axes, but not the 4th axis. In this case no parsing error is returned.

Thank you!

[luc-github]

Please provide the full [ESP400]json=YES output

[terjeio]

It works for me with four axes enabled. Post your CMakeLists.txt?

[luc-github]

@troth530 any update ?

[troth530]

Hi @luc-github and @terjeio, I cannot determine what conditions cause this. Mostly parsing does not work. I don't know if it's because the GUI changes based on what settings are enabled or now.

[terjeio]

Retested with latest versions and it still works for me with four axes enabled. Post your CMakeLists.txt or if firmware made with the Web Builder Save board and post the the saved board file (zip first).

[troth530]

Hi @terjeio, I will try with the latest version, but the parsing seemed to toggle with 4 axis vs 3 axis a few weeks ago, but now it is not repeatable and typically will not parse. Attached is my CMakeLists.txt, keep in mind that I am being very pin economical. So probe cannot be used when TMC2209 UART is enabled, also I do not use a flood pin. As mentioned in the other issue https://github.com/grblHAL/Plugin_WebUI/issues/10 I am having issues with SD card and these could be related, so if you post your CMakesList.txt and bin file I can back track what is causing the issue.
CMakeLists.txt

Thank you!

[terjeio]

I see you have a custom map file, you have to share that as well. And this could be the reason for the slow SD card access - if you are using different pins for SPI than the optimal ones.

[troth530]

Hi @terjeio, I am trying to build bare bones and just with the SD card and the WROOM device currently to debug the slow SD card issue which may be related to the parsing. I am definitely not changing the SPI pins.

I tried building with the web builder with grblHAL build 20230711.
ESP32, CNC BoosterPack, WebUI 3 which enables Wifi and EEPROM-No
I get this error:
main/wifi.c:471:17: error: implicit declaration of function 'ssdp_stop'; did you mean 'ledc_stop'? [-Werror=implicit-function-declaration]

Thank you!

[terjeio]

I get this error:
main/wifi.c:471:17: error: implicit declaration of function 'ssdp_stop'; did you mean 'ledc_stop'? [-Werror=implicit-function-declaration]

Oops, I forgot to add a guard for SSDP code - fixed now. Also, I forgot I have used a I2C I/O expander for the CNC BoosterPack MB - so a build would likely fail to start. Test with the MKS Tinybee V1 instead.

[troth530]

Hi @terjeio, on the latest build whether compiled through Wed or ESP-IDF it does not appear wifi is working at all. No SSID is being broadcast in AP mode and in Sta mode it will not attempt to connect to the router (after setting $73=3, $74,$75). Latest build I used that had wifi working was [VER:1.1f.20230501].

Also, I tried several boards and tried to keep the simplest settings no chnages to mapfiles and only making changes to CMakeLists.txt with WiFi, SoftAP, FtpDaemon, WebUI, SDcard all turned ON. I always clean before compiling.

[terjeio]

Both a local build and a Web Builder build works as expected for me, something on your end is messed up?
It could be corrupted settings? The single byte settings checksum is not very robust, I've had problems with corrupted settings before, a reset with $RST=* may help.
An issue is that the default AP password is too short - I'll fix that in the next commit.

Tip: instead of modifying an existing board map file rename the one you want to modify to my_machine_map.h and enable that in CMakeLists.txt. This way your changes will not be overwritten on an update.

[troth530]

Hi @terjeio, I will try, but my goal is to use a WROOM with SD breakout bare bones to figure out why SD card writes are so slow and figure out the parsing issue on WebUI.

I am using the same bare bones with SD breakout hardware setup that wifi works fine with [VER:1.1f.20230501]. Are you still using the same bare bone WROOM and SD breakout board? I could have something weird going on with my PC and network or WROOM device, but frankly I doubt it.

Maybe you can post your webuilder output or grbl.bin from the build folder.

[terjeio]

Web Builder firmware running:

firmware.zip

Sloppy wiring? But working...

I started WebUI via SSDP and uploaded a 4.8 Mb test file, ~30 secs.

[troth530]

Hi @terjeio. I don't understand SSDP yet, so we'll have to leave that alone for now. I am trying to connect through AP (or STA) and then upload. But I can't even get to the WebUI because the wifi is not starting up as far as I can tell.

I do a full clean, ESP erase and $RST=* each time I program for hygiene and sanity. I'm using ESF-IDF 4.3 Powershell for the downloaded code and for uploading Webbuild bin files I use esptool.exe and a script.
idf.py -p COM3 clean
idf.py -p COM3 erase_flash
idf.py -p COM3 flash (or build)

With the bin file you posted I programmed a couple devices (one with and one without the SD breakout) each with different USB cables and tried on a couple PCs. Momentarily the SSID I saw in available networks was ESP_xxxxxx (I can't recall the exact number of digits but each letter was Hex as far as I could tell. Then that SSID disappeared and never showed again. I then tried setting $73=3 and set $74/$75 and it would not connect to my router. I tried this with an ESP WROM device hard wired to SD breakout module and powered through USB and also on an ESP WROOM just connected to USB. I also saw a similar result with your latest build using ESP-IDF and manually making necessary changes to CMakeLists.txt to enable SD and WebUI for testing. And using my map file was of no help.

Maybe the ESP gods are mad at me, but I will keep hammering away at this, but best I can tell is that there is something that has changed with the latest code (since May 1) because that May 1 code still works.

Thank you!

[terjeio]

I don't understand SSDP yet

"grblHAL" should show up in the "Network" display, clicking on the icon should open the WebUI (if enabled).

The device properties displays this info:

Momentarily the SSID I saw in available networks was ESP_xxxxxx (I can't recall the exact number of digits but each letter was Hex as far as I could tell. Then that SSID disappeared and never showed again.

The default SSID ($76) is grblHAL_AP, did you change this? And the default password ($77) is too short and should be changed (>= 8 chars).

Maybe the ESP gods are mad at me

Perhaps there is a WiFi channel clash? I should add a setting for channel selection?

but best I can tell is that there is something that has changed with the latest code (since May 1) because that May 1 code still works.

IMO there are no changes to the WiFi code that should change the basic functionality.