I see what you are saying, tool changes and Z setting take time. I would save a ton of time. I don’t think that can be downplayed.
Doing multiple one offs in a fixture illustrates the benefits very well. Heck two fixtures making the same object with a tool change means you unload and load one while the other is cutting. That really increases production. You can load a full sheet in there and have it do all of op one, tool change, then all of op two. Tool change back and do it again. But for me having it cutting one while I swap in a new blank is a very enticing proposition.
I feel like you get the benefit of two machines in the space of one. While not needing to change tools either.
I can’t think of any multiple back and forth tool changes, though…Spend too much time designing for minimal tool changes.
Bit out there, but… Could 2 Cores with attachments/mounts orchestrate picking-up/dragging/manipulating/transforming/conveyor-belting material in a way that’s not possible with 1 Core?
If you were making 100 coasters, you could have two jigs set up (or 4). The machine would be doing the two tool operation on jig 1 while you were setting up/tearing down jig 2.
If the job is 2 hours long. A change in the middle for 2 mins is not that bad. But a 2 min tool change every 2 mins is where this machine would really make an impact.
But in my shop, where I would appreciate it is that I would be doing things like chamfers way more often. If I just always had the extra router mounted, it sould be worth it to asd the extra step, since it would be nearly zero effort.
It’s looking like the tool change gcode within EstlCam (Setup → Texts → Tool Change) can work, with a trick.
To switch from Tool 0 to Tool 1:
Stop Tool 0 spindle (M42)
Move Tool 0 to home position (X=0 in machine coordinates)
Switch tools using T1 command
Move up a bit, in case tool length difference reduces clearance height after switching
Start Tool 1 spindle (M42)
And a similar, but different sequence is necessary to switch from Tool 1 to Tool 0.
Since the routine to switch T0 → T1 is different from T1 → T0, it doesn’t neatly fit within the tool change gcode script. There might be a way to use the auto-park feature in Marlin, but even then the M05/M03 does not handle tool-dependent pins for the SSR, so the gcode has to be customized for each tool.
The trick is to enable macros M810, M811, … M819. I can define a sequence of steps for switching Tool 0 → Tool 1 and assign it to the macro M811. Likewise to switch from Tool 1 to Tool 0 I have defined a macro M810. Then to switch to tool <n> (0 or 1) I can issue M81<n> within the tool change code, which then expands to M810 or M811.
Since macros are not persistent I define them each time in the startup code.
Also I found a workaround for the weirdness around workspaces and tool switching, but that will get its own thread.
I have yet to test all the pieces working together, including the macros, but so far it is looking like it should all work.
For the video above I generated code with EstlCam and then by hand I inserted gcode at the start and the end and at the tool change. It works okay but it’s error prone if you have to do it every time, and it doesn’t scale.
There is just no way any other forums are as cool as this one. mind blowing. You had an issue, solved it, demoed it, and issued a pull request to solve it for any that follow.
From the build, discussion and product page, looks like they expect production increase will be compelling to folks/businesses:
Z axis are independent, but looks like they’re on a single X-axis lead screw. So fixed X-axis spacing. Can’t tell if video/photos are real/edited/rendered, so maybe final shipped design in ~Jan will be different and have more range of motion for each tool. Nice to see though.
Jamie’s LR3 Idex (currently) may not have independent Z axis for each tool core, (for example there’s no solenoid/binary engagement linked to tool on/off signal…), not a big deal though, since Jamie’s IDEX can orchestrate moving the tools off to the side.
Jamie’s LR3 Idex has the advantage of independent X axis for each tool. Giving it greater x-axis overlap, and different capabilities/options…
Personally, I prefer @jamiek’s design, and pricing
With a V-bit for carving and a straight endmill for carving the perimeter, these can be batched out quickly with the right fixture. I agree that a short job requiring two tools will best highlight the benefit of not having to manually change tools.
I’m thinking I’ll edit this into a more polished video to better explain/highlight the benefit of having two routers, for a general public audience for whom it might not be so obvious.
Hack A Day? Good idea!