Skip to content
Spyke Automation Spyke Automation Spyke Docs

Semantic diffs

When you compare two versions of a program, Spyke shows the change the way an engineer thinks about it: this rung changed, this tag was added, this timer preset went from 3s to 5s. This is called a semantic diff — a comparison based on the meaning of the program, not its raw text.

This page explains why that matters and how it works.

The problem with comparing files directly

Section titled “The problem with comparing files directly”

A PLC program exported from your engineering software is not written to be read by a person. A Studio 5000 .L5X export, for example, is a large XML file. Open two exports of the same project in a normal text-comparison tool and you’ll see two kinds of noise drown out the real change:

  • Cosmetic differences. The export time, internal IDs, and the order things are written can all change between exports — even when you changed nothing in the program.
  • Scale. A one-rung edit can sit inside thousands of lines of XML. Finding it by eye is slow and easy to get wrong.

The result is a comparison that’s technically accurate but practically useless. You can’t tell at a glance what an engineer actually did.

How Spyke reads a program

Section titled “How Spyke reads a program”

Spyke solves this in two steps.

First, it understands the program. Spyke parses your export into the structures you already work with — controller, tasks, programs, routines, tags, data types, and Add-On Instructions. Ladder logic is read rung by rung. Structured Text is read as code, not as a block of characters.

Second, it stores each version in a clean, consistent form. When you save a version, Spyke writes the program out as a tidy set of small files — one per routine, one for each program’s tags, and so on — always in the same layout and the same order. Anything that changes between exports without being a real edit, like the export timestamp, is left out.

Because of this, two exports of an unchanged project produce an identical saved version. So when something does change, it stands out cleanly — and it touches only the part of the program it belongs to.

What a comparison shows

Section titled “What a comparison shows”

When you run a comparison, Spyke lines up the two versions and reports the differences in program terms. For a change to one rung, you’ll see which program and routine it’s in, which rung changed, and how — for example, that a contact was added to the rung that drives a lamp:

Program MixerProg
  Routine Main
    rung 0 changed

Spyke compares the parts of a project that engineers change, including:

  • Routines — ladder logic, rung by rung, and Structured Text, line by line.
  • Tags — controller-scoped and program-scoped, including data type and initial value.
  • Programs, tasks, and I/O modules — added, removed, or reconfigured.
  • User-defined data types (UDTs) and Add-On Instructions (AOIs).
  • Controller settings.

A note on graphical languages

Section titled “A note on graphical languages”

Spyke reads ladder logic and Structured Text in full detail. Function Block Diagram (FBD) and Sequential Function Chart (SFC) routines are still tracked — a change to one will show up as changed — but they aren’t yet broken down element by element the way ladder and Structured Text are.

Why this matters

Section titled “Why this matters”

A clear comparison changes how a change gets handled:

  • Review is fast. A reviewer sees the actual edit — one rung, one setpoint — not a wall of XML.
  • Records are meaningful. Your history reads like a list of engineering changes, not file saves.
  • Mistakes surface early. An unintended change is obvious when the comparison shows only what really moved.
Section titled “Related”