TLDR: It fits. Change your partition!
Long Answer: The default firmware tries to compile a lot of large features. The big features are Bluetooth, Wifi and OTA (over the air) firmware updates. OTA updates copy the new firmware into memory, verify it, then overwrite the old firmware. It needs space for (2) copies of the firmware. Unlike basic Arduinos, the ESP32 allows you to partition the memory for different sizes of firmware, EEPROM sizes, OTA, etc. See this page for what to do.
This error is due to improper installation of required libraries. See the Copy Libraries section of the Compiling the Firmware Wiki page.
This is due to a corrupt SPIFFS. It can happen when switching partition sizes. You can reformat the SPIFFS with the [ESP710]FORMAT command sent from a serial terminal.
It often happens when an ESP32 is programmed for the first time. In that case is safe to ignore it.
Some ESP32 dev modules use a different flash memory type. You may need to set the Flash Mode to DIO instead of the default QIO when programming. We have seen this in some older NodeMCU-32 modules.
If you are using PlatformIO, you can change a line in your platformio.ini file from...
board_build.flash_mode = qio
to
board_build.flash_mode = dio
If there is a chance you tried to upload some firmware with a different partition size, you may have corrupted your SPIFFS (SPI Flash File System). This is where the WebUI is stored. Try reformatting and re-uploading the WebUI. Follow the instructions below
- Using a serial terminal, reformat the SPIFFS by sending $LocalFS/Format=FORMAT pwd=admin (only add pwd=admin if you have ENABLE_AUTHENTICATION, which is not the default)
- Open the following URL in your web browser. http://192.168.1.69/?forcefallback=yes (use the address of your ESP32)
- Load the WebUI per the instructions here (WebUI Section).
The original Grbl was written for Arduinos. Arduinos reboot whenever you connect to the serial port. This was done as a handy way to trigger the bootloader to allow firmware to be easily uploaded. Therefore, many senders wait for the Grbl startup message after connecting.
The ESP32 does not reboot when connecting. This is nice, because you don't want the CNC machine to essentially "crash" every time someone connects via serial port. Also, the ESP32 allows many other ways to connect such as Bluetooth or Wifi, which do not reboot the controller.
There are other ways for the sender to see that Grbl is connected. The most common is to send a reset command. A lot of senders have the option to send the reset command when connecting. Please check the documentation for for sender or contact the developer of the sender.
Make sure you are using the correct machine definition file. All of the input and output pins are configured by that file. The default one has no pins mapped and just acts like a simulator. This is the safest machine definition file, because it is harder to damage the i/o pins. During bootup, the name of the machine definition file you are using is typically sent to the USB/serial port.
There is more information about the machine definition files this wiki page.
Check the wiring. If a motor stutters, moves in random directions or is very weak, that is the classic symptom for one of the 4 motor wires not having a good connection. Only one of the 2 coils is being used.
The motor current for these is set via firmware. Many have pots for setting current, but they are not used in SPI or UART mode. You need to set the run and hold current like this $X/Current/Run=1.2 and $X/Current/Hold=0.6. X is the drive letter and the number is the current in amps you want. The defaults for these are quite low. See the settings page for more details on how settings work.
Those drivers often use opto isolation and require special step pulse timing. See this page for some suggestions.
Be sure you are not in laser mode. Send $GCode/LaserMode=Off. Laser mode prevents the spindle from turning on unless the machine is in G1 motion mode. This turns off the laser during rapid moves between cuts.
Soft limits work in the machine coordinate system. GCode works in work coordinate systems. It typically works in the G54 system. If you "zero" your work piece in a new location, you offset the work coordinate system from the machine coordinate system. You can send the $# command to see the offsets.
Here is an example response to $#
[G54:4.000,0.000,0.000]
[G55:4.000,6.000,7.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:1.000,2.000,0.000]
[G30:4.000,6.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
If your range of motion is 0, 100 in X, you can only move from -4.000 to 96.000 in G54 without getting a soft limit alarm.
The range of motion for each axis is shown in the boot messages. There is a good video on coordinate systems here.
If you need help it is very important to give us information regarding your configuration. Most of this information is only available on the USB/Serial serial port. The information is sent to the serial port because it is the only connection that is available during startup and during a crash. WiFi and Bluetooth run in firmware, so they will not be on at startup and will be lost during a crash.
Grbl_ESP32 outputs messages at startup on the USB/Serial port. You can get the firmware to restart at any time by clicking the reset button on the module or by sending [ESP444]RESTART on the USB/Serial port. The message information looks something like this.
[MSG:Compiled with ESP32 SDK:v3.3.1-61-g367c3c09c]
[MSG:Using machine::MACHINE_DEFAULT - Demo Only No I/O!]
[MSG:Axis count 3]
[MSG:Timed Steps]
[MSG:Client Started]
[MSG:Connecting Barts-WLAN]
[MSG:Connecting.]
[MSG:Connecting..]
[MSG:Connected with 192.168.1.21]
[MSG:Start mDNS with hostname:http://grblesp.local/]
[MSG:SSDP Started]
[MSG:HTTP Started]
[MSG:TELNET Started 23]
Grbl 1.1f ['$' for help]
[MSG:'$H'|'$X' to unlock]
It is the [MSG:....] stuff we are interested.
Backtrace.
When it crashes it will provide so BackTrace information on the USB/Serial port. This information will tell us what function caused the crash and all the calling functions. It will help us greatly.
Using the Arduino IDE, you can enter the backtrace into a decoder. This is a plugin you must install. The details are here.
A typical decoding will look like this. We can tell what line the error occurred on. We cannot do it for you because it must decode from the machine that created the file.
Decoding stack results
0x400def59: report_realtime_status(unsigned char) at C:\Users\flogg\AppData\Local\Temp\arduino_build_159193\sketch\report.cpp line 731
0x400df1d1: execute_realtime_command(unsigned char, unsigned char) at C:\Users\flogg\AppData\Local\Temp\arduino_build_159193\sketch\serial.cpp line 208
0x400df392: serialCheckTask(void*) at C:\Users\flogg\AppData\Local\Temp\arduino_build_159193\sketch\serial.cpp line 134
0x4008a165: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143
Yes, there is a defined value in the Config.h file that can be changed. It is limited by the USB/Serial chip on your ESP32 module, but typically these can go quite high. We have regularly tested it at 2000000 without any issues.
We chose the default to be 115200, because that is the default rate of regular Grbl and the default of most senders. Typically only really fast laser engraving can benefit from a higher baud rate.