I’ve been experimenting with the G38.2 Probe command.

I’ve been experimenting with the G38.2 Probe command. After some early confusion with the Touch Plate widget in Chilipeppr, I don’t plan on machining PCBs, I drove into the widget’s programming to learn why my results were varying.

I’ve now started working a new, fairly comprehensive, widget as one of my discoveries is the current widget resets the machine absolute z-value. Coming from a manufacturing background, I would prefer that once I home the machine that the machine zero remains at X-min, Y-min, and Z-max. (My Gcode files generally contain a G53 Z0 at the end of the program to clear the head from the workspace. This is a bad idea if absolute Z0 has been redefined to the top of the work piece or the machine bed.)

Through my testing and development, here are a few items I’ve learned.
G38.2 runs in the machine coordinate system (G53) and machine units (mm).
The code line is: G38.2 Xn Yn Zn Fn
Zn (where n = the designation value)
Fn (where n = the feed rate in mm/min)
(TinyG will accept multiple axes in the arguments)

Reading the TinyG programming, G38.2 requires Fn but actually testing shows that it is optional. I highly recommend defining the feed rate as the command will read the last issued feed rate and apply it to the probe cycle. (not a good idea if the last F-value was 2000 mm/min)

Rotational axes (A, B, C) are not allowed as target values

Minimum probe travel: The command will run with differences less than the 0.254mm as defined in the TinyG programming. (On a test frame, I’ve run values as small as 0.001mm, but have not tested for accuracy on a physical machine. I believe best results are to use travel values greater the 0.254mm)

G91 (relative distance mode) has no effect on the G38.2 command. G38.2 runs in the absolute coordinate system and the axis words are also values in the absolute coordinate system.

When the command is executed, the controller switches to the machine’s absolute coordinate system. The axis word(s) is the designation point. The machine will move from its current position to the designation point. If the:
designation point value > machine point, the head moves
away from the work surface,
designation point value < machine point value, the head moves
towards the work surface.

Hopefully these tips will help anyone working on developing probing routines.

Hats off to John and everyone that continues to develop Chilipeppr into a comprehensive CNC software package, great job everyone.

This is a really nice post. Totally agree with you. Can’t wait to see the tweaks. Agreed resetting g53 is the wrong way. The harder way is to set it for the current wcs. Would love to see how you do it.

I’ve gotten sidetracked with G28/G30 syntax and usage, but that is the next step. The lazy way out is to have the users select the coordinate system from a drop-down or radio button.

@Kenny_Barsch I assume you are aware of the Q&A&B(as in bug report) channel here: https://github.com/synthetos/TinyG/issues. It is a somewhat more disciplined way to get the tinyG developer’s attention and input and follow-thru. I also assume you are aware of other tinyG command level features that are dependent on the “tinyG way and assumptions” of homing and manipulating coordinates, such as the implementation of Soft Limits after a homing cycle.
I think I understand what you are addressing, and probably agree with your general direction, but do wonder about potential side effects as much of this area of tinyG functionality is only exercised by CNC experts such as yourself.

@cmcgrath5035 Thanks for the link. I think overall that the command is running as intended and following specification definitions.
It seems like several folks are playing with the Probe command so I just wanted to relay some of the items I’ve learned through my explorations.
Maybe the Fn and min travel are a little buggy, so I’ll post something over in the Q&A&B.

Updated tip:
G38.2 will run in both G20 and G21.
Zn - is read based on unit definition
In G20 - Z-2, will be read and converted to
-50.800mm for machine coordinates

Fn - is read based on unit definition
In G20 F1, will be read as 1" and converted
to 25.4mm/min for machine coordinates

@Kenny_Barsch I realize that I am late in sending you this, but I just wrote that functionality into a touchplate widget if you want to try it out. I assume you know what you’re doing with Gcode, but if you don’t want to deal with JavaScript, I might have done some of the work already.

@Andy_Meyer thanks for the link. The programming is my distraction and relaxation from the grind of work. You’ve kept your’s simple, whereas I’ve gone over the top. Due to the nature of my work, I’m about ready to develop the validation protocols and start regression testing, but if you want to take a look at what I’ve got, its running in my development space at http://chilipeppr.com/masterlefty

I don’t have my inputs automatically converting between in and mm, but it does track and update based on the defined units. I do have automatic updates for WCS, choice of WCS or G92, and working fixed touchplate implementation.

@Kenny_Barsch Enjoy that, then. I understand what you mean about getting away from one thing by working on another.

@Andy_Meyer Where can i see your widget-super-touchplate … i mean in which chilipeppr workspace? Link?

http://www.chilipeppr.com/pyroavr-tinyg
I am working on getting it into the mainline TinyG workspace, but I have to make a tutorial first.

@Andy_Meyer let me know when you’re ready for it to get added and I will add it. Or better yet, just do a pull request to me on Github for the core TinyG workspace repo.

@jlauer It’s ready to go, I’ve even had time to test it out, and I’m pretty sure it’s working. As I did not clone the chilipeppr/workspace-tinyg in order to create my widget, and pyroavr/pyroavr-tinyg is not up-to-date with chilipeppr/workspace-tinyg, I cannot make a pull request. How would you like me to do this? The for the widget is located at http://github.com/PyroAVR/widget-super-touchplate

On that note, my workspace is where I experiment with things, I don’t think it would be wise to merge it with the mainline, in case I have mistakenly changed something undesirable.

@jlauer I did make a pull request, the only issue seems to be the readme file, which was auto-generated. I made this during the switch from jsfiddle to Github, and so my readme is slightly different than the mainline one.

@Andy_Meyer ok i’ll check it out.