Using bCNC g-code sender running n a RPi and FluidNC. Latest versions.
Using bCNC, if I pause and then stop a job, FluidNC initially stop XYZ movement (on Pause) but when Stop (bCNC) is selected FluidNC appears to run any G-Code that remains in buffer. This is not desirable for a number of reasons (possible crash, loss of position, spoilt stock…).
Has anyone experienced this type of behaviour with either bCNC or another G-Code sender? Better still, does anyone have a solution?
Cheers, Maurice
I must admit, if I hit stop. its normally because I screwed up and I need to start again!
I would suggest you try Universal Gcode Sender or GRBL-plotter.
Universal Gcode Sender is my preference but GRBL-Plotter is super powerful
Hi Pete - Happy New Year! We’re enjoying a balmy 29C and sun but the days are getting shorter.
“Stop = screwed up” I agree 100%, the problem is that on releasing the emergency stop I need the machine to remain stationary so I can jog the tool away from the stock. Unfortunately the FluidNC buffer is not cleared so when the machine is enabled FluidNC sends the buffered code to the machine. I would like to find a way of ensuring the FluidNC buffer is cleared on an emergency stop. I’m using an RPi3B which doesn’t run UGS quickly enough to be useful. I have a RPi5 in order which should work much better. I may also try changing the SD card type as some SD card types can slow the RPi down.
I’ll let you know if a switch in sender fixes the problem. It’s not a problem I had before switching to FluidNC.
Hi Pete,
I have a RPi5 running with UGS and I am getting the same behaviour as with bCNC.
Steps to reproduce:
Suggest a simple facing task with spindle clear of the bed/stock (Z0 above stock top)
Expected behaviour:
At 1, Z axis moves up, spindle starts, machine moves to start XY coordinates. Z starts to move to start height …
At 2, machine movement stops, spindle still rotates and machine position retained.
At 3, spindle stops, machine does not move. UGS assumes Idle state ready for next job. Jogging available. (this was how my machine worked with an Arduino controller and LinuxCNC)
Actual behaviour:
At 1, as expected
At 2, as expected
At 3, spindle stops but machine executes buffered X, Y, and Z moves.
This appears to be related to FluidNC but I can’t be certain. I have looked through the GRBL1.1 and FluidNC docs but have not identified a solution.
Do you see this behaviour?
If not I’m guessing it’s a config.yaml problem… any thoughts?
Problem solved - it appears to have been a bug in FluidNC 3.7.6 which I was still running (as original setup). I upgraded to FluidNC 3.7.14 the problem went away.
I’ll leave this up in case others have a similar problem.
I’m super happy you solved it!