Tool change Z probing problem

[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.