Looking at the GC code, I can’t see why home wouldn’t raise the bit unless, as @bar said, it lost a newline character. Just odd that it would happen at that precise moment. Is it “legal” to ever have two gcodes on the same line, like G00 Z.25 G00 X0 Y0? If not, then the parser could catch a second gcode and make that a second command.
The log.txt file would have had the echo of the lines as they were interpreted by the firmware, yes?
Hmmm… I’ve got a log.txt file with 2 million lines… wonder which one it is 
1 Like
grep back from the end for ‘!’ - that would be the ‘Stop’ sent from GC. Or grep for some variation of ‘X0 Y0’, maybe with 0.0 or 0.00 - that would be part of the ‘Home’ command. The log.txt file gets re-written each time GC is run, though, so the one you see might not contain the interesting bit if GC has run again since the issue.
1 Like
I sorted through it and think I found the offending area. The ##repeats of above two lines## were a bunch of idle statements I deleted. I added the << comments. The G00 Z.25 didn’t do what it was supposed to do, apparently. So the bit apparently never did retract until the G00 Z0 was issued after it stopped moving xy
It’s interesting that it acknowledged the G00 Z.25 command, but never acted upon it. It knew it was at -0.30. Is it possible that a command sent while the kinematics is working out the position can get lost? I issued a stop command later on and it immediately went to setting the target position, but this one (with the problem) had ~90 idles (that I commented out) and didn’t do the calculation until GC sent the G00 Z.25 command.
Sent: !
<Idle,MPos:35.03,-5.15,-0.30,WPos:0.000,0.000,0.000>
[PE:0.01,-0.00,127]
[PE:0.01,-0.00,127]
ok
<Idle,MPos:35.03,-5.15,-0.30,WPos:0.000,0.000,0.000>
[PE:0.01,-0.00,127]
##repeats of above two lines##
Sent: G90
[PE:0.01,-0.00,127]
G90
ok
Sent: G00 Z.25
[PE:0.01,-0.00,127]
G00 Z.25
[PEk:832.73,-487.49,0]
[PEk:704.58,-403.31,0]
[PEk:595.57,-338.93,0]
[PEk:503.01,-289.27,0]
[PEk:424.44,-250.41,0]
[PEk:357.73,-219.43,0]
[PEk:301.07,-194.19,0]
[PEk:252.95,-173.15,0]
[PEk:212.06,-155.22,0]
[PEk:177.34,-139.64,0]
[PEk:147.87,-125.87,0]
[PEk:122.88,-113.55,0]
[PEk:101.73,-102.42,0]
[PEk:83.84,-92.30,0]
[PEk:68.75,-83.06,0]
[PEk:56.05,-74.61,0]
[PEk:45.39,-66.88,0]
[PEk:36.47,-59.81,0]
[PEk:29.03,-53.36,0]
[PEk:22.85,-47.48,0]
[PEk:17.75,-42.14,0]
[PEk:13.55,-37.30,0]
[PEk:10.11,-32.93,0]
[PEk:7.32,-29.00,0]
[PEk:5.07,-25.46,0]
[PEk:3.28,-22.30,0]
[PEk:1.86,-19.48,0]
[PEk:0.75,-16.97,0]
[PEk:-0.10,-14.74,0]
[PEk:-0.74,-12.77,0]
[PEk:-1.21,-11.03,0]
[PEk:-1.54,-9.50,0]
[PEk:-1.75,-8.16,0]
[PEk:-1.88,-6.99,0]
[PEk:-1.94,-5.97,0]
[PEk:-1.95,-5.08,0]
[PEk:-1.91,-4.31,0]
[PEk:-1.85,-3.65,0]
[PEk:-1.77,-3.08,0]
[PEk:-1.67,-2.58,0]
[PEk:-1.56,-2.16,0]
[PEk:-1.45,-1.80,0]
[PEk:-1.33,-1.49,0]
[PEk:-1.22,-1.23,0]
[PEk:-1.11,-1.01,0]
[PEk:-1.01,-0.82,0]
[PEk:-0.91,-0.66,0]
[PEk:-0.82,-0.53,0]
[PEk:-0.73,-0.42,0]
[PEk:-0.65,-0.33,0]
[PEk:-0.58,-0.26,0]
[PEk:-0.51,-0.19,0]
[PEk:-0.45,-0.14,0]
[PEk:-0.40,-0.10,0]
[PEk:-0.35,-0.07,0]
[PEk:-0.31,-0.05,0]
[PEk:-0.27,-0.02,0]
Sent: G00 X22.04 Y-4.81
[PEk:-0.23,-0.01,0]
[PEk:-0.20,0.00,0]
[PEk:-0.17,0.01,0]
[PEk:-0.15,0.02,0]
[PEk:-0.13,0.02,0]
[PEk:-0.11,0.03,0]
[PEk:-0.10,0.03,0]
position loaded at:
889.8
-130.79
ok
<Idle,MPos:35.03,-5.15,-0.30,WPos:0.000,0.000,0.000> <<–why is it still at -0.3???
[PE:0.00,0.00,127]
[PE:0.00,0.00,127]
G00 X22.04 Y-4.81
<Idle,MPos:34.93,-5.15,-0.30,WPos:0.000,0.000,0.000> <<–cutting into wood
[PE:1.20,-0.51,127]
<Idle,MPos:34.80,-5.14,-0.30,WPos:0.000,0.000,0.000>
My suspicion is that for whatever reason, the firmware didn’t get a chance to run the “checkForStopCommand()” routine before the G00 Z0.25 command was issued. In “checkForStopCommand()”, the ringBuffer is emptied and therefore the G00 Z0.25 command would have been lost. It’s clear that the G00 X22.04 Y-4.81 command was sent after the ringbuffer was empty because the controller was setting the target position to the current position (hence the PEk messages).
Before the log reported the "Sent: ! ", the controller was sitting idle for a while waiting on another gcode. It had moved to 35.03, 5.15, -0.30 and was waiting for the next line. It continued to wait and, perhaps coincidentally, when it received the G00 Z-.25 command is when it seems to have started to do the checkForStopCommand(). Does the controller issue a checkForStopCommand while idling?? Why would it? It’s not moving… but if GC is slow to send the stop command for whatever reason, then this could be the problem.
If you’re on a system with grep,
egrep -v ‘([[<].*)’ log.txt
will give you the wheat without the chaff - it ignores lines starting with ‘[’ or ‘<’ 
Had you redefined ‘Home’ for that cut session, or was it still at 0.0,0.0?
I had defined a new home position. It was heading where it was supposed to go… just never actually processed the G00 Z0.25 command. I think GC was slow on sending the “!” and that’s the cause of the problem.
The responses from firmware as printed in log.txt can be separated by many lines. Might need more of the log to see. It’s great that you’ve got the saved log, though!
Understood, but only place checkforstopcommand is performed is when its moving. Is there a reason not to immediately act upon the stop command? readSerialCommand just sets the stopflag as true and carries on, whereas a bufferoverflow sets the stopflag and goes to checkForStopCommand. I’d think when the firmware sees a stop command, it should just act upon it.
if (c == ‘!’){
stopFlag = true;
pauseFlag = false;
}
becomes
if (c == ‘!’){
stopFlag = true;
pauseFlag = false;
checkForStopCommand();
}
That, I think, would ensure that the G00 Z0.25 command doesn’t get cleared from the ringbuffer. The theory might be able to be tested if you move away from home, wait for it to come to a stop, hit stop (assuming GC will send the “!” with no code running) and hit home. If the bit doesn’t go to 0.25, then the problem is with the idle condition.
Seems possible, not hard to test. My machine is torn down right now, though… 
I’ll give it a go right now and see what I can figure out
That is exactly the behavior I see. Moving the machine away from home. The set of steps to cause the issue is:
- Move the machine away from home and wait for it to stop moving
- Press stop (nothing happens)
- Press Home (machine moves directly to home without retracting the bit)
Great catch! If I remember correctly the reason for the flag is that the place that checkForStopCommmand is called from is important. If it is called from directly within the move the function stack will result in the move being resumed when the stop is cleared. That’s just a vague recollection, I’m going to dig into the code right now
3 Likes
I’ll try to test when I get home. Stuck in some traffic.
Sent from BlueMail
But isn’t that what the hold buttons for.
Sent from BlueMail
I think the fix was remarkably easy. The firmware will now check for stop commands even when it is not moving. As far as I can tell this fixes the issue without affecting the way stops work while running a file.
I’ve created a pull request to fix the issue
@madgrizzle Ignore what I said about the function stack. After looking at the code, what I said wasn’t wrong, but it doesn’t apply to what we’re talking about 
2 Likes
Yay! I’m not crazy! (at least, not because of this)
2 Likes