Closed banana-legs closed 8 months ago
I am not sure exactly what the "stop" button does in UGS.
Ideally you would do a reset and then home ($H or $HZ) to recover from that problem.
If you are doing a feed hold, you would do a reset and then could either home or jog up.
luckily $HZ on its own works fine, so I have added a macro button to do that as a work-around. Force of habit still has me sometimes hitting the Z-up on the jog controller after stopping a job before remembering about the issue though!
Many senders do different things with "stop".
There is no stop in the Grbl protocol.
Can we close this issue?
I had a look through the code changes that occured between 3.7.5 and 3.7.6. There was nothing obvious that jumped out, but there were a number of adjustments to what happens on abort; in 3.7.5 it looks like an abort threw back into the main loop so effectively did a reset. Now the code keeps going instead of directly resetting and I wonder if the planner buffer is not being flushed properly prior to the jog?
Fundamentally, a bug crept in somewhere from 3.7.5 to 3.7.6, but it looks like it could be a subtle one that is not easy to trace. It may need someone who knows about what the 'stop' sequence in UGS is to ascertain what sequence of events are being triggered in the abort process in order to work out what is happening. I can live with the work around, but I suspect it is worth keeping an eye on rather than closing as it can directly lead to a break in an expensive milling cutter, which is not great PR for such a fantastic CNC controller.
Just to make sure, are you connecting with the FluidNC firmware profile in UGS? What version of UGS are you using?
The code for a "stop" in UGS is done here: https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/firmware/fluidnc/FluidNCController.java#L492
Can you post the console output from UGS when this happens?
I am using version 20.21, but it also happens with 20.20. Yes it is using the FluidNC firmware profile. All I get in the command window when I cancel is
ok
*** Canceling command stream
When all has stopped and I then do a jog: $J=G21G91Z0.099F593.829
The CNC moves slowly for a few seconds in x and y and not z.
What does the '?' status command reply?
I think we found the issue. It is something we fixed a little while ago, but then we had a github mishap where we lost few commits. The problem was fixed again and has been waiting for a couple weeks in the devt branch for the next release.
It has to do with some residual arc segments left in the planner.
I hope to do a release in the next few days.
Awesome, very many thanks for all your help :)
Wiki Search Terms
Jogging, UGS
Controller Board
External drivers with standard steppers
Machine Description
XYYZ gantry router with 2.2kW spindle on 10v drive.
Input Circuits
No response
Configuration file
Startup Messages
User Interface Software
UGS
What happened?
When running a programme in UGS, if the 'stop' button is pressed to abort the milling operation, the machine comes to a halt and the spindle stops as expected (usually with the bit still in the channel being cut). The very next jog operation, which is usually one to move Z up to clear the bit from the work piece, does not usually move in the direction commanded; the jog almost always moves sideways instead of up and breaks the milling cutter. After that erroneous jog operation has completed (it usually moves really slowly too), all subsequent jog operations work fine as if nothing was ever wrong. I have found the problem does not matter which gcode file I am running as it has happend on many occasions (yes, I am that bad at starting a job correctly first time!).
I have checked back by installing older firmware versions and version 3.7.5 and earlier all work fine and the jogging does not have the fault, but the problem exists in all versions from 3.7.6 onwards.
GCode File
No response
Other Information
No response