Should the Duet support G00 and other G0x commands?

meeloo

Hello,

In my quest for setting up a CNC with an ATC I started to use this very handy Fusion 360 plugin https://github.com/TimPaterson/Fusion360-Batch-Post that enables me to batch export all the jobs in a CAM setup and bypass one of the limitations of the free Fusion license. However that plugin uses G00 and G01 GCodes instead of G0 and G1 and the Duet3 goest bonkers when it receives it (well, at least it doesn't behave like it would if it had received G0 and G1). I proposed a fix to the author in order to support the Duet3 and other RepRapFirmware boards natively but he replied that this was the standard (https://github.com/TimPaterson/Fusion360-Batch-Post/issues/68).

So I'm asking here: shouldn't RepRapFirmware add logic to the GCode interpreter to remove all leftmost 0s in G commands until the last digit to offer the biggest compatibility with existing GCode generators?

meeloo created this issue in TimPaterson/Fusion360-Batch-Post

open Restore Rapids adds transforms G0 that are already produced by the post processor into G00 #68

chrishamm

@meeloo That's right, AFAIK there shouldn't be a difference between G00 and G0 or G01 and G1 respectively. What firmware version are you using?

meeloo

@chrishamm I'm on 3.5.0-rc.3+

dc42

@meeloo are you running in standalone mode or SBC mode?

meeloo

@dc42 I'm running standalone

dc42

@meeloo G00 and G01 commands work OK for me in standalone mode. Tested in RRF 3.5.0-rc.4 but I think it's always been that way.

meeloo

@dc42 that's very strange, I had to manually edit the code to replace all occurrences of G00 and G01 to G0 and G1. I'll try again asap and post a complete report of the behaviour I'm seeing!

chrishamm

@meeloo @dc42 I just tried to reproduce this in SBC mode and G00 is interpreted as G0, and G01 is interpreted as G1. I couldn't see a difference between G00/G0 and G01/G1 from a USB terminal either.