Eyetory

In development

An independent check for PLC code, before it reaches the machine.

A PLC compiler tells you that the code builds. It does not tell you what the machine will do when a sensor is late or a valve is slow. Eyetory is a checker we are building for IEC 61131-3 Structured Text: you will save an ST file, and it will read the code with the machine’s I/O list and answer green, amber or red, naming the possible hazard and the actuator timing under which it appears. It is meant to check code, not write it.

01 / Illustration

Transfer.st Illustration
  1. PROGRAM Transfer
  2. VAR
  3. Step : INT := 0;
  4. StartReq : BOOL; (* part at infeed *)
  5. PartAtEnd : BOOL; (* outfeed sensor *)
  6. Conveyor : BOOL; (* belt motor *)
  7. tTransfer : TON;
  8. END_VAR
  10. tTransfer(IN := (Step = 10), PT := T#4S);
  12. CASE Step OF
  13. 0: Conveyor := FALSE;
  14. IF StartReq THEN
  15. Step := 10;
  16. END_IF;
  17. 10: Conveyor := TRUE;
  18. IF tTransfer.Q THEN Amber
  19. Step := 20;
  20. END_IF;
  21. 20: Conveyor := FALSE;
  22. Step := 0;
  23. END_CASE;
  24. END_PROGRAM

Finding on line 18

Verdict
Amber
Hazard class
Step advanced by a timer without sensor confirmation.
Line 18
Step 10 moves to step 20 when tTransfer reaches 4 s, whether or not the part has arrived.
Timing
Appears when the transfer takes longer than T#4S, for example a slipping belt or a heavy part: the belt stops with the part short of the outfeed, and the sequence carries on as if it had arrived.
I/O list
PartAtEnd is listed as the outfeed sensor and is never read.
Illustration. Example code written for this page, with the kind of finding Eyetory is being built to give. It is not output from a running checker, and the 4 s value belongs to the example, not to any measurement.

02 / What it checks

Six questions about timing and state

The questions Eyetory is being designed to ask of each program, in plain words:

  1. Two commands in conflict in the same scan

    Two parts of the program drive one actuator, or two opposed actuators, against each other within a single scan cycle.

  2. A step advanced by a timer alone

    A sequence step moves on when a timer expires, without a sensor confirming that the movement actually finished.

  3. An interlock that drops with its sensor

    An interlock is bypassed when the sensor it depends on drops out, so the guarded output can switch without it.

  4. State lost after an E-stop reset

    After an emergency-stop reset, a sequence restarts from the wrong step or with outputs it should not have.

  5. A timer called twice per scan

    One TON or TOF instance is called twice in a scan, so its elapsed time and output stop meaning what the code assumes.

  6. Two sequences waiting on each other

    Two sequences each hold a shared resource the other needs, such as a transfer table or a pump, and neither can move.

03 / Why independent

Separate from the tools that wrote the code

Any source
Planned to read Structured Text from any vendor’s tools and from any AI assistant. AI assistants now write PLC code too.
Offline
Planned to run on the engineer’s own PC, so the code does not have to leave it.
Timing
A compiler checks that code builds. Eyetory is meant to ask what happens while actuators take their time: a late sensor, a slow valve, a belt that slips.

04 / Status

Early, and nothing measured yet

Eyetory is in development. We have no results of our own to show, so this page shows none. The first step is our own measurement on PLCWorld, a public benchmark for PLC programming published by its authors. PLCWorld is cited as a planned benchmark, not as endorsement of Eyetory.

We will publish the results here when they exist, including the cases where other approaches do better.

05 / Early access

Early access

Want details about Eyetory? Leave your email to request a personal reply. This does not add you to a mailing list.