Twin Spindle / Twin Turret turning center

I don't think that a preprocessor would know that you wanted that.
My suggestion would be to use a separate utility to convert two G-code files to a single nested G-code file.

This thread here has a script that does something similar (but different) for a foam cutter.

forum.linuxcnc.org/38-general-linuxcnc-q...r-me?start=10#120524

I would suggest that for one-off parts there is not much to be gained from running the code concurrently rather than consecutively. When there is enough time to be gained it will be worth the effort of running the files through a conversion script.

Hello guys,

i am working on retrofit emco cnc lathe emcoturn 425
it's lathe with two main spindles, two turrets and two subspindles
old controller is sinumerik, which have function axis doubling - machine cutting two identical parts with single code
I am looking for solution where i have XZ UW axis in linuxcnc and program is only XZ
Is possible to join X axis with U and Z axis with W?
My intention is if i program X100, then X got to 100 and U go also to 100 but with different tool correction

Another problem is with subspindle, i like switch machine to subspindle by user M command, then programming
other side of workpiece, but i need reverse Z axis as is in sinumerik controller

I think that axis mirroring with cutter comp would be difficult (by which I mean that it won't work within the current LinuxCNC architecture)
The XZUW positions are determined by the G-code, then the offsets are applied, and then it goes to the kinematics module.
So whilst there are many ways to combine joints inside the kinematics (as is done for gantries) there isn't a way to have the axis offsets apply (also as these are _axis_ offsets not joint offsets)
There is also no way to program an XY arc and a UW arc to occur simultaneously. (This is a G-code limitation)

So, it is easy to make the UW axes move in a exact mirror of the XZ axes (whether by using HAL wiring or the kinematics modules.) But it isn't easy to apply offsets.

However, if you are willing to consider _only_ having length compensation for UW (not diameter) then it might be possible to link halui .tool-length.u/w in to a modified kinematics module to achieve approximately the required effect. A custom kinematics would also allow you to move the origin from one spindle to the other.

The problem with switching kinematics on the fly like this is that it tends to cause an immediate following-error. This needs to be handled, and there is some work ongoing in this direction with Switchkins.

If the counter-spindle moves in Z, does the coorodinate system move with it?

Interesting topic

Even though I think, that your machine type is beyond hobby scope, its an interesting challenge.
We have several multi-spindle multi-turret machines at work (like Index, Mori, Gildemeister, ...) and they all have in common, that they use dual-controllers and UI with dual instances in one app ...

But that controllers are not spindle centric, but turret centric. That means, each turret has one controller (and may be a separate tool changer, robotics, ...) and all controllers share the main-spindles.

To support such kind of machines, several changes have to be applied to linuxcnc:

• Tools need an information, which spindle they can work on. There are tools for primary spindle, tools for secondary spindle and tools for both spindles. Some tools are static, others are rotary tools (so there is a third spindle).
• controller needs to know the type of "turret" - is it a turret with fixed number of static and/or rotary tools, or is it a multiaxis-milling head with tool-changer access
• If you look closer at the hardware, you'll see, that the different turrets don't share linear rails or axis motors. So using separate hardware controllers is an obvious choice.
• each linuxcnc-instance has all axis, so double X, Y, Z ...
  The controllers at work call the axis X1, X2, Y1, Y2, ...
• you need synchronization points or the possibility to synchronize all turrets with some kind of collision detection
• To enable two instances of linuxcnc a lot of internals have to change. Not only the nml-section. Currently most work is performed by the interpreter. Not only on interpreting GCode, taskmanager heavily uses interpreter.
  I don't believe, that current codebase supports two taskmanagers running at the same time.

Yes, two instances of linuxcnc means, that you need two GCode files running at the same time.

So if you don't want to run your machine by quick hack, you should think in years, not weeks.

Counter-spindle is controlled by pneumatics, it has hard stop in rear position, the distance between main and counter spindle is constant.
In original controller coordinate system move from main spindle to counter spindle. (move with constant distance in Z and reverse Z direction.

I believe that if you want to have the two spindles and turrets to have the ability to run completely separate G-code files at the same time, the best solution at this time would be to simply set them up as two separate machines with two separate Linuxcnc PCs. Then add interconnects between the two for synchronizing moves where they must work together and communicating each other's position. Crash prevention will probably be your trickiest part to engineer, but that would not have been any easier with a single control arrangement.