Twin Spindle / Twin Turret turning center
So to take the simple case of a facing cut in X running at the same time as _two_ facing cuts in U.
G0 X20 U10
G1 X0 U0
Would actually be a cut simultaneously in X and U with U half the speed of X, and then a cut in U with X stationary.
What you would need to do (possibly in an input filter, is break the X move at the Y move reversal point, and possibly do everything in inverse-time mode too ( G93 )
G0 X20 U10
G93 F10 X10 U0
G93 F100 X9 U10
G93 F9 X0 U0
Would, sort-of, give the same result as truly independent motion of X and U.
Mutli-spindle S commands are controlled using the $ character (this was deliberately chosen to make it easy to re-map to any of the _other_ ways of operating multiple spindles without conflicting with any of them)
that G-Code work would be done by the post-processor.
The thing is, when I say the intention of working with it as two separate lathes I literally mean to be able two run 2 different
G-code programs on the same instance of LinuxCNC, each one controlling half of the machine, just like they were 2, with the exception that all the electronics are common, as well as the realtime module of LinuxCNC has to be.
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.
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.
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
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?
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.
So if you don't want to run your machine by quick hack, you should think in years, not weeks.
In original controller coordinate system move from main spindle to counter spindle. (move with constant distance in Z and reverse Z direction.
That's only true on a very superficial view.
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.
Suppose you setup linuxcnc for one turret and one spindle. As long as the tools work with the "own" spindle, there's no problem.
The problem arises, when you want to use tools from on turret on the opposed spindle. As long as that spindle runs in lathe mode, no problem. But when you want coordinated moves with spindle as indexed C-axis, you need realtime synchronization between 2 uncoordinated PCs.
Can't imagine, that a reliable synchronization from one pc to the other would be fast enuf for coordinated moves.