One idea I have is that since grbl_esp32 supports external gcode senders is to use the webserver of esp32 as a basic interface… maybe not as full featured as webcontrol but with holey calibration baked in. If so, you may be able to make it small enough to fit on a stock devkit. If someone wants a more feature-rich interface, they can hook a PC or rpi to it and run webcontrol (or any other gcode sender)
4 Likes
If I understood it correctly there is a GRBL plugin for Octoprint, that might be the ticket.
Thank you
There’s a lot of CNC programs I’m sure would work (@ldocull uses BCNC I believe with his grbl controller). BCNC obviously can’t do the calibration needed, so that’s why I suggest (as @dlang has suggested before) to bake that into the grbl-based firmware. With a web interface on the esp32, I believe that’s very doable.
It may be possible to put a full-featured web-interface on the esp32, it just looks like it’s going to be a lot of work doing so in c++. So I throw out the idea to start with something basic (settings and calibration) and leave the more complex stuff (gui display, etc.) to the external sender and then, over time, work on incorporating those features into the esp32.
1 Like
I see your point and direction, however - I think we need to come up with a way to do Calibration from a command line in firmware. At that point you remain compliant back to CPM. You can then build a UI that sends all the commands. I agreed a simple UI and Web server is convenient. My whole reason to get to GRBL is that at that point anything that can send a serial stream can run the machine. This is the standard on just about every other CNC I have access to. Further the Webserve and UI are then independent. I would run it like this - ESP controller, Optional 2nd ESP or RPI as Webserver/UI / MTQQ.
In this configuration I can use a single ESP controller and a second computer/controller to make a “widget” machine. Basically I can use and Arduino with a Character display as my second level interface to store and repeatedly make the same widget over and over. This is one of my goals. GRBL gets me very close to it.
Just my 2Cents
Thank you
1 Like
Do you mean to do so by sending $ commands? If so, that’s feasible as well (need 12 firmwarekeys to hold the measurements if using holey calibration)
I’m thinking in terms of B commands for the actual calibration, since $ are just
variable assignments and we want to do calculations.
But this then gets back to my generalization of holey and matrix calibration 
I like this idea a lot. Great suggestion @madgrizzle.
I think the first order of business should be to make a 2 motor controller work with an esp32 port of GRBL.
Then let’s work on adding a UI
Then 4 motor control should be easy as adding additional axies in the firmware.
4 Likes
the grbl-esp32 port includes something similar to webcontrol if I’m
understanding it correctly, you aren’t starting from scratch.
1 Like
The basics are there, like settings…There’s display as well, but it does not (from what I can tell) show the gcode on the screen. Adding that will take time and someone that knows how to do webserver work in c++ and particularly how grbl_esp32 implements it.
1 Like
Space is pretty tight - on a 4MB WROOM, even when compiled with ‘Minimal SPIFFS (Large APPS and OTA)’ the sketch uses 1763906 bytes (89%) of program storage space. Maximum is 1966080 bytes.
1 Like
Is there anything extra in there that we can strip out to get more space?
esp3d-webui that grbl_esp32 uses is not bloated… it’s pretty lean with its use of js libraries and html. I think I read it uses a stripped down version of Bootstrap 2 just to get it to fit in the available space. There may be a few files here and there that can be dropped out that are specific to 3D printers, but likely they would need to be replaced with something specific to Maslow.
The grbl_esp32 code might have room for improvements if you start stripping out some of the functionality that’s not needed and do some code rewrites. One of the files (commands.cpp) seems to repeat code over and over again for each switch-case and I’m pretty sure that can be optimized. There might be other examples.
1 Like
remember, we can always go with a module that has more storage. especially for
initial development
That’s before adding our kinematics and motor-control…
ESP32-DEVKITC with 128Mb flash is surprisingly hard to find. This is the only one I’ve spotted - has anyone seen others?
1 Like
I found that as well. I would be happy to go with the bigger version if we have a stable source for them
I think finding boards (e.g., devkitc) with large flash memory will be a problem. However, I think you can readily find modules, which I think was what was desired since they can be surface mounted.
1 Like
I read that grbl will be coming out as v2.0 in near future. They seem tightlipped on what’s in it.
1 Like
from what I’m seeing, it’s mostly a re-write to support 32 bit based systems
David Lang
1 Like
I put my experimental code in a repository in case anyone wants to play with it:
I think a fork of the ESP32 GRBL code is where I am going to work from here on out, but I think this code is a nice reference as a basic example of how things work.
2 Likes
Thanks. Curious if there is a reason for 1000Hz PWM rate. Typically they are 20kHz+ so its out of sonic range.
And why create your own Analog Write?