X and Y move after reset

Not sure if this is the right place to ask this. I use FluidNC, but on a TinyBee board.

This has happened a few times now.
When I hit reset (next to the pause button) on the webui when something goes wrong or when I want to stop a job my MPCNC stops like it should.
But when I than use the controlpanel or send a command in the in the webui to move the z axis up, often the X and Y axis will than move slowly too.

I have no idea how to trouble shoot this or what would be the right way to cancel a job without doing a reboot.

This is a part of the info in the terminal when I didn’t forget to save it.
You can see that after the “g1 z0 f80” command that the position of X and Y changed too. This time it didn’t move that much, but some times it moves a few cm in X/Y while slowely lifting Z. Often times through the work piece.

Grbl 3.0 [FluidNC v3.0.x (noGit) (wifi) '$' for help]
<Idle|MPos:90.340,397.900,-12.118|FS:0,0|WCO:90.000,400.000,-5.302>
<Idle|MPos:90.340,397.900,-12.118|FS:0,0|Ov:100,100,100>
<Idle|MPos:90.340,397.900,-12.118|FS:0,0>
<Idle|MPos:90.340,397.900,-12.118|FS:0,0>
<Idle|MPos:90.340,397.900,-12.118|FS:0,0>
<Idle|MPos:90.340,397.900,-12.118|FS:0,0>
<Idle|MPos:90.340,397.900,-12.118|FS:0,0>

g1 z0 f80
ok
<Run|MPos:89.130,397.790,-8.745|FS:80,0>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0|WCO:90.000,400.000,-5.302>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0|Ov:100,100,100>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0>
<Idle|MPos:87.890,397.670,-5.302|FS:0,0>

Any help or tips are appreciated.

Rob.

It is probably going off the last feedrate that was seen. You can manually tell it to move faster “G1 X10 F2000”. It should also return to normal when you run your gocode file as that specifies speeds.

Why not reboot? Canceling a job means your location is lost either way.

You might have found a bug, but they will not take a look at it without using a valid version of the frimware.

Could be a bug, someone else is seeing something like this as well. It is a very rare case you would see this in daily use though. How often do you cancel a job in the middle?

FluidNC just released a new firmware might want to try that first. If this is something you think you are going to run into often.

Or the X and Y use the f80 I set for the Z.
But the slow moving wasn’t the problem. The X and Y shouldn’t move at all.

I had problems installing FluidNC when I got this board, because the install didn’t work for some reason. The board wouldn’t go into download mode. Only worked with VScode on Linux.

I just run the installer again and now it updated the firmware without problems.
The few quick test I did looked fine so far. I will keep an eye on it for now.

I was playing around with alu plates to test for a LR3 build and that didn’t go always as planned. :wink:

I have never used a tiny bee board and I know there are a lot of questions on the fluidnc discord about them.

I would say play it safe and reset each time. No matter how you cancel the job, the position is lost. Might as well reset.

Someone is asking something similar in another thread, so it could be a bug. I don’t have a tiny bee so I will work on the Jackpot issue that is similar in the mean time could fix both.

Also, please see if it has already been fixed.

I just checked mine and if I home everything works as it should. So maybe just the cancel is loosing home. If I do home after booting movement is random.

Hi Baklin, Did you mange to overcome this issue?
I have encountered the exact same symptoms several times now.
After a pause and reset of a job, i tell it to lift the Z out of the workpiece.
Unexpectedly, it moves the head along an x and/or z axis. (thankfully no lost bits so far.)
I was on 3.7.9, but have just now upgraded to 3.7.10. (Yet to test with this version)
It seems to be running some instructions that were in the queue.
These would be arcs as I am cutting out star shapes in my code.

I just tested 3.7.10 and it fixed the issue.
I reverted to 3.7.9 and the issue was reproducible again.
Happy now…

Same here. I haven’t seen this problem after updating to 3.7.10.