Monday morning, first start of the shift. Operator hits Start on the incline conveyor and the VFD trips on overcurrent about a second into the ramp. Reset it, hit Start again, same trip. Third or fourth try it finally gets moving, and once it's warm it runs all day with no trouble. What you know: - It only happens on the first start after the line sat overnight or over the weekend. - Motor and gearbox are about two years old. Nobody changed the drive parameters. - The motor has a brake on it. You can hear a click when the drive starts. - Belt is loaded with product that sat on it overnight. - The drive's fault history shows the same overcurrent trip at almost the same point in the ramp every time. Tell us two things: 1. What do you think is causing it? 2. What's the one check you'd do to prove it before you change anything? More than one answer can fit here, so tell us why you landed on yours. I'll post how I'd work it Friday.

My order: 6, 2, 3, 4, 1, 5 6. HMI first. It's right there and it takes ten seconds. Half the no-start calls I've had were the machine sitting in Manual, a message nobody read, or another station holding it. 2. E-stops and safety relay. Somebody hit one and walked off, or the relay never got reset after the last stop. Look at the buttons and the relay lights on the way to the panel. 3. Drive or starter. A tripped overload or a drive fault won't always make it to the HMI. Open the door, look at the drive display and the overload. 4. Loose wire on the Start button. Buttons get slammed all day and the screws work loose. Quick look and a tug on the wires at the button before you open a laptop. 1. Go online. Now you know safety and the drive are good and the button's wired tight. Find what's false on the start rung. 5. Meter last. Not because power doesn't matter, but if the HMI, the drive and the PLC all have lights, you've already got power. You grab the meter for breakers, fuses and 24 volts when something's dark. The idea: cheapest and quickest looks first, laptop and meter when the quick looks don't explain it. Saw a different order that makes sense for your plant? That's fair. If your E-stops drop out the HMI too, checking them first is smart. Tell me in the comments what you'd change. Challenge #5 goes up Monday.

You get called to a conveyor. Operator hits Start and nothing happens. Motor doesn't run, no alarm on the HMI, and the line behind it is starting to back up. Here are six things you could check. They're in no particular order: 1. Go online with the PLC and find what's keeping the start rung from going true. 2. Check the E-stops and the safety relay. Is one pulled, is the relay reset, are its lights right? 3. Look at the drive or the starter. Fault code on the VFD, overload tripped, ready light on? 4. Check for a loose wire on the Start button. 5. Meter the power. Disconnect, breakers, fuses, 24 volts. 6. Check the HMI. Is it in Auto, anything in the alarm banner or history, is another station holding it? Put them in the order you'd actually do them on the floor, like 3, 6, 1, 2, 5, 4, and tell us why you put your first one first. There's no trick here. Everybody works a little different, and I want to see how you all go at it. I'll post how I'd run it Friday.

THE CAUSE The infeed inhibit is wired to the wrong bit. In PRG_Conveyors, fbInfeed.xInhibit reads fbAlarmMgr.xInfeedPreWarnMem. That's the pre-warning memory, not the jam alarm. Here's what happens on START: 1. M1 starts with no part at B1 yet, so the infeed watchdog timer starts. 2. tInfeedPreWarn is T#1S. After 1 second, xInfeedPreWarn goes TRUE and latches xInfeedPreWarnMem. 3. That latch is the inhibit, so fbInfeed loses its enable and M1 drops out. Why there's no alarm: xInfeedPreWarnMem is a diagnostic memory, a maintenance log bit. It never goes through the alarm trigger, so it never shows in wAlarmWord and the reset light stays off. The live pre-warning bit only blinks for a moment. Once M1 stops, xInfeedRunning goes FALSE, the watchdog resets and the warning clears. Why reset and stop/start do nothing: the only thing that clears the latch is xMaintClear. PRG_Main never wires that input when it calls fbAlarmMgr, so it sits FALSE forever. RESET only clears the latched alarms and the first-out. Stop/start only resets the SFC and purges the tracker. The latch isn't RETAIN, so a fresh download clears it, and that's why a new download gets you exactly one more second. HOW TO PROVE IT 1. Put fbInfeed.xInhibit, fbAlarmMgr.xInfeedPreWarn, fbAlarmMgr.xInfeedPreWarnMem, xInfeedRunning and wAlarmWord in a watch list. 2. Start the line with no part on the infeed. 3. Watch xInfeedPreWarnMem go TRUE at 1 second. xInhibit goes TRUE with it and M1 drops out. wAlarmWord stays 0. 4. Press RESET. The memory bit doesn't move. 5. Put a part at B1 before the second is up and the line keeps running. That points at the watchdog latch, not the motor, the sensor or the SFC. THE FIX One wire. In PRG_Conveyors, point the inhibit at the real jam alarm: fbInfeed.xInhibit := GVL_Alarms.fbAlarmMgr.xInfeedJamAlarm; Now M1 only stops on a real INFEED_JAM after tInfeedJam (20 s). That alarm shows on the HMI and clears with RESET. While you're in there, wire xMaintClear to something, like an HMI maintenance button. Otherwise the pre-warning memory can never be cleared.

The infeed runs a second and drops out. No alarm, reset doesn't clear it, and the HMI says the line is healthy. 13 blocks across SFC, ladder, FBD and Structured Text, and one wire is behind it. The project is in Classroom / Project Files / SortCell Challenge. Find it first, then watch how Claude traced it: https://youtu.be/bYE0cOxTlyE Drop your answer below. Tell us where you started looking, and how long it took you.