PCB and Engraving Milling autoleveling [FEATURE REQUEST]

[leadgtr7]

Is your feature request related to a problem? Please describe.
I would like the ability to probe a surface and modify the loaded g code to account for surface inconsistencies

Describe the solution you'd like
I'd like to be able to specify a grid of points that could be probed and generate a mesh. this mesh could then be used to correct uploaded gcode files to account for z height inconsistencies. This mesh should be able to be applied to multiple files via a button and the height should be able to be downloaded for future use.

Describe alternatives you've considered
Right now the only work around is to attached the GRBL ESP32 to a computer and run one of the programs that can do this. These are
OpenCNCpilot, bCNC, Universal G code Sender.

Ideally I would like to be able to run this self contained

Additional context

[github-actions]

Thank your for submiting, please be sure you followed template or your issue may be dismissed.

[luc-github]

Hmm reading what you describe and https://github.com/martin2250/GrblHeightProbe2
It seems unlike 3D printer which have autoleveling feature in FW - it is in GRBL a post GCODE process - I am right ?

In that case the web UI is not the best place for this IMHO, it can be done but won't cover most of use and also looks weird

the web UI could generate the needed mesh file for the autoleveleing but post process gcode file will lead to some problems:

• when need to apply post process ?
  for each new mesh file generated and for each original GCODEfile, so we need to always keep the original file on SD and generate a post processed file, which means:
  • download the original file from SD
  • post process the file
  • upload back the file to SD
  • start post processed gcode file
• need to distinguish in webUI files list of the processed from the not processed files
• what would be the way that user select to post process a gcode file to avoid confusion with direct job an already post processed file or just start original file
• if you do not using SD - autobed leveling cannot be applied because it is not done on the fly unlike 3D printer or it will slow down the job
• if you send command to start original file from SD but not from webUI, won't be applied neither

I definitly understand the need, but I think it is not trivial implementation due to current GRBL capabilities, also if WebUI has some slicer capabilities this would may be also more simple but there is none currently,

@leadgtr7 did I misunderstood the usage/flow ?
if webUI help to generate the mesh file, does it help with current process ?

@bdring any comment on this ?
In 3D printer autobed leveling is done at FW level, so it smooth, mesh matrix is stored in EEPROM and change are done on the fly but I know you already have a lot in your huge todo list ^_^

[leadgtr7]

@luc-github I think you understand perfectly.

Based on your comments I would think a blended approach could be best. If the web ui could generate a mesh file that something like opencncpilot could load and process then you could upload the processed file back to the web ui. I think that would be a good work flow.

[luc-github]

I will be put in 3.0 todo list then - need to do some check what GCODE serie to use and and what is the expected output format expected to be used with opencncpilot

[DeeEmm]

Good to see that this is planned. I've been looking for a solution for auto bed levelling that can be integrated into Grbl_ESP32 (which uses ESP3D). As you may know, bed levelling is a requirement for PCB milling.

I don't think that openpilot is a good solution simply as it is a windows only program, which leaves all of us Mac and Linux users without a solution. :(

TBH I think it would be great to see a direct integration rather than relying on an external program. The actual processing can be carried out by the browser and host computer, there's no need to do it on the ESP32.

A solution that might be worth looking at is the CNCjs plugin cnc-kt-ext.

The bulk of the processing is done in the autolevel.js file and it is fairly easy to pick up on the process.

Simplistically it sends the GCode commands via the regular GCode serial port sender to move the machine and perform the search. The results are stored in an array. The GCode file is then parsed line by line and the Gcode x,y coordinates compared with the array values, it then applies the matching Z correction and rebuilds the gcode file. Once the Gcode file has been parsed the updated file is sent to the machine.

It also looks like the z values are interpolated using the nearest three x,y points to the Gcode file coordinates and adjusting the Z value accordingly.

I think that without too much modification this solution could be implemented in ESP3D. Or maybe ESP3D could be modified to accept plugins?

Happy to help with testing / development

/DM

[luc-github]

@DeeEmm for direct integration, it better to push the request to GRBL_ESP32 repository, GRBL_ESP32 do not use ESP3D code anymore, it now only use webUI of ESP3D, the main code is totally different because the GRBL_ESP32 dev team rewrote deeply the firmware

[DeeEmm]

Ahh okay. The GRBL_ESP32 Wiki states

The ESP3D-WEBUI project has been modified for use with Grbl_ESP32 by Luc of luc-github

Is that not the case?

The proposed change mostly relates to the WebUI, it is largely platform agnostic and so would benefit any platform that utilises ESP3D.

[luc-github]

ESP3D-WEBUI is web interface, it used by GRBL_ESP32 firmware, ESP3D firmware, ESP3DLib library used in Marlin Firmware,
so my answer was about
I've been looking for a solution for auto bed levelling that can be integrated into Grbl_ESP32
for possible integration in webui, approach is differente,

[DeeEmm]

I think you are getting confused. I have edited my orignal post to clarify. Please re-read it.

I am asking about integration into ESP3D-WEBUI for auto bed levelling. My comments relating to Grbl_ESP32 are just to explain how I ended up here.

I understand that ESP3D-WEBUI is a web interface.

I think that integration of auto bed levelling would be a good upgrade, and also not impossible to achieve given that the hard work has already been done in the CNCjs plugin (also a web interface functioning in a similar manner as ESP3D-WEBUI).

I hope this clarifies.

It would be good to understand if this is something that may be considered.

/DM

[luc-github]

I need to check what is done by the pluggin you mention, but cncjs is a gcode host streamer when esp3d-webui is just a remote ui so I need to see how to do the integration

[DeeEmm]

The cnc-kt-ext plugin documentation seems to imply that it is updating the entire file, not modifying streamed Gcode commands on the fly. The following is from the README file

Without any options it will probe every 10 mm, with travel height at 2 mm, and probing feedrate 50 mm/min.
Once the probing is finished and gcode updated you may run the gcode.

I've only had a cursory glance through the code but I'm guessing that it is updating the file before it is sent. Assuming this is the case the ES3D-WEBUI would require that the file be read from the ESP32, modified and then sent back. (yeah-yeah I know what they say about assumptions :D ).

I note that file transfer functionality is already included in esp3d-webui.

So functional workflow could be something like as follows:

• User accesses bed levelling function in ESP32_WEBUI. A file will need to be selected as part of this process as this sets search boundaries. So maybe activated from an additional button in SD Card menu?
• ESP32_WEBUI serves bedlevelling.js file to client (browser) NOTE: bedlevelling.js is just an arbitrary name for code functions yet to be developed but largely based on existing cnc-kt-ext plugin with additional file handling.
• Client runs bedlevelling.js function for surface probing. Machine controlled by serial GCode commands. Search results stored in array [x,y,z] NOTE: I'm not sure how it gets the z value, as probing function only functions as an interrupt. But this is a path well trodden and is just a gap in my knowledge. I'm sure it can be done.
• Selected GCode file is read by client and parsed. X,Y,Z positions are interrogated, values are interpolated and Z value updated. (already present in applyCompensation() function in cnc-kt-ext plugin)
• Once entire file has been parsed, the data is sent back to ESP32 as a new file.
• File then manually selected and run as per normal

Both esp3d-webui and CNCjs are written in javascript and using the client (browser) to process the data. The main difference is that with esp3d-webui you are serving that javascript from the ESP32 in response to a server request but in CNCjs it is resident on the client machine. Both are using the client to undertake machine control, which should mean that porting the code is possible. My understanding is that both Chrome and Node.js share the same runtime functionset.

I don't really see an issue with the basic machine control as this is already being done with the existing ESP32_WEBUI interface, the challenges are going to be parsing the GCode file, especially if there are limitations with the client.

Of course it is entirely possible to use CNCjs instead of ESP32_WEBUI as it only requires a serial connection. However there is currently no solution for running CNCjs (or similar apps / programs) on a tablet mostly as installing node.js is not trivial and there are currently no ports to Android. My hope is that by integrating auto-levelling into esp3d-webui and serving it to the client auto-levelling can be performed using only a tablet connected to the machine.

As I mentioned before, my offer of help is here. If we can establish feasibility and determine some constraints around the integration I'm happy to contribute to development. Javascript is not my first language but I can generally get by.

I'm also just setting up a new machine (Hence the reason for investigating this particular workflow) and so will soon have it available as a dedicated test bed.

Looking forwards to hearing your thoughts.

/DM

[luc-github]

I've only had a cursory glance through the code but I'm guessing that it is updating the file before it is sent. Assuming this is the case the ES3D-WEBUI would require that the file be read from the ESP32

process is same as I described #122 (comment)

the challenges are going to be parsing the GCode file, especially if there are limitations with the client.

Everything is possible, it is just a matter of effort that need to be done

[DeeEmm]

Everything is possible, it is just a matter of effort that need to be done

Absolutely. Sage words there.

I'm going to make some time and work through the plugin code to get a better understanding of it so that I can better assist. I might try and set up some tests here on a spare ESP32 I have too.

Please don't hesitate to let me know if I can be of assistance with any tasks you want done in relation to this. I can appreciate that you are busy, as we all are, and so I don't want to take you away from your other work.

/DM