AXIS GUI feature to allow DRO-type axis behavior when touching off

[tangentaudio]

I have a mill with a non-motorized quill (Z), but it has a magnetic encoder feeding back to LinuxCNC. My goal was to simply view the Z axis like a traditional DRO within the AXIS GUI, and most importantly, be able to "touch off" in different WCS.

With this axis, the "commanded position" never changes (because it's never instructed to move or jogged), but the "actual position" does (via the encoder). The "Touch Off" feature in AXIS doesn't have any effect because the underlying G10 L20 command is only aware of the commanded position.

This is a small patch to change the touch_off_system function in AXIS GUI to incorporate both the touch-off value entered by the user as well as the current axis position into the value sent to the G10 L20 command that does the actual "touch-off" process. It is only active on an axis when TOUCHOFF_ACTUAL=TRUE is set for the desired axis, e.g. in the [AXIS_Z] section of the .INI file.

[andypugh]

I can't help feeling that this is such a specialised use case (that as far as I know only one person has wanted in 20 years of LinuxCNC) that it isn't worth adding.
But then, at the same time, it isn't expensive as your new code only runs in the touch-off routine.

It does, however, raise a point. Shouldn't the touch-off routine use the actual measured position rather than the commanded position anyway?

But, for your patch, I think I would like to see some other opinions before deciding whether to merge.

[tangentaudio]

@andypugh I agree that it's a specialized use case, borne out by the fact that I think I only found one thread on the forum that was similar. Not finding a solution is what sent me down the path of implementing it myself.

Honestly, the main reason I submitted the PR was so I wouldn't have to maintain the patch myself over time, but I certainly understand if it's deemed to be too specialized or not implemented generally enough to be included.

I also wondered about whether the touch-off should always be using the actual position vs commanded, but I don't have a good understanding of the implications of that.

The touch-off code in the AXIS GUI builds a G10 L20 command with the current WCS and user-entered value and sends it to MDI, and ultimately the code that's doing the actual offset is buried deep in the rs274 parser. I initially chased it down to that level to see if I could implement this in that code more generally, but it didn't seem the parser even has knowledge of the machine actual position. As best as I could determine it only seemed to be aware of commanded position, but I only studied the code for an hour or so, and it's pretty hairy stuff to follow.

Cheers,
Steve

[tangentaudio]

This was the thread that I started on the topic. No discussion though, just me talking to myself 😆
https://forum.linuxcnc.org/10-advanced-configuration/55203-configure-a-non-motorized-axis-with-a-linear-scale-dro-mode-solved

[jethornton]

For me a lot of the changes don't do anything like
axis_letter = vars.ja_rbutton.get()
axis_letter_upper = axis_letter.upper()

is the same as this deleted line

text=_("Enter %s coordinate relative to %%s:") % vars.ja_rbutton.get().upper(),

axis_letter = vars.ja_rbutton.get()
linear_axis = axis_letter in "xyzuvw"

is the same as this deleted line
linear_axis = vars.ja_rbutton.get() in "xyzuvw"

offset_axis = trajcoordinates.index(vars.ja_rbutton.get())
offset_axis is the axis number so x=0 y=1 and z=2

s.actual_position[offset_axis] will return the selected axis actual position

new_axis_value = str(float(new_axis_value) + s.actual_position[axis_idx])
could be
new_axis_value = str(float(new_axis_value) + s.actual_position[offset_axis])

for me all I see that is needed is:
if inifile.find(f"AXIS_{vars.ja_rbutton.get().upper()}" , "TOUCHOFF_ACTUAL") is not None:
new_axis_value = str(float(new_axis_value) + s.actual_position[offset_axis])

JT

[jethornton]

A couple more thoughts on this is it's not complete without updating the documentation and I'd change the message shown in the touch off window if that ini entry is being used.

JT

[tangentaudio]

Most of that extra code/changes were to make the function more clear. At least to me, reading axis_letter is a lot more clear in terms of purpose than vars.ja_rbutton.get(). If terse and compact code is preferred over readability, I can certainly make those changes. I will also alter the dialog text to indicate when the actual position is in use, that's a good idea.

I'll see if I can find the correct places to document the change and do that as well.

Steve

[andypugh]

We prefer clear code, but we prefer clear commits even more, ie it's easier to follow the commit history if commits only do what they need to do to add the new functionality.

[tangentaudio]

• cleaned up the code per request with an eye to making a small, clean diff
• added a feature for the dialog to indicate that it's in this new "ACTUAL" mode
• added flexibility to allow adding or subtracting the actual position from the dialog value depending how it's configured
• added documentation

cheers,
Steve

[hansu]

Normally, the operator should assumes that the machine is following the commanded position and doesn't care how big the following error is. That makes it easier to calculate with the displayed values and they are more stable.
Not sure in which case it will be helpful to see the measured position. I only could imagine that the display of the following error/position deviation could be of interest. But that does not belong to this issue.

[jethornton]

Looks good to me.

JT