RFC: New G-Code: Disregard tool offsets

---Background and rationale---

I have a Mendel 3 Tricolour from RepRapPro. I've been trying to a track down a bizarre problem: after printing, the next G28 (home all) command was causing the machine to Z-crash. Very annoying, esp. since Mendels have two Z-axis motors and can thus drive the head into the bed *very* hard.

For those unfamiliar, this printer has an optical X endstop, a microswitch Y endstop, and an optical Z endstop. The Z endstop consists of a white square located under the bed.

I believe I have tracked down the issue, and it's a rather nasty situation. The Mendel 3 runs on Duet; the firmware is here: [https://github.com/reprappro/RepRapFirmware]. Gcodes.cpp's implementation of G28 is simply to execute the script /sys/homeall.g, which simply runs a sequence of G1 commands to detect the X/Y endstops, then positions the head so the sensor is over the white square, then moves the head down until senses the white square.

I believe the issue is this: if the previous print ended with a tool other than T0 active, the current tool offsets are applied to the G1 commands in /sys/homeall.g, so the final G1 command does not position the sensor over the square -- instead it positions it off of the bed.

---end background and rationale---

I'm thinking I could add couple of new commands, one to disable tool offsets, and one to reenables them.
Based on reading the NIST RS274NGC spec, using G54/G55 to enable/disable tool offsets might be in line with the original intent.

What do you guys think?

*** EDIT ***

Okay, after sleeping on it (and considering what dc42 just wrote) I would propose the following

Modified commands:
G0, G1, G2, G3: New parameter Pxxx
Omitted = Use current tool offsets (the default and classic behavior)
0- = Use the same tool offsets as configured on G10 Pxxx
-1 or invalid tool = Use all-zero tool offsets

New command:
M137: Set current coordinate system offsets (137 is unused, based on [reprap.org])
M137 Pxxx Sy
Pxxx - Tool in question (if omitted, default is current)
Sy - y=0 read and output current settings, y=1 to set
(I'm still on the fence as to whether S should default to 0 or 1, or if I should flip it to S0=write S1=read)

I constructed it this way to try the minimize the number of surprises.
Examples:
M137 P-1 S1 - Sets current offsets to all zeroes
M137 P0 S1 - Sets current offsets to those in G10 P0
M137 P1 S1 - Sets current offsets to those in G10 P1
M137 S1 - Sets current offsets to those defined (using G10) for the current tool; basically, this would undo any other M137 commands
M137 S0 - Outputs current tool offsets
M137 P0 S0 - Would output the tool offsets that M137 P0 S1 would use
M137 P-1 S0 - Would output all zeroes

*** EDIT 2 ***

Alternatively, instead of G{1,2,3,4} Pxxx, I could make it G{1,2,3,4} Txxx and have that mean "move tool xxx". This would be relevant for things like dual-axis printers where each tool (extruder) is mounted on an independent X-axis. And if I did that, should I have M137 use Pxxx or Txxx?

Edited 2 time(s). Last edit at 11/24/2015 10:04AM by Stevie-O.

I understand the problem. I have a dual extrusion Ormerod running RepRapFirmware, but I don't have that problem, because I use a proximity sensor that doesn't need a white target so it works anywhere on the bed.

I can think of two ways you can avoid the problem without any firmware changes:

1. Put a T-1 command in homez.g and homeall.g to deselect all tools.

2. In homeall.g and homez.g insert G10 commands at the start to set all tool offsets to zero. Then more G10 commands to restore them at the end. The snag is that you will have to keep the offsets in those final G10 commands the same as the ones in config.g.

Instead of implementing new gcodes, I am more inclined to add a parameter to the G1 command to mean move the head reference point to the specified coordinates instead of the current tool.

Edited 1 time(s). Last edit at 11/24/2015 03:38AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I can think of two ways you can avoid the problem without any firmware changes:

1. Put a T-1 command in homez.g and homeall.g to deselect all tools.

Actually, according to [http://reprap.org/wiki/G-code#T:_Select_Tool], even that wouldn't work; choosing an invalid tool deselects the current tool but would *not* affect any current commands.
Someone else had the similar suggestion of T0, but that might result in T0 being heated up when it oughtn't be.

Quote
dc42
2. In homeall.g and homez.g insert G10 commands at the start to set all tool offsets to zero. Then more G10 commands to restore them at the end. The snag is that you will have to keep the offsets in those final G10 commands the same as the ones in config.g.

And that snag is why I didn't do that. It is my firm belief that the firmware should do work for me, not the other way around

Quote
dc42
Instead of implementing new gcodes, I am more inclined to add a parameter to the G1 command to mean move the head reference point to the specified coordinates instead of the current tool.

I can get behind the addition of a parameter to G1 (and friends), esp. since there seems to be a good one that's not used: Pxxx. Actually, we can use Pxxx as basically a per-command tool selection, which would be even more flexible. I've been reading about some of the more exotic setups, including one with a dual X-axis so the two extruder heads can move independently.

However, I can't rule out the introduction of a new G-code (or M-code, as the case may be) because realistically, it's a lot easier to just drop a couple commands at the beginning and end of home{x,y,z,all}.g than to edit every single G1 line. (Also, I'm wondering about how things like G92 behave if there is a nonzero tool offset in effect.)

As such, I've revised and expanded on my proposal in my original message.

Quote
Stevie-O

Quote
dc42
1. Put a T-1 command in homez.g and homeall.g to deselect all tools.

Actually, according to [http://reprap.org/wiki/G-code#T:_Select_Tool], even that wouldn't work; choosing an invalid tool deselects the current tool but would *not* affect any current commands.

Don't hypothesize, just try it. I would not have suggested it had I not been confident that it would work. Deselecting the current tool will remove that tool's offset from subsequent move calculations.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
Don't hypothesize, just try it. I would not have suggested it had I not been confident that it would work. Deselecting the current tool will remove that tool's offset from subsequent move calculations.

A touch, I do confess!

The wiki's description of how Tx is handled is indeed inconsistent with how RepRapFirmware is written -- the current tool's G10 settings are actually factored in by LoadMoveBufferFromGCode. Which suggests another bug, which I'll test for tonight.