G00 command movement error on z axis for negative values

[blurfl]

I noticed in the z-axis panel that the raise and lower commands were not symmetrical - issue a 1mm raise followed by a 1mm lower and the router does not return to the spot is started from. This is easiest see when watching the motor coupler. It is also possible to see in the z calibration step of the calibration sequence - the 'move -0.1mm' button does very little except buzz.
Looking into GC, a G00 Zxx command is sent in these instances. I found that if I changed the G00 to G01, the z movement was correct. Further, the positive case (raise the bit) works correctly with G00 or G01. G00 Z-xx will move the motor by an incorrect amount in every instance.
A workaround in the short term would be to change the 'lower' commands in GC to send G01, but the issue is in the firmware handling of G00 on the Z axis.
I've looked around in CNC_Functions.h in the G1() function but haven't found joy. It looks to me like the resulting call to singleAxisMove(&zAxis, zgoto, zfeedrate) is the same whether G00 or G01 is used.
I've found that using the macros to issue the command strings is helpful.

these are symmetrical, change the 'G01 Z-0' to 'G00 Z-0' to see the issue occur
#move .1mm (converted to inches)
G20 G91 G01 Z-0.003937 G90
G20 G91 G01 Z0.003937 G90

#move .1mm
G21 G91 G01 Z-0.1 G90
G21 G91 G01 Z0.1 G90

#move 15 degrees converted to mm (3.175mm / 24)
G21 G91 G01 Z-0.132292 G90
G21 G91 G01 Z0.132292 G90

[blurfl]

I've found more information on this.
PR#315 includes a change that adds the zaxis to the coordinatedMove() in CNC_Functions.h. The function G1() calls coordinatedMove(). CoordinatedMove() is called for all three axes, with feedrate 1000 (a hardcoded value...) for a rapid move - G0 gcode. This seems to be a problem for the z axis in the negative direction, haven't looked for why. In the positive direction the z axis seems to work correctly. Changing the hard-coded value to 500 makes the z axis work correctly in the negative direction in the coordinatedMove() function.
@krkeegan, you've studied this section more deeply than I - can you think of a reason that the negtive direction of the z axis should behave this way? Should we consider adding a separate feed parameter to coordinatedMove() for the z-axis?
A temporary workaround could check for non-zero z axis movement just before the call to coordinatedMove() and set the feedrate to 500 if found.

[servant74]

it may not be related, but a little research I found grbl defines G00 as a 'fast' move command, where the resultant movement may not be a straight line. G01 is a 'linear interpolation' command that moves with all axes coordinated to make the move in a straight line. I just found that interesting.

[blurfl]

That's the crux. In the G0, all three axes move at their maximum speed - that is why the path might not be straight. Before PR#315, the firmware would wait for a z-axis movement to complete before beginning the XY traverse. Now all three run simultaneously in a G1 or G0 command.
This works correctly in a G1 command, and in a G0 command if the z-axis movement is positive (raise), but a wrinkle is causing this issue when negative in a G0. Once the wrinkle is corrected, the z-axis will lower the correct amount while running a G0 command.

[krkeegan]

I won't be able to dig deeply into the code for about two weeks. Inside cordinatedMove there is a process for determining the max zaxis federate. The zaxis cannot do 1000mm/min. If changing to 500 is solving the issue, it sounds like maybe I made a mistake in how this calculation is performed when the rotation or position is negative? Hope that is enough to help someone find the bug.

…

On Oct 22, 2017 1:37 AM, "Scott Smith" ***@***.***> wrote: I've found more information on this. PR#315 includes a change that adds the zaxis to the coordinatedMove() in CNC_Functions.h. The function G1() calls coordinatedMove(). CoordinatedMove() is called for all three axes, with feedrate 1000 (a hardcoded value...) for a rapid move - G0 gcode. This seems to be a problem for the z axis in the negative direction, haven't looked for why. In the positive direction the z axis seems to work correctly. Changing the hard-coded value to 500 makes the z axis work correctly in the negative direction in the coordinatedMove() function. @krkeegan <https://github.com/krkeegan>, you've studied this section more deeply than I - can you think of a reason that the negtive direction of the z axis should behave this way? Should we consider adding a separate feed parameter to coordinatedMove() for the z-axis? A temporary workaround could check for non-zero z axis movement just before the call to coordinatedMove() and set the feedrate to 500 if found. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#321 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC57q6FiZ4giYbQGoNVbbyMrfv92Sqsaks5sumGOgaJpZM4QBZpj> .

[blurfl]

Thanks for your insight, that's where I was beginning to suspect. I see the code section you describe, I'll dig around there.

[krkeegan]

Correct G00 normally isn't guaranteed to be straight. But in the Maslowcnc that type of move could cause the sled to travel off the work piece, so we always make straight moves.

…

On Oct 22, 2017 7:47 AM, "Jack in TN" ***@***.***> wrote: it may not be related, but a little research I found grbl defines G00 as a 'fast' move command, where the resultant movement may not be a straight line. G01 is a 'linear interpolation' command that moves with all axes coordinated to make the move in a straight line. I just found that interesting. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#321 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC57qwz6zVKEjHgraInFI8NuZiIQA9Tiks5supF5gaJpZM4QBZpj> .

[BarbourSmith]

Do we feel good about closing this?

[blurfl]

Yes, 👍