Can G30 report encoder position when triggered?

[mulcmu]

Is it possible to have G30 print the encoder positions where the probe was triggered or corrected position when probe compensation is enabled? I've been manually using G0 to return to the nozzle to the triggered z position and then M114 to report the encoder values.

This would supporting testing a calibration idea where a calibrated target paper is used in to optimize M666 X Y Z and M665 L R A B C D E F X Y Z. The target paper is attached to the bed, the nozzle is moved to each target location, bed is probed with carbon paper in position, x & y are manually adjusted until the probe mark is in center of the target. After all targets are probed, the encoder values for each tower are known for the x y & z=0 locations of the targets. I've had okay results so far with scipy.optimize returning sensible calibration parameters with dimensionally accurate prints.

[aegean-odyssey]

Currently, G30 does a "report position" at the end of its cycle, but it's after it moves the nozzle up (like it's been stowed). It seems to me that what you're asking is the proper behavior, and that the changes will be pretty much a wash as far as code space and performance go -- so doable.

The G30 (and G29 and G33) have a "verbosity" parameter V that I've tried to do useful things with, but there are some conflicting ideas going on in the code. As all three G-codes use the same "probe tap" code, I'd like to get some common functionality into the V parameter for G29, G30, and G33. Right now it's a bit of a mixed bag.

So what should a bed tap report? I'm thinking X Y Z Q A B C. I would like to make this work consistently with G29, G30, and G33

[mulcmu]

Yeah, I found the currently reported z position for G30 is around 5mm higher which can be confusing.

Consistency between G29, G30, and G33 reporting X Y Z Q A B C for bed taps the same way for given V level would be great. I can't think of anything else to report, unless you think there is any beneficial debug output from the probe compensation logic that might be worth including. Reworking the M114 output with these changes might save some program space if it could be integrated easily.

Having Q reported only when mesh is present in the same output line will make parsing the output a bit more difficult. Printing A B C on one line then X Y Z Q on next seems like a good way to go to reduce impacts or compatibility with user's existing scripts.

Bed A: 6418 B: 3009 C: 6419
Bed X: -42.407 Y: 24.498 Z: 2.134 Q: 2.578

[aegean-odyssey]

Good point about parsing. Q needs to be at the end, always. As far as the V parameter, it's a bit tricky since it's used differently among G29, G30, and G33, and its use is a bit overloaded to boot.

So, I'm thinking:

G30, G29, G33:

• V1: report the BED tap position XYZ and maybe Q (BED X Y Z [Q]).
• V2: also report ABC and maybe XYZ' (BED A B C [X' Y' Z']). XYZ' are values after the Z correction. They shouldn't change, but it appears that they do.
• V3: also report the actual (2x) taps

G29:

• V4,V5(V4+V1),V6(V4+V2),V7(V4+V3): print the bed level map after probing plus the tapping information

G33:
Similar to G29, but not sure how it comes together, and I'm trying to get the firmware into a state where I can focus on the G33 command, so it's in flux in my mind.

I think these changes are workable -- I'll see if I can make it happen. Point out the flaws.

[aegean-odyssey]

As of release 119r15:

more information, relevant for delta style printers, is part of the M114 "position report" code and the G29, G30, and G33 calibration and probing sequences.