Skip to content
nautilus nautilus nautilus

Verified: Coming from Studio 5000

Each claim the Coming from Studio 5000 page makes, with the tests that prove it in the last green CI run: 8 of 20 verified, 2 with no test yet. The claims live in docs/claims/studio-5000.yaml.

Last green CI run 16 Oct 2026, 14:48 UTC on c7618d3 · all runtime claims

C5K-001 partly verified

A set coil `( S Tag )` latches the tag and a reset coil `( R Tag )` unlatches it, as `OTL` and `OTU` do; the latch holds after the rung goes false.

where the docs say so · The plain XIC/XIO contact and OTE coil have no dedicated test here; they are exercised by every ladder example and the seal-in rungs.

  • pass TestConformance/ld-coils/S coil latches, R coil unlatches, R wins a same-scan tie in lang/conformance

C5K-002 verified

A pulse coil `( P Tag )` is TRUE for exactly one scan when the rung condition rises, and `( N Tag )` for exactly one scan when it falls (`OSR`/`OSF` as output instructions).

where the docs say so

  • pass TestConformance/ld-coils/P coil is TRUE for exactly one scan on the rising edge in lang/conformance
  • pass TestConformance/ld-coils/N coil is TRUE for exactly one scan on the falling edge in lang/conformance
  • pass TestConformance/ld-coils/first scan with A already TRUE counts as a rising edge in lang/conformance

C5K-003 partly verified

An edge contact `+Tag` passes power for one scan on the rise and `-Tag` for one scan on the fall, standing in for `ONS` at a position in the rung, with no storage bit to declare.

where the docs say so · The page also says the generated edge state stays stable across unrelated edits; only the name derivation (rung and reference) is tested.

  • pass TestConformance/ld-coils/+ contact passes one scan on the rise, - contact one scan on the fall in lang/conformance
  • pass TestEdgeTrigNamesMatchTheCompiler in lang/ld

C5K-004 partly verified

Branches `[ a | b ]` are parallel legs, nested to any depth.

where the docs say so · Two levels of nesting are tested; "any depth" is not.

  • pass TestConformance/ld-coils/nested branch, bare leg passes at once in lang/conformance
  • pass TestConformance/ld-coils/nested branch, FB leg is Q false at PT-1ms, true at PT, drop resets in lang/conformance

C5K-005 verified

`t:TON(PT := T#5S)` stands in for `TON t PRE 5000`: `t.Q` is the `.DN` bit, TRUE once PT has elapsed, and `t.ET` is the `.ACC`, a `TIME`.

where the docs say so

  • pass TestConformance/fb-ton/Q false at PT-1ms, true at PT, ET clamps at PT in lang/conformance

C5K-006 verified

`t:TOF(PT := T#5S)` keeps `Q` TRUE for PT after `IN` drops.

where the docs say so

  • pass TestConformance/fb-tof/Q holds for PT after IN falls, drops at PT, ET clamps at PT in lang/conformance

C5K-007 partly verified

`c:CTU(PV := 10, R := ResetC)` counts rising edges of the rung power (a held input counts once), `c.Q` goes TRUE at PV and the `R` pin resets it.

where the docs say so · Counting and Q at PV are covered in ladder; the reset behaviour is only checked in ST, and `c.CV` as `.ACC` is read through the same pin.

  • pass TestConformance/ld-coils/FB-only rung (no coil) still runs, its outputs read elsewhere in lang/conformance
  • pass TestFBCTUCountsAndResets in lang/st

C5K-008 partly verified

`CTD` is the IEC block: it counts down from `PV` loaded by `LD`, and `Q` means `CV <= 0`; this differs from a Logix CTD.

where the docs say so · LD loading PV, counting down and Q at CV = 0 are asserted; Q while CV is below 0 (counting past zero) is not, so a Q that tested CV = 0 would also pass.

  • pass TestConformance/fb-ctd/LD loads PV into CV and clears Q in lang/conformance
  • pass TestConformance/fb-ctd/before any load CV is 0 and Q is already TRUE (CV <= 0) in lang/conformance
  • pass TestConformance/fb-ctd/counts down one per rising CD edge and Q rises when CV reaches 0 in lang/conformance

C5K-009 partly verified

With `dialect: logix`, `t:TONR(PT := T#5S, Reset := Clear)` clears `ET` and `Q` while `Reset` is TRUE, the stand-in for `RES` on a timer.

where the docs say so · Only the Logix writer's translation is tested. No test runs a TONR on the nautilus runtime.

C5K-010 partly verified

Compare functions are contacts: `EQ(A, B)` `NE` `GT` `GE` `LT` `LE`, with `/EQ(A, B)` passing power when the comparison is FALSE, and an arithmetic expression is allowed inside the comparison, as in `GE(ADD(Base, Bias), Limit)`.

where the docs say so · The negated contact runs in conformance; expression arguments are only checked as transpiled text. The remaining compare functions are not each run.

  • pass TestConformance/ld-coils/negated function contact passes power when the call returns FALSE in lang/conformance
  • pass TestFunctionContactExpressionArgs in lang/ld

C5K-011 partly verified

The assignment element `{ Dest := Expr }` assigns while the rung has power at that point and passes power through; it takes any IEC expression evaluated every scan (`MOV`, `CPT`, `ADD`, `SUB`, `MUL`, `DIV`, `MOD`, `NEG`, `ABS`).

where the docs say so · Checked as the generated netlist (SEL on the rung power) and that it compiles; no test scans a rung and reads the assigned tag.

  • pass TestAssignmentElement in lang/ld

C5K-012 verified

`Status.3` on an integer tag is a BOOL, readable and assignable, with bit 0 least significant.

where the docs say so

  • pass TestConformance/st-partial-access/a bit and a byte of a word read as BOOL and BYTE in lang/conformance
  • pass TestBitAccessInLadder in lang/ld
  • pass TestBitAccess in lang/st

C5K-013 partly verified

A block called in a rung takes rung power on its input pin and passes it on from its output pin, keeps its own state per instance (two instances of one block share nothing), and its pins are readable anywhere as contacts or operands (`m101.Pin`).

where the docs say so · State retention per instance is tested for one instance; two simultaneous instances are not.

  • pass TestLadderFunctionBlockRuns in lang/ld
  • pass TestLadderFunctionBlockPowerPins in lang/ld

C5K-014 verified

A manifest tag is in scope in every program without a declaration, as a Logix controller-scope tag is in every routine; `VAR_EXTERNAL` stays legal and must agree with the tag's `type:`.

where the docs say so

C5K-015 verified

A function block does not see manifest tags implicitly: like an AOI it takes what it needs as parameters or names a tag in its own `VAR_EXTERNAL`.

where the docs say so

C5K-016 verified

A tag's `type:` takes `BOOL`, `DINT`, `REAL`, `TIME`, a UDT or an `ARRAY`.

where the docs say so

C5K-017 partly verified

A tag's `alias:` field (with `dialect: logix`) is the rack-point alias and is written as a Logix alias tag.

where the docs say so · The writer is tested with an alias map passed to it directly, and the importer writes `alias:` into the manifest; a manifest `alias:` reaching the writer is not exercised.

C5K-018 no test yet

`JMP`/`LBL` and `MCR` are not supported: they are declined rather than approximated.

where the docs say so · No test asserts that these instructions are refused or what the diagnostic says.

C5K-019 no test yet

The MCR replacement works: rungs in a `FUNCTION_BLOCK` with an `Enable` input and `[ Start | Run ] /Stop Enable ( Run )` leave every output dead while `Enable` is FALSE.

where the docs say so · The pattern is documented but no test builds and scans it.

C5K-020 verified

A Rockwell `.L5X` export opens as ladder with no Studio 5000 installed.

where the docs say so

  • pass TestLogixGraphEmitsTheLadderModel in cmd/naut
  • pass TestLadderContactsAndCoils in lang/l5x