Traveling Z offset

Phaedrux

I'd definitely stick to G31 for the Z offset.

I'm not sure what kinds of weird behaviour you'd be getting. G30 and G29 would be using the offset from G31, and then your G10 offset would be getting applied after. That's a confusing way to go about it.

What was the reasoning around using G10 instead of G31? @jstevewhite @kraegar

duetal

@phaedrux no reasoning other then reading @jstevewhite suggestion. I took out G31 offset and only G10 L1 gets applied. I can switch it back to G31 but same behavior was present with G31 before switching to G10

Phaedrux

This may be the same issue that he had been posting about here just the other week.

https://forum.duet3d.com/topic/10916/weird-bed-mesh-behavior-after-z-leveling

duetal

This post is deleted!

Phaedrux

This post is deleted!

duetal

@phaedrux interesting didn't see that one. let me read it. Thank you

jstevewhite

@phaedrux

Tool offsets are critical to the eventual application of the tool changer to the RailCore chassis. G31 is for PROBE offset - which is fine if you have only one tool, but if you have multiple tools, it's insufficient for configuration.

That's what got me testing it. While testing it, it became clear that the tool offset is MUCH more user friendly. You'll note that bmveee had the same issue prior to switching to the G10 tool offset process, and the issue in the other post that you mention occurred with G31 and G10 tool offset as well.

If G10 doesn't function properly, it's still broken, even if you can work around it with G31. I don't think that's related to this issue, though, but there's certainly something strange going on. The M500 wasn't saving the tool offset like it's supposed to. Specifically, in my gcode console I can issue:

G10 L1 P0

and get:

G10 L1 P0
Tool 0 offsets: X0.00 Y0.00 Z1.70, active/standby temperature(s): 0.0/0.0

This is mirrored in my config-override.g:

; config-override.g file generated in response to M500 at 2019-06-27 16:10
; This is a system-generated file - do not edit
; Heater model parameters
M307 H0 A90.0 C700.0 D10.0 S1.00 V0.0 B0
M307 H1 A618.9 C194.1 D4.1 S1.00 V24.3 B0
M307 H2 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H5 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H6 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H7 A340.0 C140.0 D5.5 S1.00 V0.0 B0
; Probed tool offsets
G10 P0 Z1.70
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00

while troubleshooting with bmveee or duetal (I think that's mspal from our discord ) I noted that M500 never wrote their tool offset to the config-override.g. This is unexpected behavior, and is sufficient in and of itself to result in unpredictable behavior. That's when I recommended they post in the duet forums.

Specifically, I had one of them put M501 at the end of their config.g (This should load config override). Then issue:

G10 L1 P0 Znnn.n (insert number here)
then
M500
and the entry does not appear in config-override.g as it should. This is clearly a problem, but I can't seem to figure out why. Mine works as expected.

duetal

yep thats me My config-override.g file was time stamped when i did M500 but G10 L1 P0 was not saved into it. I tried it multiple times and ended up removing M501 from the config.g

This is my config-override.g
; config-override.g file generated in response to M500 at 2019-06-28 20:57
; This is a system-generated file - do not edit
; Heater model parameters
M307 H0 A274.3 C798.5 D9.1 S1.00 V24.1 B0
M307 H1 A304.7 C170.2 D4.6 S1.00 V0.0 B0
M307 H2 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H4 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H5 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H6 A340.0 C140.0 D5.5 S1.00 V0.0 B0
M307 H7 A340.0 C140.0 D5.5 S1.00 V0.0 B0
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00

dc42

G10 tool offsets are only written by M500 if they were measured by probing or they were read from config-override.g.

jstevewhite

@dc42

Is this intentional behavior? I ask because it seems to leave out anyone who might manually configure multiple tools. I see why mine is working (because i tested touch-off G10 settings for our eventual implementation of the E3D toolchanger on RailCore 2), and it's worked ever since (because it was already there, I suppose).

So in order to make this work manually, you have to manually enter it into config-override.g once, reboot, and then changes will be written?

cts5191

Bump (curious to see reply from dc42)

dc42

@jstevewhite said in Traveling Z offset:

@dc42

Is this intentional behavior? I ask because it seems to leave out anyone who might manually configure multiple tools. I see why mine is working (because i tested touch-off G10 settings for our eventual implementation of the E3D toolchanger on RailCore 2), and it's worked ever since (because it was already there, I suppose).

So in order to make this work manually, you have to manually enter it into config-override.g once, reboot, and then changes will be written?

The behaviour is designed to give you this choice:

Measure your tool offsets and put them in G10 commands in config.g. Check that you have no G10 commands in config-override.g. This is the recommended solution if you do not manually change tools very often.
Measure all your tool offsets by probing, and use M500 to write the to config-override.g.

If you prefer to hold all the tool offsets in config-override.g even if you didn't measure them by probing, then you can add G10 commands manually to config-override.g as you suggest, so that M500 always rewrites them.

jstevewhite

@dc42

Ah, ok, that makes sense. Add it to the config-override.g manually. I just wanted to make sure that was an appropriate way to achieve the behavior I'm looking for.

Thanks!