giseburt
commented
6 years ago It should be explained here: https://github.com/synthetos/g2/wiki/Marlin-Compatibility
In short: “G28 X Y” is not valid parsable gcode (along with a slew of other cases outlined in that link), and normally an error is thrown accordingly.
g2core has the concept of gcode “flavors” - of which it knows of two at the moment: g2core (default) and Marlin.
When in Marlin gcode flavor special handling is added to interpret these cases specifically. In this case, two exceptions are made:
1) It assumes a “0” was the number part of a gcode word (a letter-then-number in a gcode line) if another word is started without a number. This internally translates “G28 X Y” to “G28 X0 Y0” so it works with the gcode handlers.
2) G28.0 is rerouted as an alias of G28.2. This means G28.0 is no longer accessible in Marlin Compatibility Mode.
In order to get the flavor mode switched to Marlin (at boot it defaults to g2core so there is no loss of functionality) we have to see something that clearly is only Marlin gcode. Any of the Marlin M-codes that come from a slicer (in the gcode file) will do that.
(Note that the communications protocol is switched independently, so Cura can send g2core gcode in Marlin’s limited protocol or a g2core-native sender can send Marlin gcode without losing rich status reports and such.)
When Cura connects to a machine, it generally always follows the same pattern, usually starting with handling the bootloader found on the Arduino Mega. (We fake one to catch this.) Somehow this is getting skipped in this circumstance.
A workaround would be to ensure that you always send a temperature control command first. Those Mcodes are all Marlin flavor.
One possible enhancement would be to specifically catch numberless words as Marlin flavored gcode. It’s risky however, because a mistyped gcode at a console could flip the gcode interpreter into Marlin mode, which is bad if the rest of the gcode coming is actually in g2core flavor.
A second option is to make Marlin flavor gcode the default at compile time. This would also require a means to explicitly switch the gcode flavors to g2core in order to reach the full feature set of the firmware. (I’ll have to check, we might have done that switch ability already.)
-Rob On Fri, May 18, 2018 at 8:59 PM Brian Fife notifications@github.com wrote:
Cura uses the command G28 X Y to home the XY axes from the interactive UI (when the Printrbot G2 board is connected via USB to a PC running Cura).
When this command is sent to a printer in a 'clean' state (recently power cycled), sending the command "G28 X Y" returns an error - "Error: Bad number format".
(It looks like the G28.2 command would get the desired response from the board.)
That's an issue getting Cura to run as expected out-of-the-box. There's another interesting angle to this, though. When I've run a print on the board and then issue the same command "G28 X Y" it homes the board just fine. Power cycle the thing, and the same command fails with "Error: Bad number format".
Do you know what is behind this inconsistent behavior?
Thanks, Brian Fife
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/g2/issues/351, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXj0VgjQNOKhvO3e9rJMGFNE4FXzxI6ks5tz3ycgaJpZM4UFiJ9 .
BDFife
Cura uses the command G28 X Y to home the XY axes from the interactive UI (when the Printrbot G2 board is connected via USB to a PC running Cura).
When this command is sent to a printer in a 'clean' state (recently power cycled), sending the command "G28 X Y" returns an error - "Error: Bad number format".
(It looks like the G28.2 command would get the desired response from the board.)
That's an issue getting Cura to run as expected out-of-the-box. There's another interesting angle to this, though. When I've run a print on the board and then issue the same command "G28 X Y" it homes the board just fine. Power cycle the thing, and the same command fails with "Error: Bad number format".
Do you know what is behind this inconsistent behavior?
Thanks, Brian Fife