motion channels for robotic atc library

So i had a craaazy idea for a little robot tool library.
Wondering how you would implement it in linuxcnc.

So we have our XYZA on our cnc. lets reserve B just in case we ever need a 5th.

That leaves 4 more axes available.
Our little tool robot will have an x2 y2 z2, and a x3 (fixed motion, likely air) and C do pivoting the gripper - again fixed motion.

Basically it is a cnc of its own, and needs to operate while the main machine is cutting so it can sort and stage tools. This is different from using C for an atc platter that is actually coordinated with the main machine.

How could we do this?can we decouple these new axes from the main motion as a "channel" ?



 

LinuxCNC has a single realtime motion module (motmod).
All coordinated motion and joint updates go through that one trajectory planner and queue.
Even if you configure additional axes (U/V/W etc.), they still belong to the same motion instance.
There is no concept of a second independent motion channel inside one LinuxCNC process.

Industrial controllers sometimes give the impression that this should be possible because they support true multi-channel motion. For example, platforms like Omron Sysmac can run multiple independent motion groups or program contexts in parallel within the same controller. That capability is built directly into the motion kernel.

LinuxCNC, however, is architected around a single motion instance per process.

If you need the tool robot to move while the main machine is cutting, the practical solutions are:

• Run a second LinuxCNC instance / second controller for the tool robot and handshake via IO/fieldbus.

• Use an external PLC/MCU/drive sequencer for the robot and trigger it from LinuxCNC via M-codes or IO.

A “HAL-only second planner” is technically possible, but then you own all the safety, limits, interlocks and coordination logic yourself — and it tends to become fragile fast.

Thanks, that's basically what I thought

I've been thinking about this for some time.

Obviously the easiest way is probably going to be to run a second LinuxCNC pc. (Assuming I'm doing everything in LinuxCNC.)

Then I was thinking about the possibility of running a custom multi-instance capable tp component consisting of something like:
GUI <-hal-> [tp.0, tp.1, tp.2] <-hal-> [trivkins.0, scarakins.0, scarakins.1] <-hal-> I/O (mesa, lcec, etc)

Definately re-inventing most of the wheel. Can we make it any harder?

One other possibility I considered, if it is possible to run just one at a time?
Could it then be done pausing the one and temporarily switching kinematics to run the other set of axis... say, toolchanger?

Because the OP is on the Ethercat bandwagon (as are the commenters),
I have wondered about a seperate Ethercat component that does not consume an axis. I was mostly thinking about spindles but it might be able to morph into something with position control.


EDIT Running it on a seperate thread may give you enough independence...

mmm. interesting

I may wind up making it self contained, as not all my customers will use linuxcnc.

it could run linuxcnc self contained. or we could make it much more simplistic on an arduino.

The way the system is now its down to 2 coordinated linear axes, one fixes linear axis (most likely to be an air cylinder) and one for rotating, which might be best served with a servo axis. not sure yet.

thanks

Marcos wrote:

A “HAL-only second planner” is technically possible, but then you own all the safety, limits, interlocks and coordination logic yourself — and it tends to become fragile fast.
 

If the toolchanger robot only requires point-to-point motion and doesn't require circular or linear interpolation, then extrajoints can be used. Basic safety chains, homing, and limits will work as for other regular joints. However, for motion planning, you need to connect the simple_tp or limit3 components. Their motion calls should be implemented in custom M-code (e.g., M100 P1.2 Q23 ...).