Anyone else testing out v3.9.3?
I was able to use the web installer to update my Jackpot to it. I will try to run a little testing on it.
OK, I’m re-running my most recent GCode cut file as an air cut, and all seems well. From my FluidDial, the pause and resume work without dropping the machine, and also the E-stop cancels without dropping the machine.
Then, while re-running the job again, I went to the browser where the WebUI v3 had been previously connected (before updating FluidNC), and yet was not still connected of course, and so I pressed a button to re-connect, and I got this nice message:
…and I then used the “Pause” button shown in the message, and the machine instantly paused and the WebUI v3 instantly loaded. It came up showing the job as paused:
I then used the resume button in the WebUI v3, and the job carried on:
Then, from the WebUI v3, I tested the pause and resume, and they work without dropping the machine.
I don’t really know what all needs tested, but I’m pretty pleased with all this.
Can anyone think of something else I should try as a test for the newly released update?
2 Likes
This is great to see. Against my better judgement, I couldn’t leave well enough alone and decided to give 3.9.3 a whirl also. My machine is now constantly in an alarm state. 
If I try to clear the alarm:
$X
error:152
[MSG:ERR: Configuration is invalid. Check boot messages for ERR's.]
Alright, let’s try that:
$SS
[MSG:ERR: Showing startup log from previous panic]
[MSG:INFO: FluidNC v3.9.3 https://github.com/bdring/FluidNC]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:INFO: Local filesystem type is spiffs]
[MSG:INFO: Configuration file:config.yaml]
ok
<Alarm|MPos:0.000,0.000,0.000|FS:0,0>
That doesn’t tell me squat. I’m using the V1E config.yaml from Github. Not sure where to even start here.
I’m not at my machine right now, but I think the file system normally gets reported as “littleFS“ — not “spiffs”?
The first thing I would do is make sure that your config.yaml file is actually still there and still has correct contents.
Well, I went old school with a serial connection and completely reset the whole thing. Used the web installer, full rewrite, etc etc. Used the same tool to set the wifi (works great, STA) and upload the MPCNC yaml file. It’s absolutely there. FluidTerm shows what I gather to be a “common” guru meditation error, but doesn’t actually have MSG:ERR anywhere. It’s weird. Here’s the full output:
FluidTerm v1.2.1 (1cf9483) using COM5
Exit: Ctrl-C, Ctrl-Q or Ctrl-], Clear screen: CTRL-W
Upload: Ctrl-U, Reset ESP32: Ctrl-R, Send Override: Ctrl-O
Resetting MCU
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13260
load:0x40080400,len:3028
entry 0x400805e4
[MSG:INFO: uart_channel0 created]
[MSG:RST]
[MSG:INFO: FluidNC v3.9.3 https://github.com/bdring/FluidNC]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.7-dirty]
[MSG:INFO: Local filesystem type is littlefs]
[MSG:INFO: Configuration file:configMPCNC.yaml]
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400d8a2b PS : 0x00060830 A0 : 0x800eb06c A1 : 0x3ffb1d40
A2 : 0xb3300122 A3 : 0x3f40541c A4 : 0x00000000 A5 : 0x00000002
A6 : 0x0000001a A7 : 0x00000001 A8 : 0x3ffbbbd8 A9 : 0x3ffb1cd0
A10 : 0x3ffbbbd8 A11 : 0x00000000 A12 : 0x3ffb36fd A13 : 0x00000006
A14 : 0x3ffb36fd A15 : 0xff000000 SAR : 0x00000017 EXCCAUSE: 0x0000001c
EXCVADDR: 0xb330014a LBEG : 0x4008d5e9 LEND : 0x4008d5f9 LCOUNT : 0xfffffffe
Backtrace: 0x400d8a28:0x3ffb1d40 0x400eb069:0x3ffb1d60 0x400e77fd:0x3ffb1d80 0x400eb149:0x3ffb1db0 0x400ea282:0x3ffb1e00 0x400ead05:0x3ffb1e20 0x400eb149:0x3ffb1e70 0x400eb766:0x3ffb1ec0 0x400ebce2:0x3ffb1f50 0x400ebf1a:0x3ffb2200 0x400edd2c:0x3ffb2240 0x401299b2:0x3ffb2290
ELF file SHA256: 1b9e4b9a7a086a0a
Rebooting...
1 Like
Hmm. Interesting.
From earlier message, said “spiffs”:
…from later message, said “littlefs”:
Efforts to clear the alarm simply don’t work?
Yeah, I noticed that as well. Figured something changed with the full wipe/reset.
$X to clear the alarm won’t work, because it insists the problem is with whatever config.yaml I use. It never actually says why in the form of MSG:ERR though. Apparently it boots, decides it can’t read the config file, then boots in a safe mode of sorts with default values. I didn’t realize any of that until I used Fluidterm though.
1 Like
Any chance you can use WebUI to edit some value(s) and save changes? Perhaps letting it rewrite the config file might fix something?
You’re storing the config.yaml file on the flash memory, not SD card, right?
I was thinking the same thing - maybe the file itself is corrupt, has bad CR/LF characters, something with the config file. The web installer can open the YAML, and has a nice gui to pull in all the values and edit them. That loads correctly. I can change a value, save, restart, nada. Always “configuration is invalid” and no other ERR messages.
Next, I loaded up the web installer, file browser, create new config. I left that completely blank, saved, restarted. That boots without any errors, but won’t work obviously.
Tired the same, but this time new config using the create from template / Jackpot CNC option. That file also fails during boot, again no specific ERR given.
My conclusion is there is some setting that isn’t liked. I’m starting with that blank/new file and going to try adding settings in manually a few at a time. Not sure what else to try.
For what it’s worth, this problem seems to follow FluidNC versions too. I can replicate it in 3.7.18, 3.9.1, and 3.9.3. Does anyone else have a MPCNC working with the Jackpot? I’d love to see a known good file.
Hmm. I know that stray trailing spaces (at the end of a line of code or a variable value) can create issues. If you edit in VS Code and search for instances of the space (" ") it highlights all of them, and you can scan for trailing spaces.
V1 tested/recommended config file is here
1 Like
That’s the one I’m using - from V2. I tried the V3 one also. My logic:
The controller says it can’t read the YAML file, it must be the YAML.
But the web installer can read it just fine, even edit and save it. So it can’t be the YAML.
So it must be some setting inside the file… but I’m running the stock settings. Nothing makes logical sense. I’m going to see if I have another ESP32 chip around and flash that as a replacement. Everything should be working, and I’m running out of variables to swap out. 
Edit - also want to mention it does not matter if the chip is installed in the jackpot or not. I have tried with and without an SD card inserted too. I do have another ESP32, but it’s an old Devkit V1 with less pins.
1 Like
One thing to try, is to use the web installer, and downgrade to an earlier version of fluidNC. If the alarm issue goes away, then that would indicate that you have uncovered some type of a glitch or bug in the new version. It becomes a version specific error.
said he tried that
If doing a complete wipe and re-install from the web installer doesn’t fix it, I have seen a few say that downloading the release directly and starting fresh using the batch files can sometimes clear up problems.
Otherwise, I’d try a different ESP32.
Ryan’s configs are known to work, so it kinda sounds to me like the filesystem may be having issues or something
1 Like
I had forgotten that. Ugh.
For one last attempt, I used esptool.exe erase_flash. Verified it appeared truly dead. Poked the body a few more times. Then flashed one last time. Uploaded config.yaml one last time. Same dang errors. I give up for the night. Waiting to get another ESP32 to try.
1 Like
Guess I’m a liar, I also decided to flash that older ESP32 via the same process, even though I don’t think it’s usable in the Jackpot. That seems to work great, other than not being attached to anything. So I’m pretty certain it’s the chip and not my process.
2 Likes
Try this as a final, final step.
In the FluidNC distribution, there is an erase (erase.bat or erase.sh depending on your distribution)
Do this in order (add the .sh or .bat as appropriate for your setup)
erase
install-wifi
install-fs
Then put config.yaml back on.
Reboot, reconfigure your network, and then see if it is misbehaving.
If not, add the rest of the files one at a time.
If it is misbehaving, then you’ve got a bad ESP-32.
1 Like
Fired up 3.9.3 last night on my LR4. Was delighted to find nothing obvious I could do from the pendant caused the motors to disable and drop, including E-stop. (Feels like that used to happen any time I interrupted a job!) Was able to restart jobs, clear the alarms, etc with no problems. Thanks for leading the charge @DougJoseph!
1 Like