You already know the sortation lines don't stop for anybody. A material recovery facility (MRF) booked solid runs two shifts, maybe three, and the window to cut in a new optical sorter or a fresh disc screen gets measured in hours, not whole weekends. The machine shows up on a truck, the vendor's commissioning engineer is booked for three days, and the plant manager's real worry isn't whether the new sorter works. It's whether the four lines already running will start clean on Monday morning.
That worry is the correct one. The new box is a known quantity: factory-tested, documented, a support number on the side. The risk lives everywhere it touches the old system, and most of that surface never shows up in the sales demo.
The running plant is the hard part
When people talk about MRF control system integration they picture wiring up the newcomer. The hard engineering sits on the other side of the fence, in the running plant you're not allowed to break. Your existing programmable logic controller (PLC), the industrial computer that runs the line logic, has a finite pool of input/output (I/O) capacity, a worst-case scan time it has to stay under, and a supervisory control and data acquisition (SCADA) system on top that operators have learned to trust. Each is a budget you're about to spend.
Here's the part people get backwards. A modern optical sorter does its own high-speed work: the camera or near-infrared sensor, the belt encoder, and the valve manifold that fires the air jets all live inside the vendor's dedicated controller, because tracking a bottle down a moving belt is too time-critical to hang off a general-purpose PLC scan. The ejector timing is not your processor's problem, and any integrator who proposes to run the valve array from your shared line PLC is telling you something useful about themselves.
What lands on your PLC is the connective tissue: interlocks, feed-throttle logic, startup and shutdown sequencing, the comms handshakes with the new controller, the extra alarms on the SCADA. A few hundred rungs of that on a current processor is tens to a couple hundred microseconds of added scan, not milliseconds; rung count rarely hurts you. What pushes scan into territory that matters is heavy communications traffic, big message instructions, stacks of analog and PID (proportional-integral-derivative) control, and it's the worst-case scan you watch, not the average. If a piece of new logic really is time-critical, the fix isn't to let the whole main loop grow, it's a periodic task at a set interval or a hardware output that doesn't wait on the scan. So the first honest question, before anyone pulls a cable, is whether the existing processor has headroom for the connective work, or whether the new equipment should sit on its own controller and trade a small, well-defined set of signals with the main system. That second option often costs less in every way that matters, even though it looks like more hardware on the drawing.
What actually crosses the fence
A new machine rarely arrives naked. Modern sorters and screens ship with their own controller, their own operator screen, sometimes their own small SCADA node. The integration work is deciding, deliberately, what crosses the boundary between their system and yours, and keeping that list short. A handful of clean handshakes and nothing else: the line tells the sorter it's running and up to speed; the sorter tells the line it's healthy and ready, or faulted so the upstream feed backs off; maybe a rate or grade selection if you change target material by the load. What you don't want is two systems reaching deep into each other's guts, because then a firmware update on their side six months out silently rewrites how your line behaves.
How those signals cross matters as much as which ones do. Hardwired discrete wiring is slow to change but very predictable; a dropped wire is a dropped wire. A network link (Modbus TCP, an industrial Ethernet protocol, OPC UA) carries far more and wires in minutes, but it can go quiet while both ends still think everything's fine. Whichever you choose, the feed-throttle and not-ready signals need a heartbeat or comms watchdog behind them, so a dead link drops the feed to a safe state instead of freezing on the last value it heard. A stale "sorter ready" bit that keeps a feed running into a machine that tripped ten minutes ago will make you religious about watchdogs.
The other meeting point is the operator's screen, and it gets skipped constantly. If the new sorter's alarms only show up on a laptop bolted to the machine, your night-shift operator won't see them from the control room and won't act on them. Folding the new equipment's key states and alarms into the SCADA the crew already watches is not cosmetic; it's the gap between a fault someone catches in two minutes and one that runs blind until the quality check three hours downstream.
Sequencing, interlocks, and jams
Drop a screen into the middle of a running flow and you've changed the sequence whether you meant to or not. The startup order, the safe way to shut down without burying a transfer point, the interlocks that stop you feeding a machine that isn't ready: all of it was tuned, formally or by scar tissue, for the old arrangement.
The classic failure is the cascade on a jam. Upstream keeps feeding while the new machine is stopped, the transfer chute in front of it packs solid, and now there's a manual dig-out on a line that was supposed to be more automated than before. Preventing that means the new machine's not-ready and jam signals reach back up the line and throttle or stop the feed, with the right delays so a half-second blip doesn't trip the whole plant. It has to be thought through before the machine goes live. The first bad load of wet cardboard is a lousy time to find out.
Screens bring a mechanical wrinkle worth flagging. The control system can sequence a disc or star screen perfectly and the screen can still choke because the discs are wrapped or the spacing is wrong for your material. Sometimes the fix is genuinely in the logic, and sometimes it's a maintenance call about media and wrap, and dressing up a mechanical problem with a cleverer control scheme just wastes a week. I'd rather tell you which one it is.
Before you touch a live processor
Everything above is about keeping the plant running. The bigger risk during the actual cut-in is to the people doing it. Tying a new machine into running lines means emergency-stop (E-stop) zones that now have to take in the new equipment, guarding and safety-rated interlocks that are not the same animal as the process interlocks I've been describing, and lockout/tagout and arc-flash discipline the moment anyone opens a live panel. A jam-throttle interlock keeps product moving; a safety-rated stop keeps a hand out of a screen. They run on different hardware and get engineered differently, and conflating them is how people get hurt. Alongside that, the cheapest insurance in the job is a verified backup of the existing program and a rollback to a clean Monday start if the cut-in goes sideways. Before you touch a processor carrying two other lines, know exactly how you undo what you're about to do.
What this looks like on a real plant
A regional MRF I worked with wanted to add an optical sorter to pull a PET thermoform grade off a line already near capacity. The vendor's plan put all the interface and sequencing logic on the existing main PLC because the I/O count fit. It did, on paper. The trouble wasn't the sorter's ejection timing, which stayed on the sorter's own controller where it belonged; it was that the main processor was already carrying two other lines with a worst-case scan in the low twenties of milliseconds, and the added comms load and sequence logic nudged it up enough that a couple of existing interlocks started answering a beat late under load.
We moved the sorter's coordination onto its own compact controller and cut the interface to six signals: line running, line at speed, sorter ready, sorter fault, feed-throttle request, and selected grade, each with a heartbeat so a dropped link backed the feed off. Their key alarms got mapped into the existing SCADA. The physical cut-in happened inside a planned maintenance window, under lockout, tested one handshake at a time against a simulated line before it touched the real belts. It wasn't seamless: the two systems numbered the grades differently and we didn't catch the mismatch until the sim, and the capture rate needed a week of the vendor trimming ejector timing before it settled. But the running lines never lost a shift, and the main processor's scan went back to where it started. What made that boring was deciding where the boundary sat before drilling the first hole.
The risk lives in your old PLC's spare capacity and in the boundary around it. The new box that arrived on the truck is the least of it. Check the existing processor's headroom before you assume the connective logic fits, and lean toward a separate controller with a short, watchdogged interface when it doesn't. Get the new machine's alarms onto the screen your crew already trusts. Sequence the interlocks so a jam backs off the feed instead of packing a chute, keep the safety-rated stops on their own hardware, and don't open a live panel without lockout and a tested rollback. And when the honest answer turns out to be a mechanical fix, media or wrap or a chute liner, rather than a smarter loop, take the mechanical fix. It's the unglamorous groundwork that decides whether a capital project pays off, and it runs through all the waste and material recovery work where uptime is the whole game.
If you've got a machine on order and you want to know the cut-in won't cost you the lines already running, tell me what you're adding and how the plant runs now and I'll give you a straight read on where the real risk sits.