Touch-off via MDI_COMMAND, and Axis confusion

Recently I realized that I was spending way too much of my "get ready to carve" time homing the axes of my 2.5D x/y/z mill. Using the Axis UI involves at least 6 keystrokes or mouse clicks to establish "home" relative to the workpiece, or a similar number (maybe more) to use "Touch-off" instead. So I've configured some buttons on my pyvcp panel which invoke MDI_COMMANDS:

• home X and Y at the same time
• home Z
• auto-home Z

The last one invokes a G-code subroutine that uses my probe in (what I think is) the usual way: Z travels down slowly until the cutter hits my aluminum probe plate, and when it does, sets the Z location to the thickness of the plate, using:

The other two are similar, but without the probing:
and
In order to make all of the above work via MDI without first having to home the machine (which would somewhat defeat the purpose), I've had to set "NO_FORCE_HOMING = 1" in my .ini file. I have no physical homing switches, but I do have limit switches for safety.

This all works well, and I now have one-click manual, confirmationless, homing, as well as the probe feature. It's exactly what I want.

However: While the milling all works correctly, the Axis display is out of sync. When I use the Axis homing, or homing + touch-off commands, the red cutter path on the screen matches (and overlays) the predicted cutter path (in white) that is shown when I first load the file. But when I use my panel buttons, the cutting path is offset from the predicted path. It looks like it's off, on the screen, by approximately the values held in the G54 registers. You can see this in the screenshot.


Ignore the extra paths from a previous project in the upper right (I forgot to erase them), and just look at the spiral hole-boring cut. The white helix is the predicted path from the G-code, and the red-spiral is where the "cutting" occurred on-screen. (The cutting in real life did exactly the right thing.)

Any ideas on why this is happening, and how to fix it? Many thanks...

paul

Hi Paul,
Try
G10 L20 is similar to G10 L2 except that instead of setting the offset/entry to the given value, it is set to a calculated value that makes the current coordinates become the given value.

Thanks. I did look at, and try, G10 L2 earlier. It doesn't reset the current position to 0.0 -- it leaves the current value. Nor does it seem to change the G54, so I'm not really sure what it's doing at all. :-/

You need to force AXIS to reload the graphics display.
We didn't make linuxcnc smart enough to tell the screen to update

There is no easy direct way.
You can use HAL and Axis remote:
linuxcnc.org/docs/2.8/html/gui/axis.html#_axis_remote
(I'm pretty sure there is a forum post somewhere about this)
Surely you could use custom python code to do it -if you know that sort of thing.

I just realized AXIS looks for magic comments for some display controls.
I should add reload as a magic comment control to make this easier.
Can't be done by AXIS, it only reads the file when loaded not running.

Chris

Okay. A fair amount to process here.

Chris -- Are you really saying that HAL can call out to the shell?? Even given that (somewhat surprising!) possibility, I've looked at axis-remote, and the "tell AXIS to reread all the internal registers" command isn't jumping out at me from the usage message. And I know just enough python to shoot my foot off, so I'm game. But I didn't think pyvcp could invoke python directly -- has that changed? Is there anything at all I can do via MDI that would cause axis to refresh? Some mode I could set, then unset, perhaps?

And tommylight -- can you expand on "%halcmd setp axisui.refresh 1"? I getin linuxcnc 2.7.15. Should I expect otherwise?

paul

No HAL can't send to the shell directly/ You would use an Mcode to call an external program (shell python etc)

axis-remote - you would use the --reload command.
I think this would work . you could try it manually first before spending lots of time on the code.

calling a python program like this might do it (untested):

Tom's idea would use the python modification-to-AXIS technique that apparently Plasmac uses - I don't see the actual code in the link he posted.
the code must add the pin to AXIS.

This guy was using gladevcp which gives more options.
In his case he wanted to load a program via a button - but it's the same principal.
forum.linuxcnc.org/48-gladevcp/38063-com...p-button-call-python
Chris

Excellent. Thanks -- that helps a lot. Yes, "axis-remote --reload" seems to fix things. I hadn't thought through that reloading the file would also reset the UI in other ways.

I'll look into your other suggestions. I wasn't familiar with M-Codes before. Looks useful, to say the least!

paul

Okay, this seems to work:
I had to put the reload into the background. Before doing so, I was getting this error:
I'm still a little confused about all this, though. As I think back, I've been using my probe routine for auto-homing Z for a couple of weeks, and it hasn't exhibited the "stale display" problem that my newer manual buttons have shown. Why wouldn't my probe routine show the same problem that they do? (I'm afraid I'll be away from my mill for several days, so won't be able to retest for a while.)

paul