That’s a tough problem. Seeing that the WebUI source file lives on littlefs and access there interferes with interrupt handling shows this is really a problem, way down low-level.
It’s sort of an intractable conflict for resources and as Jamie positied, this is a mess that seems like it needs an architectural overhaul. The very same high performance but congested hardware architecture that enables FluidNC on ESP-32 is now significantly hampering it.
Time to redouble efforts to find a Klipper supported MCU that can fit on a Jackpot, as a contingency while we wait and hope for a FluidNC breakthrough.
Does anyone know what the last, best, somewhat stable version of FluidNC 3.7 was? I can live with moving files manually to the SD card- but I can’t live with the botched interface between the step engine and the web UI.
A-
Okay swapping boards, and firmware is a pretty huge bummer, the Jackpot is steadily increasing in sales. Just turning my back on that would be pretty heartbreaking, especially right before the LR4.
Does anyone have the skill and any time to look into this, if you do PM me so we can discuss if I can afford your time.
If we do have someone, I can reach out to the Fluid guys and see how we might best spend our time and money.
B-
I run a job that is nearly two hours and has a tool change. I am not sure how I have not run into this on 3.8.0. Finding the last release that did not have this issue would be good to update the docs with. I can run jobs on several board with different firmware if someone has a sequence I can run to try and trigger this, Just run a job and go to the settings tab?
C-
Any other options that might work on the Jackpot, Jamie did get Marlin working we can go back to that for sure, right?
I’ve only been lightly following all of this as I’m still using a slightly older version, but I’m kinda confused as to why this is such a big deal???
I don’t find it very hard to keep my interface open, and connected, for the duration of a job without having to refresh.
I keep the interface open to the status tab to watch what is going on, but I guess I don’t see it as an issue to not play with Settings, refresh, etc. while a job is running.
I understand that the v3 has more toys to play with, but to me, this has always been a problem even in V2.
I’ve never been able to refresh the UI or do a lot of things while a job is running, and don’t want to attempt it anyway given the memory constraints and risk of crashing the board.
Maslow is also operating with FluidNC and the WebUI, right?
I know Bar was poking around getting the S3 to work, which could potentially solve memory issues.
Are you really at a point where you are considering throwing away FluidNC? I know it’s far from perfect, but I honestly have not had any of the types of issues with it pausing or crashing like I’ve been seeing mentioned recently
I haven’t run any long jobs yet but I haven’t any any issues on 3.8.3
I do have the screen time out on my fire tabled set to the max time and I have made it a habit to move the screen around every few mins so it never goes off. Maybe that’s why I’m not seeing the issue.
I know its not perfect and still very much in development, but thinking about going back to marlin just sucks. But I understand it if its what we need to do.
I use a fire tablet, my screen goes off all the time. I swear I even screw up and refresh sometimes and have never seen the issue. With that said, same as you guys I don’t play with anything while it is running.
We have some heavy hitters here with machines not working on a jackpot, makes me wonder what happens to a new user?
I also don’t like that I have not seen it. Mitch seems to confirm random crashes in github on a few threads/issues. That is bothering me a lot. Seems it has been know for weeks, so it must not be easy to track down.
I am suggesting this in all seriousness (again): Estlcam has a really great controller part where you can pause, move around, change tools without it ever crashing. I have been using it for nearly four years now and the only two major drawbacks are a) no autosquaring natively (though that might come, Christian hinted at new hardware) and b) the USB cable (Timo from Timo’s Werkstatt tried to get it working over Wi-Fi but failed, but this would be something you guys could figure out. Christian already gave some pointers).
There is the OPEN-CNC-Shield 2 Mainboard Mini | SW10046 which includes the ESP in its board for autosquaring. It’s a good approach but tbh, none of us really need the modularity I guess. It’s nice to change the controller on the fly but I don’t think we actually need that.
As regarding the “it’s using an old Mega, it’s outdated etc…” argument: Does that really, really matter as long as it’s working? I know me and @RegPye are the outsiders using Estlcam as the controller, but I do run both systems, FluidNC from Ryan on my MPCNC I use as a plotter and the Open CNC Shield with Estlcam and Estlcam is so much better in every regard… (except those two mentioned above that you’d have to solve).
I’m by no means looking to abandon FluidNC. I think I was mistaken before that you can still resume and do tool changes from that basic screen. Not ideal but ok.
I typically run the UI from my phone. I start the job and sometimes put it back in my pocket. Then later I’ll open it back up which triggers a UI refresh. This definitely worked fine on a 3.7 version. If I need to modify my workflow, that’s ok.
I’m not that concerned about the settings page crashing the job. Not ideal but I can just not do that. It would be nice if I could get back to the dashboard while a job is running.
I don’t have time at the moment, but I tempted to try to create some automated UI testing around this functionality. At work, our QA department uses Playwright for this.
What do I do about the ~1000+ Jackpot users running my board. That is not a good look to develop something and just dump it.
I have no issues with people using other boards and firmware, I try to go out of my way to make sure that is easy to do, but More important is not dumping the people that bought a supported board from me. I only sold ~20 Archim boards and I feel like crap that those users just got left kinda high and dry with no updates. They have working boards but no update path at all.
You don’t have to drop the support, but maybe find the working version and leave it at that? I don’t know, I am not in your shoes and the Estlcam boards being only popular in the EU more or less does not really help, but it would be an eye-opening experience for everyone to use it once for a job with 3 toolchanges or a job you want to do over several days.
/edit: I know I sound like a raving lunatic about it sometimes, I really am not I do have the comparison and have run both machines for quite a bit. Obviously Fluid not as much, but enough to have a definitive and informed opinion.
That is interesting. I spent most of my day yesterday trying to get myself off Sourctree and figure out VSCode with git instead so when the LR4 dust settles I can spend more time on the Jackpot. I will have to figure out some sort of test protocall at some point and that looks great. Currently, I run a job and make sure it has a tool change. If I see no issues I call it good and move on. Clearly, I never tried to change settings or refresh much while it is running. Seems like something that needs to be there I guess. Although I don’t do that to my printers either. When they are running I leave them alone unless they call me over for something.
Currently those independently are 100% deal breakers for me. 10’+ USB cable on a LowRider sounds like a very bad idea, and autosquaring is a must or you are stuck trying to shim LR2/3 Y&Z endstops as well as all MPCNC endstops.
I’m clearly a green noob regarding the factors, but the discussion does make me question whether it would be possible to serve the WebUI from the SD card instead of from the ESP32/LittleFS storage? Would it help? Hurt? Not doable?
I am quite happy to use Estlcam as the controller, apart from the USB drop outs that happen far too often. As for auto squaring, I don’t have too much problem there as I use geared down steppers on the Y axis and ballscrews and rarely have an out of square situation.
I have been using clone Nanos up to date, but have recently bought a genuine Nano to test out to see if it is any better, which I will do when I can get back into the workshop (recovering from recent surgery)
Estlcam has many good features that I have not found on very much more expensive systems and it is so easy to use in most cases, the downfall is in the firmware that really needs to have some improvements done to make it a perfect solution.
@vicious1 are you using index.html.gz from the repo referenced by Jackpot docs, or a newer build uploaded somewhere, or, do you run a WebUI you built locally (using VSCode + PlatformIO) ? Think Mike and Jason are running locally built WebUI on their machines, guessing VSCode + PlatformIO?
I’ve been following Jackpot docs and using files at https://github.com/V1EngineeringInc/FluidNC_Configs/tree/main/LowRider%20CNC/UI%20V3%20LRCNC including the 6 month old index.html.gz in that folder … Mentioning incase there’s some updates/fixes missing for folks following Jackpot docs? Am not even using Jason’s neat extensions/mods just yet until I understand what I need to do (and not do) to always reliably cut.
Created https://youtu.be/6d5CHlRZiMs shared yesterday to show what I’m seeing, so people can tell me if I’m doing something(s) wrong, and/or, help others navigate the sunny path to success…
0:00 Overview/Problem - going to show ways to crash FluidNC, and, how we can avoid crashes…
2:50 Set IP to 1.2.3.4 for FluidNC ESP32 so my client PC can straddle my home network (ethernet), and connect to FluidNC AP (wifi).
4:04 Some JSON scripting/error, not reassuring, but am just ignoring… “Bad control character in string literal in JSON at position…” in scary red error notification popups. Recently fixed by Mike, see https://github.com/bdring/FluidNC/pull/1336.
4:30 Start a cut job using .gcode file on SD card.
5:07FluidNC crashes when Settings clicked while CNC job active. StoreProhibited fault
6:38 FluidNC behavior when network connectivity lost
6:55 Distraction… The scary red JSON scripting/error again…
10:50 Simulate less than 30s network unavailable… FluidNC will auto reconnect and continue.
11:20 Summary/tips… Don’t click on stuff when job is cutting. Configure client to not auto sleep/shutdown/energy-saver/etc… Reconnect less than 1min to avoid seeing the basic 3.8.3 workaround screen.
I use a jackpot and Bart’s 6 pack board both are running v3. 7.x and i can say i have not seen this issue: both boards have a dedicated touchscreen and a raspberry pi 4 running as KioskMode with the Fluid.nc page. (But i never hit the fluidnc settings page while working or else. ) Just downgrade until you find software is stable enough. I do have multiple esp32s as backups with the exact same settings and config files for each machine. I can do some testing tomorrow