Is the solution they offered my best one?

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

Hey David,

what is the content of the ‘tool-change’ field on your SETTINGS page? You know that in stock configuration, as of up to firmware 1.2.1, the content of Onefinity Controller ‘tool-change’ field is unusable? Did you already update it to my most recent tool-change routine?

@Arzt

They told me not to write a tool path with more than one cutter(!) They said I should use a single toolpath for each cutter. That would be a nuisance!

You might be interested on more info on manual tool change on buildbotics-based controllers:

@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, as described here .

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

So what you have to do is just follow an easy instruction for this here.

@Aiph5u

What will it do?

In general, when you followed the instructions above, when your g-code program is started and a bit change appears in the program, the milling motor is halted and will be driven to the home position, which means to front left corner and Z is lifted, and a popup appears (if present in g-code, with the tool number) and tells you to insert the bit, then after your confirmation it tells you to attach and put the touch probe underneath the bit, after confirmation probes tool length (Z probing) automatically, and after one more confirmation resumes your g-code program at the right position by powering up the milling motor (if supported by your motor, to the speed specified in your g-code program).

A difference in wanted behaviour is whether you have set your workpiece origin to workpiece top left corner, or to a lower workpiece corner. In the first case you put your touch probe on the top left corner of your workpiece, in the latter case you will be told to put the probe on the machine bed when spindle is at home position. This behaviour is altered by enabling or disabling one single command in the instructions above.

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.

@Arzt

I now recall that I didn’t re-home the machine at the start of the work today. So if that’s the issue, then it’s all on me. But if that isn’t the issue, then I don’t understand the cause or Support’s recommendation.

Except if you are sure that the motors are X in left most, Y in frontmost and Z in topmost position on powerup, it is always necessary to home the machine once after powerup. Only in case where you interrupted the work on a workpiece and re-powered the machine on, you could find that using stall homing is not reliable enough to continue on the same workpiece, you may have a more or less small deviation of the starting position, which can be visible on the work. In those cases, the solution is either to always probe on the workpiece with the 3-axis touch probe, or to clamp a reference block or jig on the machine bed (possibly away from your work) that you don’t move during the project and to use the 3-axis touch probe on this block or jig to home the machine.

Links

Aiph5u’s ‘tool-change’ routine (V2023-03-14)