THE CAUSE The transfer step timer kept counting while the line was stopped. In the sorting program (SortingByHeight, SCL), every step of the transfer has a timer, tStep, and a watchdog: if a box takes longer than 6 seconds (TRANSFER_TIMEOUT_S) to reach its exit conveyor, the program raises fault 102 "Transfer timeout". That is a good check. It catches a stuck box. The bug was where the timer was updated. It ran on every scan, before the program checked whether the line was running: #tStep := #tStep + #scanDt; // counted on every scan IF #running THEN ... 10: ... ELSIF #tStep > #TRANSFER_TIMEOUT_S THEN #faultCode := 102; So when an operator pressed STOP in the middle of a transfer (step 10 or 20), the conveyors stopped but tStep kept growing. Leave the line stopped for more than 6 seconds, press START, and on the very first scan in step 10 the program sees tStep > 6.0 and throws 102. Nothing is jammed. The timer was measuring time stopped, not time moving. HOW TO PROVE IT BEFORE CHANGING ANYTHING 1. Put tStep, step, running and faultCode in a watch table and go online. 2. Start the line and let a box enter the transfer (step 10). 3. Press STOP. Watch tStep: it keeps climbing even though running is FALSE and nothing moves. 4. Wait past 6 seconds, press START. faultCode goes to 102 on the first scan. 5. Repeat with a stop shorter than 6 seconds: no fault. That points straight at the timer, not the mechanics or the sensors. If you can make the fault come and go with nothing but how long you wait, it's a logic problem, not a field problem. THE FIX Only advance the step timer while the line is running. One condition: IF #running THEN // step timer only runs while running: a Stop mid-transfer must not count toward the transfer timeout #tStep := #tStep + #scanDt; Now a stop pauses the timer, START resumes it, and 102 only fires when a box is really stuck for 6 seconds of running time. A RELATED TRAP WE FIXED AT THE SAME TIME Reset used to send the sequence back to step 0 even while a box was still on the transfer. Step 0 reloads the box direction from the next box's height reading, so the box on the transfer could be pushed the wrong way and time out: another false 102. Reset now keeps the current step while a box is on the transfer.

I gave Claude a mixing cell to program in Siemens TIA Portal: a ladder OB1, an SCL batch sequence, an STL status block, FBD analog scaling and an S7-GRAPH sequence. It wrote all of them, imported them, and the project compiled with 0 errors. What it got right, what I had to fix, and what I would never let it touch (safety) are all in the video. Full build (22 min): https://youtu.be/WtmMeiEcORA Question for you: which language do you use most at work, and would you trust AI to write it?

A sorting line sorts boxes by height onto two exit conveyors. After an operator hits STOP in the middle of a transfer and then START again, the line faults with 102 "Transfer timeout", even though nothing is jammed. YOUR JOB - What is the most likely cause in the program? - How would you prove it before changing anything? - What is the fix? Post your answer below. I will post the real cause and the fix in the PLC code on Friday, with screenshots from the live test.