These four steps produce an L5X ready for Studio 5000 import. The full guide below covers every option in detail.
Overview
Code Analyzer parses an L5X export from Studio 5000, lists every routine it contains, and produces a structured report on whichever routine you select. The headline pass is the AI review, purpose-built to find logic errors, copy-paste mistakes, missing interlocks, and the hidden bugs a static rule set can’t catch. It runs on top of a deterministic rule layer that flags structural problems on every rung of the selected routine. Findings from both layers land in the same report, ranked by severity, each with the rung number, the tag or instruction involved, and a plain-English suggestion.
Common uses: pre-commissioning review, evaluating an inherited program, accepting delivery from a contractor, or deciding whether to patch a legacy program or rewrite it. The analyzer does not modify your code, it produces findings, dismissals, and a report.
Before you start. You need an L5X export from Studio 5000. The analyzer works on one routine at a time, so you’ll pick a single routine from the parsed L5X before running. A full program export gives you the full routine list to choose from; single-routine, AOI, and UDT exports also work and you just pick from a shorter list.
What the analyzer checks
Findings come from two layers: an AI review that does the work of a senior engineer on a code walkthrough, and a deterministic rule set that catches structural defects no review should miss.
AI review
The AI review is the differentiator. It reads every rung in context (the instructions, the tags, the comment, the surrounding rungs) and looks for problems a static rule set can’t see:
- Logic errors. Conditions wired the wrong way around, latches that can never clear, comparisons against the wrong scaled value, sequence steps that skip a precondition.
- Copy-paste mistakes. A rung duplicated from a sibling device but with a tag reference left pointing at the original. By far the most common bug in production code, and one of the hardest to spot by eye.
- Hidden mistakes. Rungs whose logic doesn’t match the comment above them. Missing interlocks on rungs that should have safety conditions. Inconsistencies between paired rungs (a start without a matching stop, an enable that contradicts itself across paths). Structural and naming suggestions that improve maintainability.
The review runs as a multi-pass pipeline: a discovery pass that summarizes each rung in isolation, then a re-review pass that revisits each rung with the full routine in context. A rung’s role inside the larger sequence informs the finding, not just the instructions on the rung itself.
Three review depths
Pick an effort before you run the review. Each higher tier consumes more AI usage capacity than the previous level, and generally runs longer in exchange for deeper coverage.
| Mode | When to pick it | Plan |
|---|---|---|
| Quick | Fastest LLM review. Best for “did this change introduce anything obvious?” sanity checks. | Pro and above |
| Standard | Balanced depth, the default for a serious review. Uses ~5x the capacity of Quick. | Pro and above |
| Deep | Deepest review. Slow, thorough, the one you run before commissioning or accepting delivery. Uses ~5x of Standard. | Geek and above |
Step 1. Upload your L5X and pick a routine
Open Code Analyzer from the dashboard. Drag an L5X file into the upload area or click to browse.
PLCflow parses on upload, extracting the program name, listing every routine and AOI, counting rungs, and building the tag usage statistics.
After parsing, you can navigate to the Browse tab with a routine list grouped by parent program. Each entry shows the routine name, rung count. Search throughout all the routines, or click the routine you want to analyze.
Then to the Analysis tab. The mode selector above the Run analysis button lets you pick Deterministic (rule-only, instant), Quick, Standard, or Deep. Deterministic always runs; the three AI modes layer on top and consume capacity from your plan. To analyze additional routines from the same upload, run the process again, pick another routine, and run again; each run targets the routine that’s currently selected.
Step 2. Review findings
The findings view shows the selected routine’s health score, a severity breakdown, and the list of findings. Deterministic rule hits and AI-review findings rank together by severity.
Click a finding to see the rung context: rung number, the instructions on the rung, the tag involved, and the suggestion. Cross-rung rules (like OTL_NO_OTU or DUPLICATE_OTE) list every related rung so you can trace the issue without scrolling Studio 5000. AI-review findings include the model’s reasoning alongside the suggestion.
Health score
The routine gets a numeric health score (0–100) with a band label (e.g. Excellent / Good / Needs Work). The score is opinionated: a routine with several unconditional outputs and missing JSR targets will score lower than one with a handful of info-level dead rungs.
The score is most useful relative to itself across versions of the same routine. Watching it rise after a refactor is a better signal than the absolute number on day one.
Dismissed findings
When an AI review runs, the model can mark an initial finding as dismissed if its broader read of the routine shows the finding is a false positive. Common cases: an OTU_NO_OTL where the latch lives in a sibling routine, a deliberate AFI-disabled rung that was flagged as dead. Dismissed items appear in their own panel below the active findings, struck through, with the AI’s reason attached so you can see what was filtered and why. Dismissals are generated fresh on each run.
Step 3. Act on the findings
Triage by severity:
- Errors are real problems.
JSR_TARGET_MISSINGwill cause a runtime fault;OTL_NO_OTUwill leave outputs latched on forever. Fix before commissioning. - Warnings need engineering judgment. An
OTU_NO_OTLon an HMI command tag is expected; aDUPLICATE_OTEon a motor run output is probably a bug. Read each one. - Info is meant to be informative. Things like disabled rungs (
DEAD_RUNG_AFI) and empty rungs that are usually intentional.
The analyzer does not modify your code. It produces findings. You apply fixes in Studio 5000. False positives happen, especially on cross-rung rules when the latch or OTE lives outside the exported scope, and occasionally on AI review findings where the model misreads intent. Treat AI findings as a starting hypothesis to verify, not ground truth.
Step 4. Export the report
Click Export PDF to download a formatted report. The PDF covers the routine you just analyzed: program / controller metadata, the health score, the full findings list (deterministic and AI), and the AI review summary if a review ran. Designed to save findings for later, or for review meetings and customer handoffs. Run the analyzer + export step for each routine you want documented.
Common pitfalls
- Cross-routine references read as findings. Cross-rung rules (
OTL_NO_OTU,DUPLICATE_OTE) and the AI review only see the routine you selected. If the latch or OTE that resolves a finding lives in a sibling routine, the analyzer can’t see it and the finding will surface. The AI review pass can dismiss these when it has enough surrounding context, but otherwise they’re expected on routines that share state with others. - HMI tags flagged as unlatched. The analyzer skips tags whose names contain
hmi,pb,pushbutton,cmd,button,operator. If your shop uses different naming, the heuristic misses them and you’ll see falseOTL_NO_OTUfindings. Treat as informational. - Section-separator rungs flagged as empty. A rung with no instructions but a comment is treated as a separator and skipped. A rung with no comment is flagged
EMPTY_RUNGat info severity. - Health score dropped after a refactor. Sometimes a refactor exposes pre-existing issues the rule set couldn’t see in the old structure. Read the new findings before assuming things got worse.
- AOI-level findings are sparse on deterministic. The rule set is tuned for ladder logic in routines. AOI-internal logic gets parsed but the rules are conservative. The AI review produces more on AOI internals. Use Standard or Deep when you’re analyzing an AOI’s routine, not the default Deterministic pass.
FAQ
What's the difference between Quick, Standard, and Deep?
Three depths of AI review. Quick is the fastest LLM pass, best for routine sanity checks (“did this change introduce anything obvious?”). Standard is the default for a serious review; it uses ~5x the AI capacity of Quick and digs noticeably deeper. Deep uses ~5x the capacity of Standard, runs the full multi-pass pipeline, and is the one you run before commissioning or accepting delivery. Quick and Standard require a Pro plan or higher; Deep requires Geek or higher. The button tooltip in the analyzer names the estimated capacity each run will consume from your plan before you commit.
Does it work on Structured Text or Function Block routines?
Partially. The parse extracts ST and FB routines and counts them, but the deterministic rule set only runs against ladder logic. ST and FB content surfaces in the report as structural metadata. The AI review can produce findings on ST.
What about GuardLogix safety routines?
The parser reads them. The rule set does not have safety-specific rules and PLCflow is not certified for safety review. Treat findings on safety routines as informational only.
Can I add my own rules?
Not in the current build. The rule set is curated and shipped with the module. Drop us a note at [email protected] if there’s a check you keep wanting.
Why does the same tag get flagged twice on different rules?
Each rule runs independently. A latched output with no unlatch could trip OTL_NO_OTU (the latch side) and UNCONDITIONAL_OUTPUT (if the OTL has no input conditions). Both are accurate. Fix the underlying issue and both findings clear.
Related
- I/O Code. Run the analyzer over your generated I/O Code output before importing. Catches drift between your spreadsheet and the produced rungs.
- Tag Database. Naming consistency starts with the source-of-truth tag list. Populated database means fewer naming-related warnings to triage.
- Alarm Code. Analyze the generated alarm routine before importing. Catches missing references and structural issues.
Related modules
Generate a Studio 5000 routine from an I/O list. Upload a spreadsheet, paste from one, or add rows by hand. Output is an importable L5X with tags, UDTs, and AOIs bundled in.
Library of reusable device, alarm, and parameter definitions. Tags defined here can be pulled into any code generation module via Import from DB.
Define alarm conditions in a table. Get a Studio 5000 routine bundling the ALARM_UDT, alarm tags, and detection logic into one importable L5X.
Honest feedback. We read all of it.