Activity
Mon
Wed
Fri
Sun
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
What is this?
Less
More

Owned by Markus

Learn PLCs, HMIs and troubleshooting with AI as your co-pilot. Siemens, Rockwell, CODESYS and more, all in simulation. For techs and students.

5 contributions to The Controls Floor
Fault Challenge #1 answer: the transfer that times out
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.
0
0
The Prompt Library is live: 71 prompts for real PLC work
Every prompt from the courses is now in one place, cleaned up so you can use it on your own projects: Prompt Library 11 pages, organised by job: - read and explain code you didn't write - write LAD, SCL, STL, FBD and GRAPH - review AI code before you trust it - analog scaling and PID - test plans, forcing and FAT records - troubleshooting and fault finding - HMI screens and alarms - plant data (collectors, databases, dashboards) - drawings, I/O lists and tag tables - commissioning and handover Each prompt tells you what to paste in, gives you the prompt ready to copy, and lists the mistakes AI usually makes on that task so you know what to check. There's a full PDF on the first page if you want it offline. Start with page 1, "How to use this library". The rules there matter more than any single prompt: give the platform and version, paste real exports, ask for tables, and don't let the model guess. The files behind the courses are in Project Files: the demo line program and HMI, the data stack, Excel templates for FAT records, fault logs and I/O lists, and every Siemens reference solution, compile-checked in TIA Portal V15.1. Both are part of Premium. Question: which prompt would you want added next? Reply with the task you do most and I'll write one for it.
0
0
Start Here
Welcome to The Controls Floor. This is a place to learn PLCs, HMIs and troubleshooting with AI as your co-pilot, in simulation, where mistakes cost nothing. HOW THIS WORKS - Every week there is a fault challenge: a simulated line with something broken. Find it, post how you found it. - Build videos show AI writing real PLC code, then testing and breaking it. - The Prompt Library (Premium) has the exact prompts I use, ready to copy. THREE THINGS TO DO TODAY - Introduce yourself in General: your role, your PLC, what you want to learn. - Watch the 5-language build in Builds and Projects. - Try this week's fault challenge. THE RULES THAT MATTER - Simulation only. Never connect AI to a live machine. - AI never writes safety logic. That stays with qualified people and certified tools.
0
0
AI wrote a PLC program in 5 languages. Here's the proof.
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?
0
0
Fault Challenge #1: The transfer that times out
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.
0
0
1-5 of 5
Markus Splawn
1
5 points to level up
@markus-splawn-3293
Mechatronics and controls tech. I build with PLCs, automation and AI, and share what actually works on the floor.

Online now
Joined Oct 13, 2026
Powered by