Just did this as well! Built and flashed the ESP32 with platform.io. Will be using a Raspberry Pi zero 2w with CNCjs as the GCode sender, the slow response on the esp32 webUI, and it failing to upload large NC files was getting tiresome.
Prior to the firmware upgrade, and after as well. The ESP32 CPU temperature climbs at least to 80C. Anyone else seeing their ESP32 really hot?
The new version of Fluidnc (3.7.18) should handle up to 6mb files well. My ESP is on the hot side but 80C sounds very high.
My reported CPU Temperature shows getting close to 60C and we’re in a heat wave right now.
Guess i am not even sure where to look
At least on WebUI v3, if you click the FluidNC logo in the upper left, it takes you to an “About FluidNC” page:
Which shows a bunch of info:
In the v3 UI, you click the logo in the top left.
I think v2 has the same, but it’s been too long since I opened it
also in the serial terminal/telnet the System/Stats command will print that info
I’m suspecting I burnt something out on it, but it continues to work which is a odd failure for an MCU. Might just order a backup now though
It’s always good to have a backup. Before you tear it apart, can you make some voltage measurments and maybe temp measurments?
I’m curious about the voltages before and after the ESP32 voltage regulator, and the temps of the other components on the ESP32 dev board.
If you happen to have an IR camera, an IR picture would be interesting to see.
80C is very warm for the ESP32 chip and is a curious resulty.
ESP32 Seems to be getting 3.3V and the regulator seems OK. Something in the ESP32 itself must be broken… Stock no-radio firmware freshly flashed
Thanks for the status report. I’m running a replacement Jackpot with no issues. But will keep an eye on it’s temp periodically
Hi! Thanks for posting this interesting alternative. Can you point to some background information on how to build the no-radio version of FluidNC.
You don’t need to build it, you can just install it from the native installers. It’s one of the standard options.
As Ryan notes, one use case is laser machines. Another would be any environment where WiFi is not allowed (corporate security policies, for example.). A third would be continuing to use an ESP-32 where the radio has been blown and would boot loop the ESP if used.
Great! Thanks a lot $Wifi/Mode=off is just what’s needed.
Thanks MakerJim to clarify. I’m not using Laser but I agree with other use scenarios.
But still I will not be getting any more free flash memory, as everything will be the same; I thought that a new firmware was available (or was build) that will not have the webUI and other SW. or tus witf the instruction $Wifi/Mode=off, some space will be liberated. Please help me to understand.
Im referring on how to do as per above by Anonymus:
“I built the no-radio version of FluidNC and noted that the bin file was 43% smaller compared to the wifi version.”
Without re-partitioning the device flash, no additional space will appear on the file system of the ESP-32. Memory (ram) usage may go down a bit, but the real problems with these devices are from bugs in the code.
I’d recommend running either 3.7.17 or 3.9.2-pre1 if you’re seing OOM errors. To many bugs in intermediate firmware revisions.
The gcode files live on the SD card, so nothing to gain from free space elsewhere.
With a V1 ESP-32, you can re-partition and get a notable increase in on-device flash storage, but that generally doesn’t help with anything but lots of macros or multiple config files. (or a really big Web UI)
What are you trying to achieve?
If it’s just OOM issues, then use the firmware versions I mention above and try again.
Thanks for the additional context MakerJim. I think I will continue using my version 3.7.17 for now. Kind regards
