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.

Picture this. A machine goes down, you walk up and scan a QR code on the panel with your phone. The prints, the manual and every past work order for that machine are right there. You ask what the fault means, and it answers from that machine's own documents, not generic internet advice. If the downtime runs long, it writes up the 5 Whys for you. That's what my Industrial Maintenance Intelligence Platform (IMIP) does, and the whole thing is free on GitHub: https://github.com/Markus864/Industrial-Maintenance-Intelligence-Platform What's in it: 1. A phone web app, nothing to install, that opens when you scan the QR code at the machine 2. An AI chatbot that answers with references to that machine's drawings and manuals 3. A PLC poller that reads fault data from Siemens S7 PLCs. It's read only, so it never writes to the machine 4. Automatic 5 Whys root cause write-ups for long downtime 5. A practice PLC project with 2 machines and 8 faults, so you can test it without a real plant You don't have to build the whole thing. Pick one piece and make it your own: - Just the QR code to documents part, for one machine at your plant or school lab - Point the chatbot at one manual and see how well it answers - Swap the Siemens poller for whatever platform you run (Allen-Bradley, CODESYS, anything) The app and your plant data run on your own server. The AI answers come from Google's Gemini API, so questions and the document bits it quotes go to the cloud. All the AI calls go through one file, so swapping in a local model is a solid project if your plant wants everything on-site. It's a solid project to show off, too. Saying "I built something that cuts troubleshooting time" stands out more than another certificate. Which piece would you build first? Tell me in the comments and I'll help you get started.

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.

You ask, and the block shows up in your project already imported, compiled and saved. That's what this setup gets you. The new video walks through it from zero, one step at a time: Claude Code, Python, the server file, the Openness group and one command to connect them. Then Claude writes a motor seal-in in ladder and an analog scaling block in FBD inside TIA Portal. The server file and the exact prompts are in Classroom > Project Files > Claude + TIA Portal (MCP server). Got it running? Post a screenshot of the first block Claude wrote for you. Stuck on a step? Post the step number and a screenshot and we'll get you through it.