Ran a one-week pilot with Desoutter DC nutrunners on Door Line 2; rework dropped 28%, but we lost about 0.6 sec at takt from program swaps and cord management. For those who’ve made the switch, how did you handle quick-change programs and cable routing to keep flow, and did you push OK/NOK straight to MES or buffer locally to avoid cycle-time hits?
We tied the station barcode to auto-load the job on the Desoutter controller via Open Protocol and buffered the ‘OK/NOK’ in a small Node-RED queue, then pushed to MES async on tool release, which cut the swap hit to about 0.2 s. Caveat: cap the queue (e.g., 200 results) and add a short retry/backoff so an MES hiccup doesn’t block the tighten; for cords, a short overhead drop with a 90-degree swivel keeps snags down, but the buffer is what protected takt.
We clawed back about 0.5 s by keeping one “parent job” resident on the Desoutter controller and stepping parameter sets via PLC inputs instead of full program swaps, so the tool never reloads between hits. For the cords (), dropping from overhead through a 360° swivel with a short coiled pigtail and tucking the trunk inside the torque arm killed most of the drag. For data we push NOKs straight to MES but buffer OKs locally on the edge box and flush async; similar to @amartin, but we also turned off blocking acks on the Open Protocol results to avoid any wait. How many parameter sets are you swapping on Door Line 2?
On trim we kept flow by running the main lead in an overhead e-chain (Cable Carriers, Drag Chains & Energy Chains | igus®) and giving the tool a short whip on a balancer — like walking a dog on a short leash — and we used RFID-tagged sockets so torque curve selection happens as soon as the socket changes. We also post a single OK/NOK per VIN at station exit to cut traffic — are you swapping sockets per door or sticking with one bit?
Trim side, we shaved that “about 0.6 s at takt” by collapsing SKUs into two torque families and running a 3-step sequence (snug/angle/verify) so the Desoutter wasn’t swapping full jobs every door. For cords, a light torsion arm with a through-bore feed kept the lead off the operator’s wrists better than a straight balancer. On data, we post one part-level record to MES at station complete with the rundown traces bundled, not per fastener, and cycle stayed flat.
“part-level record to MES at station complete with the rundown traces bundled, not per fastener, and cycle stayed flat.” We matched that by using the Desoutter controller’s local sequencer to pre-arm the next job via one PLC bit and, on trim, adding a 180° inline swivel plus a 0.6 m coil whip off the balancer so the main lead stays parked; net we gained about 0.5 s back. Do you have a free I/O to pre-arm on approach?
We hid that ‘about 0.6 sec at takt’ by having the PLC send the next job ID to the Desoutter controller as soon as the prior rundown hits OK, so the program’s already loaded when the trigger pulls (CVI3 over Profinet). For cords, a ceiling drop with a slip ring and a short coiled lead killed the twisty mess — — without slowing the wrist. We push OK/NOK to a local MQTT broker and let MES subscribe async (Sparkplug B): https://www.eclipse.org/tahu/.
We cut the ‘cord management’ drag by mounting the Desoutter controller overhead with a 2.5 m drop, inline swivel, and a light spring retractor, plus a short umbilical with a breakaway plug — no more headphone knots. For swaps, an RFID read two stations upstream lets the controller cache the program set, and we publish a single summary to MES on station release via MQTT with a 150 ms timeout; tiny caveat: use QoS 1 and de‑dup IDs or you’ll get doubles. Are you on CVI3, @Ava?