🤖 Can AI Write PLC Programs? Test a Conveyor Program Step by Step

Can AI write a PLC program?

AI can propose a program, explain rungs and draft tests. That does not establish that the program matches the machine or behaves correctly. A useful workflow is requirement → I/O list → draft → independent review → simulation → qualified engineering verification. A plausible-looking rung is the beginning of the review, not its conclusion.

Here we use a five-package conveyor exercise in the Virtual PLC Lab. You can complete every test without an AI account or API key by loading the supplied project. No generated program in this article is connected to real equipment.

Specify the behavior before asking for code

For this exercise, enabling Auto requests conveyor operation while the Stop, E-stop, guard and overload inputs are healthy. The photoeye counts packages on rising edges. Five packages complete the batch, stop the conveyor and turn on an amber lamp. Reset clears the count. A mechanical jam prevents normal package feedback.

This particular teaching project resumes when Auto is on and its permissives return; it is not a separate-Start, restart-inhibited machine sequence. If the intended machine needs that behavior, add it explicitly to the requirement and test it as a different design.

A prompt that produces a reviewable draft

Ask for a rung plan with assumptions and expected results, not a claim of a “safe” finished program. For example:

Draft a teaching ladder rung plan for a conveyor batch counter.
Auto I8 permits running while healthy-high I1, I2, I3 and I4 are true.
Count rising edges of photoeye I5 with C0, preset 5.
Reset I9 clears C0. Q9 drives the conveyor; Q5 indicates batch complete.
State what happens on restoration of Auto/permissives and on held Reset.
Explain scan-order effects. Provide tests for a held photoeye, a jam,
a missing output connection and a completed batch.
Do not claim safety certification or invent controller-specific syntax.

Use an abstract description when consulting an external AI service. Avoid sending customer programs, credentials, network diagrams or other confidential plant information without authorization. Provider capabilities and billing vary; the lab exercise itself makes no AI requests.

Compare the draft with a known lab program

Load Conveyor batch counter from the lab’s guided projects. Its rung plan is:

1. Reset C0 when I9 is true.
2. Drive Q9 when Auto and all four permissives are true and C0.DN is false.
3. Count I5 rising edges with CTU C0, preset 5.
4. While Q9 is true, write the project’s speed demand of 80 to AO0.
5. Drive Q5 when C0.DN is true.

In this engine, CTU already detects a rising edge. Adding a second, poorly understood edge detector can change behavior. The run rung is evaluated before the counter rung: when the fifth edge sets C0.DN, Q9 clears on the following scan. The lamp rung, which comes after the counter, can see the new done bit in the current scan. This is a deliberate opportunity to observe scan order, not a prediction of a real conveyor’s stopping distance.

Also inspect AO0 after the conveyor stops: the example’s MOV rung does not explicitly zero its previous speed value. Q9 disables the simulated conveyor, but retaining an analog demand is a separate behavior to document. A real drive interface requires its own command and stop specification.

Run the acceptance tests

Use Schematic to trace I5 through the input card and Q9 through the output card. Use scan stepping and the counter monitor for the fifth-edge test. Save a baseline workspace before making changes, then compare expected versus observed results.

Introduce a defect and explain the failure

Change the run condition from “C0.DN is false” to “C0.DN is true.” With an empty batch the conveyor no longer starts. The program may be syntactically valid, but it violates the requirement. Ask an AI tool to explain the fault, then verify its explanation against the live rung state rather than accepting the explanation on confidence alone.

Next hold Reset while Auto remains on. Repeated reset can prevent the preset from being reached. Improving this teaching sequence could mean an edge-qualified reset, reset only when stopped, or a dedicated batch state—but first decide the intended operator workflow. Any change needs a fresh set of tests.

Extension: add a missing-feedback alarm

Write a requirement before adding a timer: when a run request exists but no valid package edge occurs for a chosen interval, latch a jam indication; acknowledgment alone must not restart motion. Define startup allowance, spacing between packages, sensor failure and reset conditions. Use the lab’s documented timers, edge contacts and memory bits to build the extension. The base project does not already implement it.

For an independent example of the difference between alarm acknowledgment, trip reset and a new command, open the Virtual SCADA Lab. It is a separate process simulation, not an HMI connected to this conveyor workspace.

For language fundamentals, read PLC Programming Languages: Ladder Logic vs Structured Text. Our broader AI copilots overview covers other engineering workflows; this article focuses on testing one concrete control requirement.

Learning scope: a browser simulation cannot validate physical safety, scan timing, wiring, motor stopping, communications or a vendor runtime. Real deployment requires the applicable engineering lifecycle, manufacturer documentation and qualified review.