Unattended is the point of the machine — and the reason a crash costs so much more
The economics of a Swiss-type or multi-channel turning machine assume it runs unattended off a bar — nights, weekends, whole shifts with nobody watching. That’s where the margin is. It’s also what changes the stakes of a program error completely. With an operator standing there, a bad move is a feed-hold and a near-miss. Lights-out, the same move is a crash discovered hours later: a full bar of scrap, a broken tool that kept cutting air for two hours, a tightly-set machine damaged and down, and the run that was supposed to be finished by morning not even started.
The only way unattended machining pays off is if the program is genuinely proven before the lights go off. Not “looks right.” Proven — executed the way the control will run it, on a twin of the machine, with everything that can go wrong at 2 a.m. already checked.
The pre-lights-out checklist
Before a program runs unattended, these are the things that have to be verified — and they’re exactly the ones a listing and a toolpath render leave uncertain:
- Hard collisions across the whole program, over the real fixtures — not just the operations the CAM generated.
- Near-miss clearances between cutting edge and equipment — the ones that are fine tonight and a crash the day a tool is set a millimeter closer.
- Synchronization across channels and the sub-spindle transfer — the timed handoffs that drop a part if a beat is off, with nobody there to catch it.
- Overtravel / end-of-travel on rotary and combined-axis moves — a fault mid-run stops the whole night’s production.
- Finished part vs model — so a silent offset error isn’t quietly scrapping every part until morning.
- Pre-holes for tapping present — so a tap isn’t breaking into a hole that was never drilled.
- Constructor cycles, macros, subprograms and probing executing as intended — the runtime behavior that a toolpath sim never ran.
Any one of these unverified is a candidate for the crash you find at 6 a.m. The whole point of proving the program is that none of them is left to chance.
The scaling problem: it's not one program, it's the night's worth
There’s a practical wrinkle to lights-out verification that a single-program check doesn’t solve: a night of unattended running often means many programs — different parts, different setups, queued back to back. Verifying each one thoroughly, one at a time, on the programming station, becomes its own bottleneck. The verification that’s supposed to enable lights-out can end up gating it.
That’s a throughput problem, and it needs a throughput answer: run the simulations the way you run the parts — in a queue, in parallel, overnight.
Where Eureka G-Code and Eureka Cloud fit
Eureka G-Code proves the individual program the way the control will run it, on a twin of your real machine — every item on the checklist above, from inter-channel collision and sub-spindle transfer to overtravel, part-vs-model, and probing — because it executes the true ISO, not a toolpath render.
Eureka Cloud solves the scaling problem. It turns the network into a distributed simulation resource: projects are queued simply by dropping them into a monitored shared folder, and simulations run at set times (overnight, say) or on demand, in parallel across available licenses. If a simulation finds no errors, the program is cleared to run. If it finds errors, Eureka Cloud produces a report with the information needed to fix it — and the simulation can be opened and analyzed in Eureka Viewer on a Windows PC with a dedicated GPU. So the whole night’s worth of programs is verified before the lights go off, instead of one at a time at the programming station the next morning.
That’s what makes unattended machining actually safe to leave: not a hope that the programs are fine, but a queue that proved every one of them, on twins of the machines, while nobody was there.
> Take the set of programs you’d run unattended tonight — the queue for the night shift or the weekend — and put them through Eureka G-Code, with Eureka Cloud running the simulations in parallel. Walking away from programs a twin has already proven, instead of programs that merely look right, is the difference lights-out was supposed to buy you.
FAQ
What has to be verified before running a program lights-out?
The full set of failure modes an operator would otherwise catch: hard collisions over the real fixtures, near-miss clearances, channel synchronization and sub-spindle transfer, overtravel, finished-part-vs-model, pre-holes for tapping, and the runtime behavior of constructor cycles, macros, subprograms and probing. Unattended, any one left unverified is a candidate for a crash discovered hours later.
Why is a crash worse during unattended machining?
Because nobody stops it. Instead of a feed-hold and a near-miss, an error lights-out becomes a full bar of scrap, a tool that broke and kept running, a damaged machine, and a run that didn’t happen — discovered only when someone arrives.
How do I verify a whole night's worth of programs efficiently?
Eureka Cloud queues simulations by monitoring a shared folder and runs them in parallel across available licenses, at scheduled times or on demand. Programs with no errors are cleared; programs with errors get a report, and the simulation can be reviewed in Eureka Viewer. That way the night’s queue is proven before the lights go off, not checked one at a time afterward.
Does the simulation use the real machine and program?
Yes. Eureka G-Code executes the true ISO the control receives on a digital twin of your actual machine and kinematics, so the checks reflect what will really run unattended — not an idealized toolpath.
How do I review a flagged simulation?
Eureka Cloud produces a report identifying the problem, and the simulation can be opened and analyzed in Eureka Viewer on a Windows PC with a dedicated GPU.
Next step
Request a demonstration on a digital twin of your own machine
Prove the whole night’s queue on twins of your machines — before the lights go off, not after.