Getting the "Tool Touch Off" button to come up ***SOLVED***

I've been having trouble finding the process to touch my tools off and what I've come to realize is that my "Touch Tool Off" button will not allow me to select it.

I was told that it could be because I don't have a probe configured. I'm not sure if that's the case. But I'm pretty sure if I can get this button to work, I may be able to set my tools and start to turn parts.

Well, I hope so, at least.

Any info on getting that button able to be selected? From what I understand without this, I can't really select tools to set.

Scot

When I had this problem, either I hadn't homed the machine, or I hadn't selected a tool (M6).
Hopefully, yours is as simple as that.

It isn't the case in my world. Machine is homed. M6 selected.

In fact, when I input the tool number and M6 with G43 in this format: Tn M6 G43, something got really weird.

The gui hung up. So when I went to tab from the MDI tab to the Manual Control, it just hung there for about 10 seconds before the Manual Control tab showed up, blank. Then it hung for another few seconds until the regular tab was displayed with it's typical selections. Then I couldn't turn on my flood relay through the Gui and had to repower LinuxCNC.

Something is amiss. But I think it's going to be ironed out, soon.

Thanks for giving it the old try,though. I appreciate it, sincerely.

Hi Scot,

system freeze for several seconds sounds really strange.
In my world this happens when a harddisk is dying.

Did you check /var/log/syslog for errors or strange messages?

The hang up happens on one condition. It happens when I input the tool change line. The code is Tx M6 G43, where x is any number on the tool table. When I run a Gcode in machine coordinates, it's peachy. No jitters. No hangups on the gui or in the motion. Just so long as I don't enter that tool change code, it runs fine. But in my quest to find the process to set the tools, running that code is the clear lag and hang up culprit.

Both axes, the spindle through a VFD and 4 outputs all function flawlessly. But trying to set tools is what's making it happen, I think.

I'm guessing that it's some missing code or a portion of the file is suppressed that could allow it. And I've found the process I'm looking for to get the tool offsets to function , but I'm not sure quite how to implement it, yet.

I'll check the path you gave me, though. Thanks.

Hi Scot,

I just finished my tooleditor.

There I read in the tools from definition file named in ini-file.
When the user (me) changes a tool offset, the changes are commanded to linuxcnc via NML interface.
When I then start gcode execution with that tool, I see the new tool offset in statusline of axis ...
... and best of all - changes are persisted without me having to code anything for it
So the changes got active instantaneously.

Ah - and there are no lags, freezes or whatever.
Everything works as expected.

Cheers Reinhard

Scot wrote:

Thanks for giving it the old try,though. I appreciate it, sincerely.

After posting, I came across another of your threads, and thought "yeah, your problem is definitely more complex than I suggested"!
Hope you get it sorted.

Hi Andy,

Do you have any sort of tool handling routine set up?

Not yet. I use manual_tool_change from axis.
I'm working on a replacement for that, but hal is a lot more difficult than nml.
My prototypes all crashes.

Currently I try to do something similar than halui ...

Its very hard to get into.
.

Are you running with no hardware?

Yepp - my bobs are not ready yet
I like to develop electronics but soldering is for me pain in the ass ...
So things need time ...
... and I need a kick in the ass

meanwhile I'm happy that linuxcnc simulation works that good

cheers Reinhard

Finally :-D

I got the hal-part of the toolchanger working.
There's a little bug in halui in function check_bit_changed() - that function triggers if a pin get's active, but does not trigger, if the pin goes low. Pin is then 0 and that value is returned, so no action ...

In case of the toolchanger, you have to reset the tool_changed pin on your own. If not, the toolchanger gets involved on the first toolchange only.

I changed that checker function to return always true, if there is a difference between both pins. Than I check the pin state later in the app - and so I can reset my own out-pin - and the toolchanger gets involved on every request

Toolchanger gets into the play by halcmd and loadusr - now I have to find a way, to bridge to my java app, as I don't want multiple apps painting the screen ...