Team PLC projects: review and approve control logic together, in the browser

Control logic is written by one person and trusted by many — the integrator who drafts it, the senior engineer who signs it, the customer who runs it, the tech who inherits it. Yet the tooling has always been single-player: a project file on one laptop, emailed as conveyor_v3_FINAL_rev2.zip, reviewed by screenshot if reviewed at all. PLC-Ladder now supports team projects: invite colleagues into a project as owner, editor or viewer, and the draft–review–approve loop that already existed for one engineer becomes one a team shares.

Three roles, one honest question

The roles are deliberately plain. An owner runs the project and its membership. An editor works on the logic. A viewer sees everything — program, assumptions, simulation — and changes nothing.

The honest question is why a viewer role matters in PLC work, and the answer is that most of the people who need to understand control logic shouldn't be editing it. The customer's process engineer who must confirm "stop during dwell holds the part" behaves as agreed; the senior engineer reviewing before FAT; the apprentice learning how the machine thinks — all of them today either get a PDF of rungs or a laptop handed across a desk. A viewer link replaces both: the live program as ladder and FBD, the assumptions list, and the running simulation, readable from any browser, editable by nobody who shouldn't.

Review built on things reviewers can see

Team sharing is only as useful as what there is to look at, and this is where the existing workflow pays off twice:

• Drafts arrive with their assumptions written down. When an editor generates or changes logic, the review card shows the before/after diff and every assumption made — "sensor treated as rising edge", "added E-Stop, not in your request". A reviewer argues with a list, not an inference.
• Requirements are tests the whole team owns. Scenario tests re-run on every change, and a draft that breaks one is held back. "Does it still meet requirement 4?" stops being a question for the author's memory.
• The simulation is common ground. Instead of "it works on my machine," anyone with access runs the same scan cycle — or watches the same 2D machine scene — and flips the same fault switches. Disagreements get settled by running the case, in front of everyone.

One mechanical detail worth knowing: AI requests in a team project draw on the team's credits, not each member's personal balance — so the project carries its own budget, and nobody burns personal credits polishing shared work. Compiling and simulating remain free and unlimited.

Who this is actually for

Integrators get the pre-FAT loop they already run by email, minus the email: editor drafts, senior reviews the diff and assumptions, customer's engineer views the behaviour and the scenario tests before anyone travels. OEM machine builders get one shared home for standard device logic — the valve blocks and motor patterns every machine reuses — where the approved version is the visible one, not the newest attachment. Mentors and juniors get the shortest feedback loop there is: the junior builds, the senior opens the same project and comments against the actual running logic rather than a screenshot of it.

What team projects are not: a replacement for your vendor IDE's source control at deployment time, or for the sign-off process your company already requires — a qualified engineer still approves and validates logic for the actual equipment, and a shared browser project doesn't change whose name is on that approval. It changes how much everyone has seen before the name goes on.

The quickest way to feel the difference: open a project you're working on, invite the colleague who would normally get the screenshot — as viewer costs them nothing — and ask them to read the assumptions list cold. The first "wait, why is the sensor a rising edge?" you get back is the review that used to happen at FAT, happening in a browser tab instead. Start at plcladder.com.