Companion post for the week-7 video. The video covers the same ground on screen in about four minutes: watch it here.

I work on a system of about sixty Allen-Bradley PLCs at remote sites, and I wanted to see what their logic would look like as Nautilus controllers. Before I could do that, I had to read all sixty programs: the routines, the add-on instructions, the tags, and the setpoints each site had been commissioned with.

An ACD file can't be read

A Studio 5000 project is an .ACD file, and it's binary. file calls it "data". The first few lines of hex include the text "generated by the RSLogix 5000 software… DO NOT ALTER THIS FILE", and nothing after that is readable.

Studio 5000 can save any project as an .L5X, which is Rockwell's XML export. That's the format I needed. But doing it by hand is sixty rounds of opening a project, clicking Save As, picking L5X, and waiting.

One command, with Rockwell's SDK doing the work

Rockwell publishes an SDK for Logix Designer. It runs as a service on Windows, beside a licensed Logix Designer install, and two of its calls do this job: open the project, then save it as L5X.

Nautilus wraps that in one command, naut logix convert. It runs on my Linux workstation and sends the ACD to logixd, a small agent on the Windows machine that drives the SDK, then brings the L5X back. So the conversion is a command I can script like any other.

naut logix convert DemoLine.ACD DemoLine.L5X

One conversion takes about thirteen seconds. The SDK reports each step (open started, open succeeded, save started, save succeeded), and the L5X lands next to the ACD.

The L5X is plain text

Opened in VS Code, the L5X is readable XML: the main routine with the pump's seal-in rung and its comment, the high-level alarm rung, and the tag block with every tag's data type and value. That's something I can parse, diff, search, or hand to an AI agent with a question.

The whole folder in one pass

A loop over the folder runs the same command for every project, one line per file. When it finishes, every ACD has an L5X beside it. In the video this part is sped up; in real time it's a coffee break, not an afternoon of clicking.

for f in plant/*.ACD; do naut logix convert "$f" "${f%.ACD}.L5X"; done

One table for the whole fleet

Once everything is text, a short Python script reads each L5X and prints one row per controller: the processor, the add-on instructions, routines, rungs, tags, and the value of a setpoint. A second mode rolls all sixty up into a fleet summary: how many distinct add-on instruction libraries there are, and how a setpoint varies from site to site.

The roll-up answered my question. Every controller used the same library of about sixteen add-on instructions. So moving it to Nautilus would be sixteen blocks, plus some glue code per site, not sixty separate programs.

The same project, live over EtherNet/IP

Converting the files reads the program. The last part of the video watches it run.

The DemoLine project is downloaded to FactoryTalk Logix Echo, Rockwell's emulator, which runs real ControlLogix firmware in a virtual machine. On my Linux machine, naut logix serve connects to it over EtherNet/IP, the same driver Nautilus uses for any Allen-Bradley PLC, and serves its tags to VS Code. Open the L5X and the rungs show live values.

naut logix serve --host <controller> --l5x DemoLine.L5X

DemoLine has no real I/O, so a small simulator plays the tank: the level rises while the pump runs and falls when it stops. From the editor I press the start button, and the seal-in rung holds the pump on. The level climbs past the 85 % setpoint and the high-level alarm rung lights. I press stop and the pump drops out. Every value I set is read back from the controller on the next poll, so what's on screen is what the controller has.

There's no Studio 5000 on the Linux side, no licence, and no Windows. That's what EtherNet/IP looks like in Nautilus.

The second video: we tested our tests

This week I also published a video on how we test Nautilus itself: watch it here. The docs said 533 features of the runtime were verified by a test. We audited 40 of them at random, and for 16 the test passed without proving the claim. That happened three ways: the second half of an "and" was never tested (the page promised DIV and MOD, the test checked DIV); tests that pass with the feature broken (a retained-values test used a program that overwrote the loaded value every scan, so it could never see a wrong load); and tests that checked something other than what the page claimed.

The fix was one more layer: test the tests, by running each one against code that should fail. A test that still passes isn't proving anything. Checked that way, 533 verified dropped to 343. Since then we've worked back up to 644 verified, 271 partly covered, and 61 with no test yet, and all of it is public. nautilus.joyautomation.com/verified lists every claim, the test that covers it, and the result from the last CI run on main. The 61 are the to-do list, in the open.

We test the VS Code editor the same way, and record it. Almost everything in the editor is a gesture, so the tests run a real copy of VS Code with the extension in a throwaway Incus container on a virtual screen. xdotool moves the mouse and types, the Chrome DevTools Protocol reports where each element is on screen, and every test saves the file and reads it back to check that the edit landed. ffmpeg records the screen the whole time. The suite runs every night at full speed, and once a week at human speed so the clips are watchable; the docs embed the last weekly run that passed. 178 of the editor's 188 features have a recording like that today, and the other 10 are listed as "no evidence yet". I wrote about the audit on LinkedIn, and about the recording rig here.

Also this week

We added a 3D scene editor to the VS Code extension, on main for the next release: a .scene.json file opens as a 3D view, equipment drops in from a palette, a gizmo drags it into place, and every gesture is one text edit, so a scene diffs like the rest of the project. The lift-station example is rendered in 3D now from six glTF kinds, hmi-3d 0.2.2 has a paper look that draws a scene as an isometric line drawing, and the HMI kit 0.8.0 has an AlarmSign component, one shape per priority.

What's next

Next week I'm monitoring a server rack with a PLC runtime, in 3D. And this video is the first half of an Allen-Bradley thread: next month I program this same controller from VS Code and never open Studio 5000.

If you have a fleet of Logix controllers and want to know what's actually in them before you decide what to do next, start with a Control System Assessment: a fixed-price review that ends in a written report you keep either way.

Nautilus docs: nautilus.joyautomation.com · Repo: github.com/joyautomation/nautilus

Subscribe to the weekly newsletter to keep up to date: joyautomation.com/newsletter