From Prompt to Plant is the series where we share, openly and in full, the prompts that let you program an Industrial Shields PLC with Claude Code. The AI writes the code; you validate it on a test bench.
One signal. Many meanings.
A digital input on a PLC does not mean one single thing. It means whatever you know how to read. The same pulse can be a produced part, the start of a cycle, a machine running or stopped, a reject, a micro-stop nobody logs, or the real speed of the line.
Here is the interesting part: knowing what that signal means in your plant — and saying it right in a prompt — is worth as much today as knowing how to program it. Or rather: today it can replace it. The AI writes the firmware in minutes. What it cannot decide for you is what you measure and what it means. That interpretation — 24V, edge, debounce, what counts and what is noise — is the real engineering, and it goes inside the prompt.
The example
On a monitoring deployment on circular knitting machines, the usual problem: nobody knew how much each machine produced until someone counted pieces by hand at the end of the shift. The solution is one of the simplest there is: a 24V proximity sensor pointed at a moving part plus an ESP32 PLC. Each pulse, one unit. The "hello world" of the factory — and almost nobody has it set up.
The prompt (copy it in full)
This is what a good prompt looks like: context, the why behind each requirement, explicit constraints, the order in which you want the answer — and how you are going to validate it. Paste it as-is into Claude Code and change the model in the hardware block if yours is a different one.
CONTEXT I want to turn a machine that reports nothing today into one that counts its production in real time: how many parts this shift, at what rate, and whether it has stopped. HARDWARE - PLC: Industrial Shields ESP32 PLC 14. (If your model is another member of the ESP32 PLC family — 19R, 21, 38R, 42, 57R or 58 — change it here: the I/O mapping changes between models.) - Sensor: 24V industrial proximity sensor (inductive or photoelectric) pointed at a moving part of the machine. NPN output: pulse goes low. - Wiring: the sensor signal comes in on digital input I0_0. - Physical meaning: 1 pulse = 1 part produced. WHAT I NEED, AND WHY 1. Counting via a hardware INTERRUPT on the falling edge of I0_0, not by polling: polling loses pulses while the firmware is busy writing to SD or reconnecting to the network. 2. Minimal ISR: it only increments volatile counters. No Serial, no String, no delay inside the interrupt. 3. Software debounce inside the ISR, starting at 30 ms between valid pulses. This is the critical point: a mechanical sensor bounces and a nearby variable frequency drive injects electrical noise; without the filter the counter over-counts and afterwards nobody knows why. Also tell me how to tune that time to the real maximum speed of my machine so the filter does not end up eating good pulses, and what pulses-per-second ceiling the chosen value imposes. 4. Two counters fed by the same interrupt: an interval counter, reset every time it is sent, and a shift counter that accumulates until it receives an explicit reset command. 5. Every 20 seconds: read and reset the interval counter atomically (wrapped in noInterrupts()/interrupts()), estimate RPM by extrapolating that count to one minute, and publish interval, shift and RPM. Leave the MQTT broker as a configurable placeholder; if you prefer a simpler first test, print it over the serial port. 6. Counting must not depend on the network: if the connection drops, the machine keeps counting and the send is retried in the background, without blocking. CONSTRAINTS - Do not invent terminals or pins: use the naming of the Industrial Shields boards package, and tell me which board to select in Arduino IDE so that I0_0 maps to the correct physical pin of my model. - No delay() in the main loop. - Do not add a web server, OTA or any other network surface I did not ask for. WHAT I WANT BACK, IN THIS ORDER 1. The assumptions you had to make and anything that blocks you: ask me before assuming something that changes the wiring or the logic. 2. The sensor wiring to the input (24V supply, signal, common) and what changes if my sensor were PNP instead of NPN. 3. The complete, commented code, ready to compile. 4. The bench test protocol. HOW I WILL VALIDATE IT (write the code so it passes this test) - I generate 20 pulses by hand with a pushbutton: the counter must read exactly 20, not one more. - I press very fast on purpose, simulating bounce: no double counts. - I restart the device: the shift counter must behave as you explained — you tell me whether it should persist or not, and why. - I unplug the network with the machine running: counting continues.
What you get
Production per interval, shift total and live RPM, with machine-stop detection for free. Claude Code delivers the firmware with the debounced ISR, the two counters and the periodic report, plus an explanation of the sensor wiring and a bench-validation protocol.
Before the machine
House rule: the AI writes the code, the technician validates it. Validate on the bench first, generating pulses by hand or with a button, before going near the machine. And the technician is the one who decides what the signal means — that is the part that does not fit in a weekend.
Answer five questions about your project — your I/O, your protocol, your control logic — and get the full prompt sequence, built with the same methodology as this series. Free.
Open the PLC Prompt Generator →Every week, one real, verified prompt. Next episode: no Arduino IDE — Claude Code compiles and flashes your PLC on its own. Full archive and upcoming episodes on this blog, and in the From Prompt to Plant newsletter.