Multi-Process Machines

Machine Configuration → General → Processes → Add. A plasma table can take on Oxyfuel and Router; an oxyfuel table can take on Plasma and Router; a router table can take on either torch. Mill and Lathe stay dedicated — those are different machines, not different heads.

The new process shares everything that describes the machine: axes and travels, homing and MCS origin, work offsets, the connection, the tool library, subroutines, hooks and pendant. Set those once and they are right for every head.

It gets its own copy of everything that describes the cut: post processor and its properties, torch or cutter selection and the factory cut charts that come with it, contour rules, lead-in and lead-out geometry, nesting part spacing, and quote rates. That separation matters in practice: oxyfuel wants wider part spacing than plasma because the kerf and heat-affected zone are bigger, a "disable THC" rule is meaningless on a flame torch, and most shops charge flame cutting differently.

Once a machine has more than one process, Machine Configuration grows a section per process — a Plasma group and an Oxyfuel group, each with its own Post, Torch and Rules underneath. A machine with a single process looks exactly as it always has.

Each head sits at a fixed X/Y offset from the others, and the machine already knows how to handle that: the tool library gives every tool number an X/Y offset, and JetCad3 applies it at runtime as a coordinate offset. Nothing is baked into the program, so the G-code stays in part coordinates and the same file cuts correctly whichever head runs it.

To wire it up, set each process's post to announce its head at the top of the program:

1. Plasma → Post — tick Emit tool select in header, set the tool number to 0.
2. Oxyfuel → Post — tick Emit tool select in header, set the tool number to 1.
3. In the machine's tool library, give tool 1 the measured X/Y offset from the plasma torch. Tool 0 stays at zero.

Now every program picks up the right head before it moves. The tool number goes out in the header, before the first rapid, so the very first pierce of a job is already in the right frame — including the first job after you switch heads.

Router tables need none of this. Router operations already carry their own tool numbers from the tool library, one per cutter, so a bolt-on spindle just needs each cutter's offset set there.

Because it is one machine, it has one machine workspace and one shared program queue. Post an oxyfuel job from the Oxyfuel workspace and it loads onto the table you are actually connected to, alongside anything you posted from Plasma. Previously a second profile meant a second machine workspace competing for the same port.

Multi-process is available on machines JetCad3 drives itself — anything using a GcodePilot post (FluidNC, GRBL). JetCad3 owns the tool table on those, which is what makes the head offsets work.

On a table with its own controller — LinuxCNC, Mach, MASSO — the tool table lives in that controller's configuration, so a second head is set up there instead.

Nothing changes for a machine with one process. Profiles work exactly as before, a .jcm saved now still opens in older versions of JetCad3, and posts you have already configured produce identical G-code — the header tool select is off unless you turn it on.

If you already built a second profile for your oxyfuel torch, add the process to the plasma machine first, set up its post and torch, then delete the old standalone profile. It becomes deletable as soon as the plasma machine covers oxyfuel, because the workspace still has a machine to use.