I’m getting tired or maybe just lazy about swapping bits on the router and maintain the same height to get the right carve. I asked about how to pocket a carve in estlcam and it is working beautifully when the bit swap is done well. So I’ve stopped swapping bits and now I swap routers and the next level up is to add a second core and get the machine to use the other core with both routers and activate the one with the correct cutter.
I’m running marlin on an SKR pro 1.2. Has someone already done something like this? The hope is that I can add the 6th 2209 driver, connect a second z motor and measure the x and y offset to the second core and instead of swapping bits it should be like swapping extruders on a 3d printer that is co-located but with an x and y offset value stored somewhere.
questions:
Should it use a sub coordinate system to incorporate an offset or do I need to rewrite marlin to do this with a second z axis?
Is there any concern with stepper power to drive 2 cores? (cutting foam as fast as possible)
Printers can get away with two extruders on a single carriage that are physically aligned in Z. Each nozzle will clear the print layer laid down by the other nozzle.
For two routers that plunge below the workpiece top, you don’t have the luxury of ignoring the other tool, so I am thinking you will need independent Z. Maybe that is what you meant (and you had said another Z driver, not running both Z motors in series).
I think independent Z is very interesting. It would also apply to all the other machines with a fixed-height gantry, so it’s got a lot of potential broadly, even if it’s pretty unusual for MPCNC.
I don’t know of a built-in feature in Marlin (or grbl) that solves this.
In theory you could define the vertical axis as X, and the horizontal axes in the plane of the table as Y and Z, and then use dual-x-carriage in the firmware. This approach would have a ton of other problems and I wouldn’t recommend it, but you could use existing features in the firmware.
Another potential approach, which might work, is to use the E axis as a second Z, and have post-processing script that detects tool changes and replaces E for Z in the gcode. There is no homing for E that I am aware of.
Or for that matter, maybe a rotary axis A could be used for second Z instead of E. The rotary axes do have options for homing. You would need to do the same search-and-replace A for Z. Maybe the A-for-Z swap-on-toolchange could even be implemented in Marlin and it would not be a major invasive effort. If you use all three rotary axes you could have four tools in all four quadrants.
Thanks @jamiek for thinking through this with me. I was not meaning to drive both Z motors in tandem like putting a second motor on a z gantry for a 3d printer. The two z axes would function mutually exclusive from the other and the active core would be determined by the tool change command. I envision Z1 would run a pocket cut for a carve area, then “park” at clearance height when the tool change command comes through and then Z2 would run to carve with a v bit, for example, and the job would finish. With now a second core printed, I’m interested to learn how to do this. The extreme would be to try to do this with 4 cores, but to me, it isn’t really an option without modifying the core from since I can’t really mount one upside-down with the X and Y pipe heights being set already.
The rotary axis seems like a possible path to use the Z2 axis on the extruder driver channel. I’ll look into it more.
I did some tests a few months ago to answer the question, “to use A and B rotary axes, is it just a matter of enabling it in the configuration?” and the answer was yes, configuration is enough. I don’t have 4th/5th axis mechanism but I got motors to move.
There are several places you have to enable, and you have to specify steps-per-mm and feedrates and max feedrates, etc. for the extra axes but it’s all in the Configuration.h and Configuration_adv.h where you just turn it on and it works. No extra hacking of code is necessary. And as long as you have EXTUDERS 0 it should just assign it to the next available stepper driver.
