Can Linux CNC control twin turrets?

It is possible to run more than one instance of the "carousel" component, to control different tool turrets for changing the tools.
If you are content to run one tool slide as XZ and the other as UW then LinuxCNC can also move both tools.

What that scheme doesn't allow you to do is to start a long turning pass in W while at the same time threading in Z (for example). G-code lines all run in strict sequence and all axes arrive at the end point at the same time.

For special purposes I can imagine running some axes outside of the interpreter using simple_tp but that is not really an answer for general machining.


Using multiple instances of "carousel" would be simplified if the component could be configured to ignore tool numbers outside its range. This is a simple fix. I think that an extra pin "base number" would do all that is needed. Then the component would quietly ignore any input number < base or > base + pockets. (rather than rely on hal wiring to achieve the same thing)

nkp wrote:

My idea: use only 2 axes(XZ), and switch depending on the tool number.
Do you think it will work?

I think that would be fiddly to make work properly, and would also be less flexible and capable.

An intermediate solution (which would allow the use of conventional CAM tools) would be a G-code filter that converts from XZ code to XZ + UW code depending on tool number selected. (This would get complicated, (or impossible) if the G-code was to call the same subroutine with different tool numbers, but given that CAM generated code is typically completely linear this could be accepted as a limitation)

You can activate U and W axis by changing the ini file:
[TRAJ]
COORDINATES = X Z U W

and

[KINS]
KINEMATICS = trivkins coordinates=XZUW

this will also enable you to define tool offsets in U and W in the tool table.

[edit]
you will then of course also have to define the axis/joints for U/W in the lower part of the ini and the hal to actually use them

The AXIS GUI can handle XYUV foam cutters but I don't think anything does a preview for XZUW.
I think most of the GUIs will allow you to jog and run such G-code though.

I don't think extrajoints is an answer for any axes that you want to control from G-code.

I don't think anything does a preview for XZUW.

Well it kind of does but not in the way you want it to.
In your INI under the [DISPLAY] section you can define how the preview for the different axis is handled. "GEOMETRY = xyz" will only show moves in xyz. You can change that to, for example, "GEOMETRY = xzuw" then x,z,u and w moves will be displayed BUT u,v,w are defined as incremental moves in x,y,z. So a move of say G0 U10 will add a move of +10 in X direction in the display.
So in that sense you will not get a display of the tool path of your second turret but the moves in u and w will be graphically added to the tool path in x and z.

Hm, I tried it in master with the gmoccapy lathe sim config.
It showed the U and W axis in the DRO.

It seems to me that this is not enough for gmoccapy.

What makes you say that?
What do you see after the changes in the ini?