Tool change Z probing problem

[Piney-Grove (D. Wagner)]

New to the game. Trying to machine a software provided relief or a down loaded .stl model using Carveco software, clearing tool seems to do its job every time how ever after tool change and probe 1/6" ball end cuts air, every time .110" high.Used 2 different computers and software sets same result. Any ideas? Thanks

[OnefinityCNC (Onefinity Support)]

what firmware are you running?

[Piney-Grove (D. Wagner)]

1.0.5 And Thanks for getting back to me on this.

[Piney-Grove (D. Wagner)]

Next piece of the puzzle, I updated the firmware on the off chance that would resolve the problem. Same results, after tool change and probe still cuts air. The carveco software generates the tool paths for the roughing tool and the finishing tool at the same time, so instead of saving them both as one file I saved and ran the separately, and the cut was near perfect. It appears that what ever is happening occurs at the tool change and probe when I am prompted to change the tool and probe. Again any ideas. Thanks

[FrothyMolasses]

I am having this same issue. I am running firmware 1.0.9 and using Carveco 1.37. After performing a tool change and probing z the next cut is .110" high.

[OnefinityCNC (Onefinity Support)]

each tool must be it’s own file.

[FrothyMolasses]

That was my workaround. It is unfortunate since running an area clearance you have to accept the longer tool run or modify the toolpath to carve only around the intricate areas that require the smaller diameter cuts. Out of curiosity is this limitation tied to carveco or the onefinity controller?

[OnefinityCNC (Onefinity Support)]

It’s the controller, not carveco.

[Piney-Grove (D. Wagner)]

This was almost 2 years ago, had to do some remembering and digging trough old emails and this is what I found. If you are using a touch plate with different dimensions than the 1 onefinity sells then this is the resolution, this is the copy and pasted contents of the correspondence I received. Ultimately I stopped using the touch plate in lieu a piece of paper and running separate files for each tool, I get much more consistent results.

"The Development team came back with this:
There are two places where the probe dimensions need to be entered:
-The settings page (used for the probe buttons)
-In the tool-change gcode under settings. This code is executed when the controller finds a tool change command in the gcode.

So when changing the probe dimensions, it will affect the probe xyz and probe z buttons…but you’ll need to edit the tool-change gcode under settings also so it will adjust for the tool change your performing. Try it out and let us know if it works!

[B2Bass]

You’ve got to be kidding me???!!!
is there a newer update to this?
I’m running 1.3.1 on a Journeyman X50.

I’ve been beating my head against the wall all week running tests that keep failing, because every time my job pauses and says, ‘time for a tool change’ and then I attempt to probe Z again, it just spins and doesn’t complete.

So I have to run EVERY tool as a separate job?? there’s no fix and/or update for this problem? the probe won’t work to change the tool, re-probe Z and then keep rolling??

[Aiph5u (Aiph5u (not affiliated with Onefinity))]

Hey B2Bass,

a g-code file with multiple tool changes works fine with the Buildbotics and the buildbotics-derived Onefinity controller. It’s just that you have to put a useful tool-change routine into the ‘tool-change’ field on the SETTINGS page (there is no useful routine in this field on the stock Onefinity). You can use my Aiph5u’s ‘tool-change’ routine.

@Aiph5u

Also do you have tool changes in your program? If so, you got to be aware the the ‘tool-change’ routine on the stock firmwares was always unusable. You can use my ‘tool-change’ routine that works.

@Aiph5u

if you want to use a g-code toolpath file with multiple tools with the buildbotics-derived Onefinity Controller, please be aware that the ‘tool-change’ routine that is delivered with the Onefinity in the SETTINGS page does not work. You can take the ‘tool-change’ routine that I provide here instead.

Further reading

• What will Aiph5u’s tool change routine do?

@Aiph5u

Regarding the other way, i.e. splitting the g-code file to one file per tool, of course there are advantages and disadvantages:

@WaywardWoodworker

@Machinist

@Aiph5u

@Mike01

can you think of any pros/cons of running a single gcode file with multiple manual tool changes vs running them as separate files, one for each tool change?

usually you would say, if your program is well-tested and mature for production, one g-code program with all the tools saves time.

Many forum members here say the advantages of one g-code program per tool is that you can change the program for a certain tool easier or re-run a pass easier. They put the name of the tool into the file name, and the pass that it is for.

Yes to this. I used to be in the camp where I wanted to keep all tools in the same program. But because I don’t have an ATC and am not running production on anything, I find it more convenient and flexible to actually program for separate tools. So even though I can program for tool changes, I prefer not to.

I was in the “one program per tool” camp until I implemented the tool setter then I found it was easier to and more accurate put them all in one program and use the tool change to measure T1 Z height, switch to tool 2, then measure T2 Z height and automatically reset the Z offset accordingly. This also works well if your Z axis zero point no longer exists after running the first tool path.

@Aiph5u

Of course the Onefinity CNC machine, whose Controller is derived from the Buildbotics.com Controller, can do g-code programs with multiple tools.

It’s just that Onefinity, unlike Buildbotics, don’t want to bother with this and simply recommends splitting the programs into individual programs.

But the Buildbotics and the Onefinity Controller let the user control the behaviour of the machine in a field called ‘tool-change’ in the SETTINGS page. The problem is, Onefinity delivers the machine with g-code content in this field that is unusable, which leads to a situation where users are stuck in the middle of a program with no possibility to change the bit.

Buildbotics, on the other hand, describe thoroughly how you use this ‘tool-change’ field here, to have the machine behave the way you’d like it when the machine encounters a ‘tool-change’ event.