Like many new forums, the excitement and

Jim ,
I have ordered the 80 mm mount but am on the fence for what spindle to purchase what do you have for a 80 mm spindle and are you happy with it

I thought vcarve pro created guide that combined multiple tool paths into one file,.

It does but 1F says to split them by tool. I can’t run mine yet because I’m waiting on my QCW (now officially late) and extension cables for the motors so they’ll reach through the table I’ve built. I can live without the QCW but I would need to disassemble my table to move the controller back close. I didn’t think it would take two or three weeks to get some in-stock wires. I’ll grab the connectors and wire from Mouser later this week if 1F doesn’t ship. I will test the VCarve combined toolpath file but understand that’s not supported by 1F per their posts here.

Hmmmm…

Is it a controller issue? That’s certainly a efficiency stopper. I have lots of saved toolpaths that I’ve saved over the years that have combined tool paths. I calculate each one individually but then output them to a single file. Since it’s Gcode I’m not sure why that would be a problem for any controller that ran gcode.

I am using carveco maker+ but have used combined tool paths with the 1f. It just pauses at every toolpath change. As long as I am using the same tool I just click continue and the next tool path runs.

I have owned my machine for almost a year now and I think it is one of the best in it’s class. There are things that could be improved on for sure, but bang for buck I do not think you could get a better machine for the cost.
If I had to say the weakest parts of the machine are the controller and the router. The controller has some limiting functionality not supporting true arcs and macros and could be improved or upgraded. The router needs a spindle upgrade that is supported by 1F. Both can be addressed by 3rd party solutions if those things are an issue, but out of the box I have had more than enough use as it is and it has been a great machine.

Hey J, hey all,

you can define the machine’s behaviour at every tool change event (M6) in the General Configuration Tab of the Onefinity Controller -

G code insertion at Tool Change :

Insertions of sequences of ‘G’ and/or ‘M’ codes are possible at the beginning, at the end, and during tool changes. It is often helpful to add comments to the commands. Comments are enclosed in parentheses. Some commands cause program execution to pause and wait for the user to take action before resuming execution. When the characters ‘MSG,’ are entered at the beginning of the comment, the remainder of the comment is presented to the user in an “action dialog”. This helps instruct the user on what action to take before resuming execution.

The “tool-change” entry box contains commands that are run every time an M6 (tool change) command is encountered. By default, the “tool-change” entry box contains the following commands:

(Runs on M6, tool change)
M0 M6 (MSG, Change Tool)

These commands simply pause execution and prompt the user to change the tool.

The following example provides a set of commands that can be used to change the tool and then set the height of the z-axis after the tool change. This example assumes the use of a 0.75” (19.05mm) touch plate like the one shown here.
touch_probe

(Runs on M6, tool change)
M70
G21
G0Z100
M0 (MSG, Change tool and attach probe)
F100
G91
G38.2 Z-100
G92 Z19.05
G0 Z25
M0 (MSG, Remove probe)
M72

M70 tells the controller to save its current state (e.g. feed rate, distance mode, and units) so it can be recovered after the sequence is completed.

G21 tells the controller to operate in Metric units.

G0 Z100 raises the tool to 100mm so the tool can be replaced.

M0 (MSG, Change tool and attach z-probe) - The comment starts with ‘MSG,’ so the text “Change tool and attach z-probe” is presented to the user in the action dialog.

F100 says that the feed rate will be 100 mm/minute. This feed rate should be slow to prevent jamming the bit into the surface of the probe. Ideally, the search will stop at the instant that the bit touches the probe.

G91 puts the machine in “incremental distance mode” so it will probe downward by 100mm or until the probe is found in the next command.

G38.2 Z-100 tells the machine to move towards the probe and stop when the probe surface is found. If the search reaches Z = -100 without finding the probe surface, the search will stop and the probing command fails.

G92 Z19.05 sets the z axis to 19.05mm, which is the height of the probe base being used in this example.

G0 Z25 tells the machine to move up to Z = 25 so the probe can easily be removed.

M0 (MSG, Remove probe) reminds the user to remove the probe and waits for the user to click “Continue” to resume execution of the GCode program.

M72 restores the original state (e.g. feed rate, distance mode, and units) that existed at the beginning of the tool change procedure.

Source: Buildbotics Controller Manual (Note: Onefinity Controller is a fork of buildbotics.com Controller.)

:triangular_flag_on_post:

NOTE:

Unlike the touch plate shown above, the Onefinity (Triquetra) Touch Probe is 15.4 mm high instead, therefore you need to replace “Z19.05” by “Z15.4” in the example above.)

Razi Ullah’s ‘tool change’ script

Tags: tool change, tool changer, tool changers, tool changing, G codes, M codes, gcode

8 Likes

It’s not an issue when using the same tool. The guidance from 1F is to separate the project by tool. So if the project requires say 3 bits (V-bit, 1/4" upcut endmill & 1/8" ball nose endmill) you create 3 different G-Code files and run them individually.

I’m used to having them all in one G-Code file where the controller stops and allows for the bit change and rezeroing of the X-axis.

I believe I read a post where they said it was a control application issue that was targeted for fixing.

I saw the last post you referenced but am hesitant to change basic behavior so I don’t have to worry about impact on controller updates. It’s nice I can do it, I just shouldn’t have to. Many people in fact would muck it up and cause issues for themselves and then 1F Support as a result. It should be fixed in the controller.

Hey Aiph5u thanks for that tip! I have already made other changes in the software to fix the inch/mm issue so this will fix another minor annoyance I had. :grinning_face_with_smiling_eyes:

Hey Jim,

I don’t understand you. You can make the machine to allow you to change the tool by driving the milling motor to the home position, raising Z high enough, issuing a message asking you to change the tool, then offering you to Z probe the new tool length, and then continue with the execution of your gcode program, which is something everybody would expect from any CNC machine, but you fear it?

What do you expect the manufacturer to fix? To enable you to use the joystick during tool change?

Also, if you have your own custom tool change instructions (which is nothing unusual on the part of a CNC operator), why shouldn’t you keep using them after an update?

It is a free-text input field! It is for the tool change behaviour! It is made for this!

I use a naming convention with my files that includes the bit size and type as well as the part origin location. Since I set my Z0 to the top of the stock for Vcarves or pockets and to the bottom of the stock for profile cuts it makes more sense for me to just have the files separate anyway. Fusion further solidifies this decision for me by using different setups for different origin locations thereby disallowing the combination of toolpaths even with the same tool.

Hey Jim,

Believing is in the church :slight_smile: Can you find that post so that one can understand what you mean that you expect the manufacturer to fix?

Because I want to jog the router not go back to a fixed position. Going to project home is okay as long as that’s an unmilled corner. But if I home in the center of the material I will potentially have milled away material so I can’t set Z off that position. I need to move the router to a position that still has original material height left to zero off of.

If 1F comes up with that as their fix then I can get rid of my customization. But I am now responsible for doing that. Easy enough for this example but what if I decide to change my workflow and always use the lower left for my project home and I’m not milling that corner so I can use my modification. But they change the default to go somewhere the controller determines has not yet been milled and only allows Z axis movement. Now I still want my mod because it works in my workflow. But can I keep it or is their change going to execute first and then my customization or vice versa? Or do they kill my customization altogether?

I have found that customizing core functionality of most systems to provide what should be a general use case when a reasonable workaround exists, often turns out badly and requires more customization that cascades over time making a hash out of things. Especially when the producer has acknowledged the issue and stated they’re working on a solution.

So it’s not that I fear making the change, it’s that I don’t want to dig a hole that I then need to climb out of.

Hey Jim,

I understand, you really wait for Onefinity or Buildbotics implement that you can move around all axes with the joystick during a tool change (M6) in a running gcode program, and then you want to continue the running program at a different project’s coordinates. But this would require a gcode program that takes this into account.

But here you assume that tool length probing always has to happen on the workpiece.

It does for me. I have years of designs I’ve created using the top of the workpiece as the 0 point (which I’ve seen is more the general case than using the wasteboard as the 0). I think I’ve zeroed off the table only a couple of times in the past 7 years.

1 Like

Hey Jim,

you really wait for Onefinity or Buildbotics implement that you can move around all axes with the joystick during a tool change (M6) in a running gcode program, and then you want to continue the running program with a different project’s home. But this would require a gcode program that takes this into account. Is that realistic?

No. I want it to cache my X, Y and then allow me to jog. I reset my Z and then want to have it return to the X/Y before resuming. All within my multi-tool GCode file (not separate projects or using another project’s home). It is certainly doable because it is supported by other machine’s using hardware (e.g. Shapeoko bitsetter) or software (e.g. Shopbot.

1 Like

Hey Jim,

okay, you want that during a tool change (M6) event you can move around with the joystick, probe Z, and then resume operation of running the program with new tool length. So if I understand right, the problem is that when the Onefinity Controller receives a tool change command (M6), it is stuck at the position and does nothing (especially not raising Z in order to allow removing the bit) because by default, there is nothing inserted into the “tool change” field of General Configuration Tab except to let a message pop up:

(Runs on M6, tool change)
M0 M6 (MSG, Change Tool)

…and that in this state, it does not accept joystick commands. And that’s what you want Onefinity or Buildbotics to fix. Did I get it now?

(Note that Onefinity Controller would execute an appropriate tool change routine if there was one inserted here instead)

But to remember the original thread creator’s question, it is clear that when using an appropriate tool change routine as shown above in the “tool change” field of General Configuration Tab, which would manage tool change and Z probing, the Onefinity machine is very well able to run jobs with multiple bits in a single file. I don’t think it’s right to express it in such a way that it leads one to believe that the Onefinity CNC Controller can’t do that.

Hey Bud,

Nor do I :slight_smile:. With the restriction that you have to have Z zero at a position that you can Z-probe after tool change.

Hey Jim,

The reason why one would put zero on the workpiece top is that you don’t have to worry about your workpiece thickness then. Hobbyist machines usually don’t have probes for sensing workpiece dimensions separately, so for hobbyists, it is often advantageous to set zero at workpiece top. But as we see here, zeroing somewhere that is independent from the workpiece allows Z probing at home position (= at tool change position) and facilitates tool change within a program.

Also you mentioned that with zero at workpiece top you can’t probe Z on a position where you have already milled the material away. But imagine if you milled the top part of your workpiece away entirely and want to proceed with a finishing run? I have seen many workpieces to which that would apply. Having zero at a position that is independent from workpiece is the solution then.

1 Like