[Question] WebUI 3.0 is out for GRBL any plan for grblHAL_ESP32 ?

[luc-github]

Hello, I like the grblHal approach and thank you for using my webUI ^_^ I am very proud you chose it 😸

Sorry to push my question here if it is not the right place, but I do not see discussion panel and cannot find Discord/Gitter Server for questions.

I am working on WebUI 3.0 which is more target oriented, it has smaller footprint and more features compare to previous version, several are dedicated to GRBL, I see you use the webui 2.1 which not actually really GRBL oriented but adapted from 3D printer version, at this time I was very new to CNC world (still learning a lot...)

Do you have any plan to support the WebUI V3.0 ? - I can help on changes as backend has several changes that need to be done, be noted 3.0 is not backward compatible with 2.1 due to these changes, but benefits are real vs current 2.1

List of current features (more will come) : https://github.com/luc-github/ESP3D-WEBUI/blob/3.0/Features.md

Let me know if is planed, so I could had a grblHAL target to V3 and support specific needs for grblHal , and also propose a PR for it if you want😸

[terjeio]

Sorry to push my question here if it is not the right place, but I do not see discussion panel and cannot find Discord/Gitter Server for questions.

I'll prefer to use github (or sometimes private mail) for discussions as this keeps it accessible for all. I can enable github discussions for the repos that currently does not have them enabled.

Do you have any plan to support the WebUI V3.0

I am currently running it against grblHAL on a Nucleo STM32F756 board via ethernet using my own networking protocol code. I'll have to backport the backend changes needed for the ESP32 driver as this uses the ESP32 IDF protocol code.

Let me know if is planed, so I could had a grblHAL target to V3 and support specific needs for grblHal

Great, it was my plan to contact you about some issues I have encountered and if you would accept a PR for adding grblHAL support.

[luc-github]

I'll prefer to use github (or sometimes private mail) for discussions as this keeps it accessible for all. I can enable github discussions for the repos that currently does not have them enabled.

If you have discord account feel free to ping me, sometimes to chat is faster than email to setup things, then tracking can be down after on github more clearly

I am currently running it against grblHAL on a Nucleo STM32F756 Ho you already use the V3 on STM32 ? - many things changed vs 2.1 and it is not documented, wow you are efficient !!! ^_^

Great, it was my plan to contact you about some issues I have encountered and if you would accept a PR for adding grblHAL support. Sure PR are always welcome, current GRBL version should only need to add SD card access if any which is trivial to add in V3

I did not compiled grbl_hal yet but I liked the aproach to use the async IDF web server encapsulation, it should be faster than sync webserver

I will take some time to setup env as I have a MKS DCL32, but you mention your porting is using STM32, so I am curious how FS is handled as I want also to propose to move to LittleFS instead of Spiffs, I am very excited to see all this ^_^

[terjeio]

If you have discord account feel free to ping me

I do not have one - and I am wary about free services as I become the product when using them... I am on Skype though.

Ho you already use the V3 on STM32 ? - many things changed vs 2.1 and it is not documented

I use your source code, browser debugging for network traffic and debugging for the MCU to reverse engineer what is needed.

I did not compiled grbl_hal yet but I liked the aproach to use the async IDF web server encapsulation, it should be faster than sync webserver

For grblHAL it will be possible to send async messages over the websocket connection, that will be simpler to implement than async http requests? IMO it could be done by adding "webui" as an additional protocol on the websocket connection request.

I am curious how FS is handled

I have two virtual file system implemenations on top of FatFS, I want to consolidate those into one and add a mechanism for dynamically adding file systems to that. When done then the WebUI backend does not need to know what kind of file system it is talking to.

[luc-github]

I do not have one - and I am wary about free services as I become the product when using them... I am on Skype though.

Well discord is just an easy tool like github 😸, in case you change your mind, here an invite to join ESP3D WebUI discord server: https://discord.gg/f7DnNgs

use your source code, browser debugging for network traffic and debugging for the MCU to reverse engineer what is needed.

wow, you should asked me , it would save your time

For grblHAL it will be possible to send async messages over the websocket connection, that will be simpler to implement than async http requests? IMO it could be done by adding "webui" as an additional protocol on the websocket connection request. the webUI is currently using http queries to send commands / doing file upload and only websocket for stream answers and for some internal message, rewriting webui to use only websocket won't be a simple task, when it is definitly possible

about async support - I have put on hold the http async support when using AsyncWebServer because I had several data loss and stability issue and the repo was not really maintained because main dev is too busy with ESP32 core maintenance/dev, I had several discussion with him but he was overloaded so I used sync webserver which is slow but at least reliable and common between esp32 / esp8266 For ESP3D I plan to drop esp8266 support in favor of esp32 for v4, esp8266 is supposed to be end of life pretty soon and replaced by esp32 C3/S2 so I can I was hoping to switch to esp_http from esp32 which is async but hoping having good performance and also may be allowing https on the way

Does the esp_http server has some issue per your experience ?

I have two virtual file system implemenations on top of FatFS, I want to consolidate those into one and add a mechanism for dynamically adding file systems to that. When done then the WebUI backend does not need to know what kind of file system it is talking to.

I did something like this in ESP3D V3, and it include a Global FS that allow to parse /SD and /FS from same root, this part need a big refactoring and cleaner code but it is working as I need to support SPIFFS esp8266 / LittleFSesp8266 / FatFS ESP32 / SPIFFS ESP32 / LittleFS ESP32 / SDMMC ESP32 / SDFat V2.x from https://github.com/greiman/SdFat and plan to add USB support from https://github.com/djuseeq/Ch376msc

I will look to your implementation to see how you did - should be better than mine for sure as I did quick en dirty as FS came one by one eacch time with different features and API ...

I have created a topic also on my side : https://github.com/luc-github/ESP3D-WEBUI/issues/252 for the webUI part

[terjeio]

rewriting webui to use only websocket won't be a simple task

IMO you could still use HTTP for infrequent commands as these do not impact performance much? What I was thinking about was to push automatically real time reports, $G reports (there is an option in grblHAL to push these following a real time report if there are any changes) and possibly the ESP701 response over the websocket connection. This would stop all HTTP requests until there is an UI interaction?

Does the esp_http server has some issue per your experience ?

To be honest I am no big fan of the ESP32 at all - the IDF framework seems buggy/unstable and it is not easy to debug. A very expensive (in terms of man hours) platform to work with due to this.

I will look to your implementation ...

Be aware that I am not using any Arduino/ESP IDF libraries at all for the WebUI plugin. This to allow it to be used with MCUs not supported by these - the plugin depends only on lwIP and FatFS implementations beeing available.

[luc-github]

MO you could still use HTTP for infrequent commands

if it is for realtime commands only there is no issue for sure I think ESP701 is only for stream from ESP3D to GRBL - and in your case you better use the SD commands no ?

To be honest I am no big fan of the ESP32 at all

Yes IDF is more maintained than arduino so I can imagine it has stability issue, when arduino got some stability due the inertia of update - but I saw you use 4.3.1 when 4.4.1 is used by arduino, I use 4.4.0 based since a while and it is ok, so may be 4.4.1 is necessary update ?

Be aware that I am not using any Arduino/ESP IDF libraries

Yes I know - I am not worry for that - that also my idea as I may explore others MCU than ESP also

That said I am trying the current grbl_hal and the compilation is ok

I see you choose to set the Webui as default page and not support the maintenance page, but I also can see the webserver is very fast wow

I need to change my setup I am always on error 18 and reset all the time in STA mode

[terjeio]

Closing this as grblHAL WebUI v3 support is now nearly finished. It is also available for a number of other grblHAL drivers such as iMXRT1062, RP2040, STM32F7xx, STM32H7xx and MSP432E401Y.

[luc-github]

thank you ^_^