Your PLCs still take a plane ticket

Say you run multiple plants on the same controls system. Same line, same controller, same operator screen. HQ wants to update the PLC and HMI.

Today that change travels one of two ways. An engineer gets on a plane, six times. Or the file goes out by email, someone at each plant downloads it, loads it, tests it, and calls back to say whether it took. Either way, a month later nobody can say for certain which revision each plant is actually running. The record says rev 4. Plant 4 says otherwise, because someone fixed a sensor on a Tuesday and never sent the file back.

Say that a change that lifts throughput by a few percent. This is worth nothing until it is on all of them. Every other fleet you own already solved this. Your phone, your car, your laptop all take a change from a central place, verify it landed, and tell you if it didn't. The plant floor is the last fleet still run by hand.

LGX Enterprise is that loop: multi-site controls management for Allen-Bradley ControlLogix controllers and their FactoryTalk Optix screens. For the engineers in the room, it is CI/CD for the plant floor.

What it looks like from the chair

The program lives in a git based version control repository. The HMI project lives next to it. A fleet.yaml lists your sites, how to reach each controller, and which group each site belongs to: one plant first, then a few, then the rest.

Before it touches a controller

The change is a pull request, and two checks run on it before any site is involved.

• lint checks the program file offline: duplicate outputs, unreferenced tags, the mistakes a reviewer catches on a good day.
• test runs it on a bench controller against a short script scoped to the updates.

A change that fails either check never reaches the rollout. The bench controller is the same model the plants run, so what passes there is what ships.

When the pull request merges

The rollout runs in four steps, one plant first.

1. sweep connects to every site and compares what is running against what is committed. The answer is not "file changed", it is which routine and which rungs differ at which plant.
2. plan turns that into an ordered list of rung edits per site. It refuses a site where someone else already holds pending edits, because that is a person mid-work, not drift.
3. apply pushes the edits in groups. First plant alone. Every edited rung is read back from the controller and compared to what was sent before the next group starts. A mismatch halts the rollout, puts that site back exactly as it was running, and leaves the untouched plants untouched.
4. hmi deploy sends the updated Optix project to each site and stamps the revision into the running app, so the screen and the logic arrive together.

Every step appends one line to an audit log. A wallboard reads it. The reply to HQ writes itself: six plants on rev 4, each read back, no site visits.

The guard is the product

The rollout is the easy part. What makes it safe to do from a chair is what happens when a plant disagrees.

If a plant edited its own program and nobody sent the file back, the tool says so and leaves the plant's work alone.

sweep shows the exact rungs, plan lists them as a site that differs, and apply leaves it as found unless you tell it otherwise. The tool never overwrites a plant's work to make the record look tidy.

What it is, mechanically

This is Allen-Bradley hardware, driven the way Rockwell lets you drive it. The controller side runs on the Logix Designer SDK; the screen side runs on the FactoryTalk Optix command-line deploy. No private protocol, no firmware trick, nothing a plant would have to install on the PLC.

Online edits, not downloads

apply does what a Studio 5000 engineer does by hand: pending edits, assemble, test, finalize.

The controller keeps running the whole time. Nothing is written to a controller that was not read back from it.

No model in the loop

LGX Enterprise is ordinary code calling the Logix Designer SDK through a wrapper.

The diff is a rung-text compare, the plan is that diff ordered by site group, the readback is a re-export. An engineer can drive the same tools from an AI assistant for a one-off; the rollout does not need one and does not use one.

What the bench showed

Six emulated 1756-L85E controllers, each with its own Optix runtime, on one lab VM.

• Seventeen rungs of drift spread across six sites: found, applied live, read back, six sites in sync in about twelve minutes.
• The forced halt at site 4, with 5 and 6 untouched.
• The inject, sweep, plan, apply, verify cycle run twenty times in a row overnight: twenty of twenty, no failures.
• The E-stop interlock change, with its operator screen, tested first on the bench controller (three steps, pass), then rolled to all six plants in waves.

What we are not claiming

• This is a bench. Emulated controllers are not a plant floor.
• Six sites is a fleet in shape, not in scale. The group structure is what scales; we have not yet run it at sixty.
• The HMI side is FactoryTalk Optix only, for now.

If this is your fleet

If you run twenty lines that are supposed to be identical and suspect they are not, the first useful thing is a drift report: what each plant is actually running against what the record says. That is a read-only sweep, and it is where we would start with you. Get in touch.