Grbl_ESP32 update: SD Card Support
Here is a look at something I have been working on. I have added some SD card features to Grbl_ESP32.
Why SD Cards?
Grbl works great with senders and really shouldn’t need SD card support. That is true for your typical desktop CNC router. laser, etc., but there are a lot of machines that are not “typical”. I like to make machines I can fit in my backpack or in the palm of my hand. I certainly don’t want to use a traditional PC – Machine setup. I want control via phone or completely autonomous. This means SD card, Bluetooth and Wifi options are critical.
Does a machine even need connectivity at all? Running a file from an SD card and uploading new firmware via SD card is going to be critical for some new projects I have plans for.
What is the best way to do this?
After debating a few methods of implementing this, I decided to do it in a more Grbl’y way, than a Marlin’y way so that it is less likely to break the existing Grbl gcode senders. This means I’ll try to report status and push notifications in a way that won’t break anything. I’ll also follow the strict NIST gcode rules of Grbl. NIST does not have SD gcodes, so they will be more like Grbls $H (homing) than Marlins equivalent gcodes.
With that said, if anyone has some suggestions for changes, I am still in a stage where I can consider them.
Protocol
The commands all start with $F (for file).
- $FM – Mounts the SD card. You do this once whenever you want to use the SD card or after you re-insert.
- $F – Reports all the files matching (.NC, .TXT or .GCODE). It printrs one line per file like [FILE:/myfile.nc SIZE:7609]
- $F=/myfile.nc – This runs the file.
Job progress is automatically appended to the end of the “?” command response. like <…….|SD:55.78> where 55.78 is the percent complete.
Sender Compatibility
- All of senders I have tested (UGS, LaserGrbl, Grbl Controller) are OK with these changes.
- They continue to request and get status and update the DROs.
- If they have a verbose option, you can see the job progress.
- Some (Grbl controller) filter out (don’t display) the [FILE:….] responses even on verbose mode.
- All can be disconnected during a job without affecting it.
- Most send a Grbl Reset when reconnected which kills the job. This would be easy to ignore during SD card jobs (not implemented).
Next Steps
- I will release a branch with these features
- I want to look at adding a card detect feature to auto mount the card
- Look at methods of firmware upgrade via SD card.
- Can a file be uploaded to the SD card (USB, Bluetooth, Wifi)?
Video
If you want to be notified of future blog posts, please subscribe.
Greetings dear!
Do you plan to expand to you perfect board the number of drivers to engines to 5-6 ?
It would be very good to use on 3d printers.
Thank you.
It is not difficult to add additional coordinated axes in firmware. My PSoC 5 port of Grbl has 6.
To do that on the ESP32 we would need to expand the I/O count using additional parts. That is not challenging either, but we are currently focused on using the existing I/O and working on new control features like, Bluetooth, SD Card, Wifi and web server.
More axes and 3D printer features are further down the road.