Twin Spindle / Twin Turret turning center

Hey guys,

So I have a quite complicated setup I would like to get going with LinuxCNC which is a dual-spindle, dual-tool-turret turning center Wickman 76-250 .
I recently read on the change-log that the 2.8 version will have support for multiple spindles. My question is, as of today, is it possible to make this turning center work as 2 separate lathes and also have simultaneous functionalities, like exchanging stocks between the 2 spindles, which the FANUC controllers do, or having the second spindle to synchronize with the first to work as a tailstock and probably use both tool-turrets simultaneously to mill the same stock.

It would work something like this .

Thanks in advance,
Simão

hi
very nice project
a double side one make flow mashine industrial standard

you can free configure your 2 spindles no problem
also you will have the option of 9 ISO axis XYZ ABCUVW 6 liniar and 3 rot in full sync

so it is a "can be done"
but the hint will be that there is only one Hint
the Fanuc got a Teatch in Module Based Programmer that gets XZ and X1Z1
that is not supported so the Postprocessor if you use one is to be modified
the Direction of moving is no problem you can coose joint direction on your own like
There will be only grafics for one lathe
BUT there is VISMACH where you can setup your mashine as 3D view and direct the Joints to the blocks

so from electronics and mashine controll there will be a green light

So if I understand correctly, it CAN be done as long as all operations are programmed in a single G-Code program, correct?

If using, say, XZ for one turret and UW for the second turret (I don’t know how the second spindle would be
referenced in terms of “Sx” directives...) it would be up to the CAM/Post-processor to control them as separate
machines, right?

I still haven’t had the opportunity to play around with VISMACH, but is it possible to embed a VISMACH tab into
GMOCCAPY? Maybe even replace the gremlin viewer with a VISMACH one?

Thanks,
Simão A.

So having independent XZ/UW movement on each 'side' is the big problem.
Combined XYUW movements are all synced in linuxcnc.

A possible way around this is to run two linuxcnc, one for each side.
Then syncing the two sides becomes the problem.
Also in the linuxcnc project, two instances of linuxcnc on one computer is not supported, so you would need to use two computers.
(Machinekit may have this capability - I've seen video of two instances on one computer -not sure if it got in the project)

Assuming you want full capability, this would be an involved project that would require pushing linuxcnc beyond what it currently does.

If you could live with XZ and UW not being completely independent, then it's coding the part transfer and syncing the spindles that is new and that seems not too bad.

All this is my off-the-cuff opinion. Others may have ideas how to work around these problems.

Chris M

Using two computers is a no go... I suppose running two instances of linuxcnc would not be possible
because I would use only one setup of mesa cards and not two sets (two FPGA cards), which I believe even if two
instances of linuxcnc could be launched, they would need to share the same communication hardware ...

Correct me if I'm mistaken and this is just an idea that came to mind but the biggest limitation
of having two parallel linuxcnc instances is that HAL doesn't allow multiple instances (which makes sense for me),
but HAL doesn't care about what is controlling it because it only creates logical connections so if there would
be a way of running parallel EMCMOT instances, each one of them with an associated RS-274 Interpreter, they could
share the same HAL instance and work completely independent, IF HAL is the one controlling the communications
(with the mesa boards). If this would be possible to do I think syncing the two EMCMOT's would be "trivial" with virtual I/O in HAL.

You are right. in linuxcnc only one instance of realtime is available.
I agree that two motion controllers is what you need for your project.
getting two motion controllers to run at once i think will be challenging but is doable - as I said it's been done before - but the guy that did it was a linuxcnc internals wizard.
It's unfortunate that his work didn't continue in linuxcnc and worse I can't find repos of his work to look at - he also had the core work for jog-while-paused figured out.

How deep are you willing to go?

Chris M

Well I think this is a type of "feature" that would give linuxcnc a boost in terms of functionality and open some
pretty interesting doors for future enhancements.

It's a real shame when someone involved that deep in the project disconnects like that.

I'm still a newbie in terms of understanding the internals of linuxcnc, but I'm a quick-learning and self-taught type of guy.
If I actually take some time to read through the docs folder, I think I could start to get involved in the development of the internals.
From what I understand, everything that is "kernelspace" or performance critical components is written mainly in C, which
is actually the programming language I have more experience with.

So I guess that if there's some general interest and consensus about this, maybe I could give it a shot on getting
it to work.

Might be interesting to you ( a bit old but mostly true - linuxcnc is refereed as 'legacy' code)


Chris M

Well there could be a way but its not for the faint hearted C programmer!

Linuxcnc has two core parts that are loaded via the ini file, task and iocontrol
Which are in the folders /src/emc/task and /src/emc/iotask
See Git here: github.com/LinuxCNC/linuxcnc/tree/master/src/emc

So task is the motion part of Linuxcnc and it sends messages back to iocontrol which turns up as halui in hal

At the moment Linuxcnc only has one task module called milltask but it has been designed to be modular. Andy has suggested there should be a plasmatask module so perhaps there could also be a twinturntask module as well.

So if you want to experiment with this, you can copy the milltask folder to a new folder, tweak the submakefile and update the main make file to include the new folder. I actually played with this and also made a new iocontrol file in the iotask folder and tweaked the submake file there.

So in about 30 minutes I had recompiled LInuxcnc with a new plasmatask and plasmaio modules and updated my ini file and everything ran as normal.

So good luck on your journey!

he just needs to map the gcode letter to the joint
he can use XZ UW for the main
and if his postprocessor i think he dient need one as he told in first post

so and if he likes to view second side g-code he can in qtvcp direct the graphics window main XZ
and a second one UV view with compared X1 Z1 command that shoudt show his need with no extra task

the mashine g-code is only a letter change
this mashine type is most one side and the other side on its own this might be more a problem
as if one side needs z 100 and the other only x/U 5mm
this move will be sync
even more problem on different feeds