qt_dragon_hd - manual tool change and remap

11 Sep 2023 05:48 #280454 by cmorley
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.

Please Log in or Create an account to join the conversation.

13 Sep 2023 09:06 - 13 Sep 2023 09:11 #280613 by Vector
I think there might be two bugs, or else there’s something I really am missing in the QtDragon setup.


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?


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:
G38.2 move finished without making contact

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:
Probe tripped during non-probe move

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!
Last edit: 13 Sep 2023 09:11 by Vector. Reason: Formatting for clarity.

Please Log in or Create an account to join the conversation.

13 Sep 2023 13:20 #280635 by cmorley
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 :)


Please Log in or Create an account to join the conversation.

14 Sep 2023 00:44 - 14 Sep 2023 01:39 #280687 by Vector
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.
Last edit: 14 Sep 2023 01:39 by Vector. Reason: Add additional note.

Please Log in or Create an account to join the conversation.

14 Sep 2023 03:01 #280697 by cmorley
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.

The following user(s) said Thank You: Vector

Please Log in or Create an account to join the conversation.

14 Sep 2023 09:46 - 14 Sep 2023 09:51 #280724 by Vector
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!
Last edit: 14 Sep 2023 09:51 by Vector. Reason: Forgot most of the message.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

14 Sep 2023 22:17 #280792 by Vector
I should have attached files. Here's the configuration and the Gcode file.

Please Log in or Create an account to join the conversation.

15 Sep 2023 02:01 #280799 by cmorley
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:

something like:

What do you mean by step through in MDI?
The following user(s) said Thank You: Vector

Please Log in or Create an account to join the conversation.

15 Sep 2023 07:17 #280814 by Vector
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!


Please Log in or Create an account to join the conversation.

15 Sep 2023 07:21 #280815 by Vector
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?


Please Log in or Create an account to join the conversation.

Moderators: cmorley
Time to create page: 0.377 seconds
Powered by Kunena Forum