[Grbl_Esp32 Issue#22] WiFi Feature Discussion

#1 – luc-github 于 2018-08-21

I could port https://github.com/luc-github/ESP3D-WEBUI for GRBL-ESP32
It is originaly for ESP8266 / ESP32 addon board (like on http://www.panucatt.com/azteegX5minireprap3dprintercontroller_p/ax5mini.htm) but I am already porting it for Marlin-ESP32 FW : https://github.com/luc-github/Marlin/issues/1

I think porting for GRBL-ESP32 will be easier as it use ESP32 SD lib unlike Marlin-ESP32

Not sure if there is space also for Serial commands to configure WiFi, on Marlin I used the reprap ones: https://raw.githubusercontent.com/luc-github/Marlin/esp32/Marlin/src/HAL/HALESP32/ESP32GCODE.txt

Could be a good leverage as lot work is already done.

One comment using AP mode – it is good for initial configuration but it can be easily flooded as computers do a lot of queries in background – many application do some auto check and can make AP busy for nothing as it is the gateway or need to set a fake gateway IP to bypass them

#2 – bdring 于 2018-08-21

@luc-github That is very impressive. It seems like a good starting point. Thanks for the tip on AP mode.

#3 – luc-github 于 2018-08-22

Cool ^_^. Thank you

#4 – luc-github 于 2018-08-22

I will check Grbl_Esp32 code ASAP but in theory need 4/5 entries points if I refer to my experience with marlin porting :
1 – an entry point to init wifi part
2 – an optional entry point in main loop for not critical actions, not mandatory just handy
3 – an optional entry point in gcode interpreter for a set of commands if you want to manage wifi by serial, not mandatory but really handy
4 – a function to inject GCODE manually – may be this function exists already, sorry I did not checked yet
5 – an entry point to catch what is sent to Serial – allowing to get result of commands injected by previous function

I call entry points because if they are defined then any lib, not only ESP3D, could be hooked on them giving flexibility – it will be also an easy way to disable wifi for debug reason for example

just my 2 cents

#5 – bdring 于 2018-08-22

Great. I would suggest using the SD card branch. Having Bluetooth, Serial and SD in the same code might make the existing entry points more obvious to you.

1. Some of the basic inits() are in the setup() function. There are also some in the beginning of the loop() function. The beginning of the loop() only runs after a Grbl reset. At the end of loop(), protocolmainloop(); runs continuously until a reset.

If you only want to init() once, put it in setup. If you want to restart something when Grbl does a soft reset, put it in the top of loop()

2. protocolmainloop() is a good place for non critical actions. This is where Grbl reads from the Bluetooth and Serial ports.

3. gcexecuteline(char *line) is a good place to inject gcode. It is also a good place to put hooks into the wifi code.

4. gcexecuteline(char *line) might do what you want.

5. Incoming serial data read by a task, serialCheckTask(void *pvParameters). basic “realtime” commands are checked and then the data is put in a buffer. The buffer is then read by protocolmainloop().

#6 – luc-github 于 2018-08-22

Excellent ^^ – thank you – looks like everything is ready to start :smilecat:

#7 – luc-github 于 2018-08-22

Hi I have started reading code and I have question:
about 5 – actually is Serial output which is needed, not input but it is ok because I found : void grbl_send(char *text) which looks like what I need

but I see also several part using directly Serial.printf or Serial.print – any reason that print.cpp (mainly) does not use grbl_send ?

#8 – bdring 于 2018-08-22

You are correct. grbl_send(0 should be used. I will fix that soon.

Right now all data, regardless of source is treated the same way. I think eventually grbl will need to know where the data came from.

Like … If Bluetooth asks for status, only return status to Bluetooth.

#9 – luc-github 于 2018-08-22

yes knowing from where the command come from would be nice, so answer would go to same ‘pipe’ and not poluate other ‘pipes’ (Serial / BT / WEB/ etc…) but this may complexify the code – I did it in ESP3D https://github.com/luc-github/ESP3D/blob/2.0/src/espcom.h but ESP3D has a lot of ‘PIPES’
“
typedef enum {
NO_PIPE = 0,
SERIAL_PIPE = 2,
SERIAL1_PIPE = 3,
SERIAL2_PIPE = 4,
#ifdef TCPIPDATA_FEATURE
TCP_PIPE = 5,
#endif
#ifdef WSDATAFEATURE
WS_PIPE = 6,
#endif
#ifdef ESPOLEDFEATURE
OLED_PIPE = 7,
#endif
WEB_PIPE = 8,
PRINTER_PIPE = 9
} tpipe;

“

#10 – bdring 于 2018-08-22

That might be why I didn’t get the [FILE:…] response in Grbl Controller (Bluetooth) 😄

#11 – cemir 于 2018-09-13

Hi , would like to help here too,

I’m currently in the process of creating a drawing machine (kind of AxiDraw clone) with an integrated user interface.

So my id was to build some kind of webapp running on the ESP, allowing a user to upload GCODE to SD card and providing a way to start the print from sd. + simple controls (like a very simplified octoprint)

The only “negative” point : I have no idea on how this will affect performance, so I’ll try to create a POC first.

Also, on boot, the board will try to connect to a configured SSID, if failed or no SSID configured, it will boot in AP mode, allowing users to connect to it and configure it.

Let me know if I can help with the wifi/webserver part please let invite me to slack.

#12 – luc-github 于 2018-09-13

Hi the WiFi part is currently here : https://github.com/luc-github/Grbl_Esp32/tree/SyncWebServer
still need some tuning but almost feature are there

the Web UI is here : https://github.com/luc-github/ESP3D-WEBUI/tree/GRBL_ESP32, I am now working on it and hope to finish next week

please feel free to test and feedback

#13 – bdring 于 2018-09-13

@cemir Here is an invite link.

The WEBUI is getting very close to completion. It did take a lot of experimentation to make sure nothing affected the performance.

#14 – jeffeb3 于 2018-09-15

Have you seen cnc.js? I don’t know if it could be compressed small enough to live on the esp, but it would be also be awesome if you made a cnc.js plugin (or maybe it already supports the websockets? Maybe use that for PC/Linux application? I would think loading and running gcode from the esp/sd card would be more reliable than streaming over websockets during an operation.

#15 – bdring 于 2018-09-15

@jeffeb3 Thanks for that suggestion.

We can probably support cnc.js, but not put it on the ESP. It is probably better to allow programs like that to connect using their existing websocket method.

#16 – luc-github 于 2018-09-15

about cncjs
the src + static directories compressed give 1 436KB which is really over current SPIFFS capacity, so need some work to adjust to fit size I think

I also think it need also a big rewrite to be executed from ESP itself and monitor SD printing instead of being a host because I fully agree that :
> I would think loading and running gcode from the esp/sd card would be more reliable than streaming over websockets during an operation.

#17 – bdring 于 2018-09-16

Closing, starting as a fresh issue about ESP3D Web-UI