PLC Simulator
Facts 2026-10-04.1
Reviewed 2026-10-04

Inspectable evidence

Public, reproducible test harness

Download cross-dialect reference vectors, inspect expected outputs and reproduce the same semantics in the browser.

Run the no-account exampleView facts JSON

Dialect test vectors (JSON)

Nine source programs for the same normally-closed safety-input semantic, plus inputs, expected outputs and source-test provenance.

Download JSON

Capability matrix (CSV)

A compact, reusable matrix of instruction families, dialect exposure, test ownership and declared limits.

Download CSV

Reference test: NC input semantics

Each fixture represents the same behavior: when input ES is false, output LIGHT is true; when ES is true, LIGHT is false. The syntax changes across nine dialects, but the normalized result must not.

CaseInput ESExpected LIGHTPurpose
NC path healthyfalsetrueProves inverse contact/output semantics.
NC path opentruefalseProves output de-energizes when the input becomes true.

How to reproduce it

  1. 1

    Download the JSON and choose one dialect fixture.

  2. 2

    Open /try for the no-account guided program, or sign in to use the full editor.

  3. 3

    Paste or recreate the fixture in its matching learning dialect.

  4. 4

    Run both input cases and compare the observed output with expectedOutput.

  5. 5

    Record the factsVersion and fixtureVersion with any result.

  6. 6

    Report a mismatch with the dialect, browser, input case and observed output.

What this proves—and what it does not

The fixture makes one cross-dialect semantic inspectable and traceable to repository tests. It does not prove full-language conformance, hardware timing, safety integrity or compatibility with proprietary project files.

Found a mismatch?

Send the URL, facts version, expected behavior and observed behavior. Product and documentation corrections are reviewed together.

Report a correction

Technical reference and worked-example guide

PLC scenario test-harness documentation: field reference

Direct answer

The reader can convert a behavior requirement into reproducible cases and distinguish passing code paths from passing system outcomes.

Written for learners, instructors, engineers and evaluators interpreting how initial state, timed stimuli and output or machine assertions determine a scenario result.

a controls engineer comparing a plant simulation model, physical training cell, PLC evidence and versioned test records while studying deterministic PLC scenario acceptance tests
System map / 02

NODE 01observable

Definition

Requirement, initial state, reset behavior, timed stimulus, observed tags, modeled machine state, tolerance, timeout, pass rule, diagnostics and repeatability.

NODE 02observable

Signal path

Scenario reset through program load and scans, input actions, modeled process response, assertions, failure output and retained attempt evidence.

NODE 03observable

Worked example

One normal and one stop case repeated from fresh state with identical pass results.

NODE 04observable

Limits

Stimulus before boundary, exactly at boundary, after boundary, simultaneous actions, invalid input, timeout, restart and nondeterministic state leak.

NODE 05observable

Common mistake

A requirement, reset, timing, stimulus, tag, model, tolerance, assertion, diagnostic or state-isolation mismatch.

NODE 06observable

Verification

Cases versioned with scenario behavior and replicated on target equipment where commissioning truth is required.

Answer surface / 07

What is a PLC test harness?

It is a controlled runner that establishes initial state, applies defined inputs over time and checks observable program and machine results.

Why reset before every PLC test?

A clean reset prevents retained state or a prior case from changing the outcome and makes failures reproducible.