qt_dragon_hd - manual tool change and remap

You should have 30 seconds before timeout. I should probably make it user settable.

hmm the g53 error is probably a bug, I think g53 should ignore incremental mode.

I think there might be two bugs, or else there’s something I really am missing in the QtDragon setup.

First:

On the G53 error: to clarify: I’m not issuing G53: I’m saying T2M6 after a failed toolchange. So I think it’s inside the qt_auto_probe_tool.ngc program… are you suggesting a change to that programs handling, or to the handling of G53 in general?

Second:

On the probing error, it’s weird and possibly is a bug:

To reproduce it is easy:
Turns out I wasn’t spending more than 30 seconds trying to reach the probe: I had set the location to a point too high: so essentially it arrives at the wrong location (not low enough), it since it therefore cannot trip a probe signal, it backs off and says:
 

OK, so we know it is trying to probe (G38.2) . (I wasn’t precise in my earlier post, I called this the “time out error,” but maybe there’s another error msg for that.)

So far so good: now we go and change the location in the ini file back to one where the tool will hit it, restart the program.

Reissue T2M6.

Now after the tool change, as it is lowering itself down toward the toolsetter, the moment the tool hits the toolsetter, instead of backing off to probe slowly, it says:

It stops right there. Argh! But a moment ago it was telling us it was doing G38.2 and probe-moving??

Soooo… either there’s a bug in the QtDragon stack that’s not letting T2M6 work the probe, or there’s some flag setting or configuration in said stack which I’m missing.

It could well be the second thing, since this error comes from control.c, right under a bunch of flag checking that I’m too inexperienced to know how to chase to ground, and the wise warning: “not probing, but we have a rising edge on the probe, this could be expensive if we don't stop.”

But in summary, the G38.2 message means we should be “in probe mode,”
but whatever control.c is safety-checking says we haven't set up probe mode well enough. 

There is a setting in the settings tab that says “Use Tool Sensor,” and it’s normally off. But I have tried it both ways, and I still get the same behaviors for both “probe tripped during non-probe move” and "G38.2 move finished without making contact."

Any help would be golden, thank you!

My guess is the tool hit the probe while the tool was still moving into position rather then when probing.
if you have linuxcnc running, then open a terminal and type:

qtvcp test_probe

You should get a small window with a text label and a button.
The label will tell you what type of movement is currently happening.
it must say 'probe' when the probe is tripped otherwise you need to adjust the tool setter Z level higher so probing starts sooner.

And yes accurate error messages are important

Chris

Thank you.

That gets it working!

(That widget is so cute! Is there one for, say, displaying DEBUG messages? Is there a list of these widgets somewhere?)

For the traveler finding this thread (maybe my future self), what this answer means is that one must set the following parameters in the .ini file under [VERSA_TOOLSETTER]:

The X, Y and Z parameters need to get you to the tool setter with this important caveat:
X/Y need to be as accurate as you need for the kind of tool you're probing... ie if you have a side-cutting tool, you might need to alter this somehow to position only the blade over the measurer, not the 'nut.'
Z needs to be a point far enough before reaching the toolsetter that all your tools will fall short of it.
MAXPROBE needs to be a distance for Z that is long enough that your all your tools will finally hit the toolsetter.

The system will do a Rapid move to the XY coordinates, then a Feed move down to the Z coordinate, then continue a Probe move for the Maxprobe distance.

Note1: that even though the documentation shows an example with a negative number for Maxprobe, I could not make that work: I needed a positive number.)

Note2: The MAXPROBE in the .ini file under Versa_toolsetter is not the same as the MaxProbe on the Settings Page: that refers to using a probe for doing touchoff.

Thank you for the feedback. I will try to incorporate the jest of your observations into the docs.

I believe the originator of this technique was using small endmills on a router, so the tool tips always touched the probe without offsetting.
In the future maybe we could use the diameter in the tool table to offset the tool from the probe.
better yet might be to utilize the newer tool data base to add entries such as tool probe offset.

I'm glad you have got this far - please keep up the feedback.

Chris

Thanks for your help! I apparently need a lot of it 

Is tool change supposed to return to the original location where the tool change was called?

Or is that the responsibility of the G-code that called the tool change?

(I exported from FreeCAD, and it does not return it to the start point... it seems to assume once M6 T2 and G43 H2 are issued, it's good to go M3 S3000 and head straight down... very scary after the tool change finished and it turned on the spindle and then just dived straight down toward the tool setter with the cutter whirring away).

Is there a guide on how to use the step through feature in the MDI window? I'm wondering if I have to put in special comments or something.

Thanks again!

I should have attached files. Here's the configuration and the Gcode file.

after probe finishes it ONLY moves to [CHANGE_TOOL] Z position.
If you wish to move back to [CHANGE_TOOL] in X and Y, you would need to change qt_auto_probe_tool after this line:
github.com/LinuxCNC/linuxcnc/blob/2.9/nc...o_probe_tool.ngc#L77

something like:
G53 G0 X[#<_ini[CHANGE_POSITION]X>] Y[#<_ini[CHANGE_POSITION]Y>]

What do you mean by step through in MDI?

Got it!
I'm going to crack the seal on qt_auto_probe_tool and make an additional change to the one you suggest....

I'll answer your question about my question about Step through on the MDI in a second post so as not to clutter this one more than it will be... because....

...if you have time... I have a few questions:

Is having the M6 remap code not return to the point where the tool change was called the normal way?? Is it advisable?

(Discussion research follows:)
In the Axis Sim , I think they "move back to toolchange position: z, then xy," ie, at least they go back to tool change, but not back to the workpiece.
At PrintNC , their solution involves two files, but the philosophy in their tool-change.ngc is to go all the way back "to the original position," ie, back to the workpiece
This thread by orangecat also seems to have been picked up by PrintNC and others and seeks to return to the original workpiece.
I don't have a link, but don't auto-tool-changer remaps complete the journey back to the workpiece?

So, would it be a valid idea to have us move all the way to the workpiece? Wouldn't that be desirable?

I'm going to work on that tonight, and I'll post back what I find... I'm happy to do the github work as well, but I don't want to step on any toes, so if I should just post here for someone more experienced to PR it, or if it's anti-qtDragon philosophy, then no worries. 

I think the work by orangecat and PrintNC was before local and global variables were added to ngc, so their code was maintenance heavy: but it was nine years ago!

 

By stepping through the MDI, I'm probably naming things wrong...

I meant in this part of the interface, it looks like I should be able, after I load a file from disk with g-code or ngc code, etc, to press Cycle Start but have some control to prevent it from immediately processing all the way to the end...

IE, those 'greyed out' Pause and Step buttons... how do I use them?