Whoaa, good catch I subscribed to that thread. Crap, That jump to 3.8 helped with file transfers. Shoot. Shoot Shoot.
Yeah, this is the interesting part of following along with a very fluid FluidNC development cycle.
I did some testing today on my testbench machines trying to work on the dual spindle / pendant hardware I’m experimenting with but gave up because of FluidNC stability.
It looks like 3.8.3 relased a couple of days ago; I’m going to jump up to that and see if it’s any better for me.
2 Likes
Yuck. The 3.8.3 change I mentioned about preventing the UI from reloading if a job is being run means that you can’t get back to the UI until the job is complete or you stop the job. I’m assuming this means you couldn’t do a tool change.
The alternative seems to be crashing it.
3 Likes
Does a pause count as stopping the gcode program?
3 Likes
I wonder if a tool change will cause that window to pop up and let you do what’s needed. Thankfully I added a fluid dial recently so I don’t hardly use the webui anymore
1 Like
I assume the screen would let you do what is needed. You only need some sort of UI to resume. If the WebUI was up the whole time, it would still work.
I am pretty sure that does not show up when it is paused waiting for a tool change. That used to be there and I have not seen it in a while. It used to only show up if I refreshed accidentally too many times (bad swipes on the touch screen).
This was changed in 3.8.3. I’m pretty sure it will show that screen for a tool change. For a quick test, I ran the crown file in the air, paused from the UI, then refreshed and got that page. Unless M0 is handled differently than a feedhold.
Crud
Crud.
This will be fine for the laser, but sucks for the way I use pauses for the router.
Maybe I’m spoiled by the RRF behaviours.
With 3.8.0 - 3.8.3
- Clicking on Settings during a cut will kill your job.
With 3.8.0 - 3.8.2
- Reloading web pages during a cut will kill your job.
- Losing network connectivity long enough to result in “Connection Lost” (takes ~1min?) results in not being able to view regular dashboard until job is complete. You end up with the crappy pages that Jason screen capped in earlier post. Those pages may not be pretty, but they help protect continued execution of your job.
Workaround: Don’t touch anything, or 
around when running a job, make sure your browser device is close to jackpot throughout the cut. Consider 3.8.3 if you need features from 3.8.0 or newer. Some 3.7.x version may be better option 
. Note I’m new to FluidNC and don’t know enough about FluidNC to have a high confidence opinion.
2 Likes
When I was last looking at the firmware, the architecture was set up so one core effectively did step generation (through the DMA) and nothing else.
The other core did everything else: handling WiFi, reading from SD card, handling serial communication and interpreting commands.
Which meant, if any of the channels misbehaved, it could hang up loading from SD card and the movement queue could be depleted. The movement queue was made rather deep so as to prevent it from having an effect, but that’s not really a solution.
Marlin + ESP3DLib + ESP3D-WebUI essentially runs Marlin on one core and everything UI related on the other core, so I would think that hammering the interface should not stop Marlin from stuttering or dying when executing from a gcode file on the SD card. If your WiFi were awful, e.g. if you walk away, you might have trouble interacting with the UI, but when you return it should behave in a sensible way. That is speculation, I haven’t tried all the edge cases with Marlin + ESP3D, but at least the architecture makes it possible.
I think FluidNC could (should) put a lot more essential stuff (like loading from SD card and interpreting commands) into the same core as the step generation. Step generation is extremely high priority but there is still idle time in between the step processing that can be used for other non-UI stuff so the system doesn’t die from UI faults.
3 Likes
Yeah, it’s taken quite a set of steps backwards. Yuck.
So I just had an issue where I needed to pause the job and adjust something, which would have been possible had I been able to raise the gantry temporarily. Of course I could pause the job, but not raise the gantry. I ended up having to restart the job. I also lost position, even though I paused and then did the soft reset, so I ruined the workpiece. Nice bit of hardwood, junked. If I’d only had to let the router cut air for a minute and a half, I’d have been OK, though annoyed.
Not Impressed.
This is 3.8.1, but looks like this issue is consistent 3.8.0 → 3.8.3 (current.) This makes me think that I really do want go back to a Duet board with RepRap Firmware.
2 Likes
This sounds horrible. I wish Cristian added WiFi and autosquaring to his boards, you guys would love Estlcam as a controller.
1 Like
There’s a port of RRF for the SKR Pro 1.2, Octopus, and Octopus pro.
Might be worth me experimenting with.
Yeah, but those controllers are weak sauce compared to the 32 bit processors on newer boards.
I suppose “works well” would overcome a lot of that- but I’m not sure there is room/capacity on those controllers.
Would happily pay for an extra ESP32 if FluidNc can be split across two ESP32s and would help mitigate some of the stability issues people see. I don’t know much about the protocol/architecture, so this could be a stupid idea.
Removed until I read the docs E.g. ESP32-S2 or ESP-S3 runs web server, and acts as USB host to the jackpot ESP32 if FluidNc doesn’t natively support split deployment.
Yes, I have RRF on my spare SKR Pro, however, I have 2 unused Duet 2 Wifi boards, which are much better documented with RRF, so… The only issue with the Duet 2 is laser output kind of sucks, but I have a good interface for it, and don’t plan on putting a laser on the LR4.
I had been planning to move the MP3DPv3 from Marlin to RRF, it’s using an SKR Pro already, and changing the firmware should be easy enough, but the plan now is to rebuild that to a v5, as in re-use the linear rails and 310mm square build platform. Unfortunately not much else is reusable…
I was looking up some “Pause/Cancel” stuff online, and kept getting referred back to a thread where someone commented what RRF does, and the answer basically said “If you want RRF, then use RRF.” I thought that was kinda rude, and makes me think “Okay. I will.” It wasn’t really related to what I was looking for, and my experience with the machine losing my coordinates after a soft reset makes me.think that wasn’t what I was looking for after all either.
Still, given the relative cost of a Jackpot and ESP32, I hold put hope for FluidNC and the WebUI to be a good solution. Unfortunately a FluidDial pendant closes the cost gap between a Jackpot and a Duet with a touchscreen quite a ways, or I’d go with that.
Here is a little context to the reload problem on the issue that triggered the 3.8.3 change.
3 Likes