Eyetory

In development

How it is meant to work

This page describes the design of a product we are building. None of it is released yet.

01 / The check

From save to verdict, as planned

  1. You save an ST file

    The check is planned to start when you save, in the editor you already use, with the code staying on your PC.

  2. It reads the code and the I/O list

    The I/O list tells it which variables are sensors and which drive actuators, so it knows what the program can observe and what it moves.

  3. It tries actuator timings

    It simulates the plant around the program: sensors that report late, valves and cylinders that move slowly, signals that drop out for a scan.

  4. It gives a verdict on the exact line

    Green, amber or red, with the hazard class, the line and one sentence on the timing condition under which the problem appears.

02 / Timing

Why timing matters

In the example on the home page, the conveyor step ends when a 4 s timer runs out. On the bench the part arrives in time and the code looks right. With a slipping belt it does not, and the sequence moves on anyway. A compiler has no reason to complain; the problem only exists in time.

Transfer.st, signals over time Illustration
Timing of the Transfer.st illustrationStep 10 and the conveyor start at 0.5 seconds. The 4 second timer output goes TRUE at 4.5 seconds, the step advances and the conveyor stops. The outfeed sensor PartAtEnd stays FALSE throughout: the part never reached it.0 s1 s2 s3 s4 s5 s6 sStep = 10tTransfer.QConveyorPartAtEndstep advances,part not at outfeed
Illustration. The same example over time. The timer ends step 10 at 4.5 s and stops the belt; PartAtEnd never goes TRUE. All times are invented for the example.

03 / Verdicts

What the three verdicts are meant to say

Green
None of the questions produced a finding under the timings tried. It is not a statement that the code is free of hazards.
Amber
The check found a possible hazard under some actuator timings, such as a late sensor or a slow valve. The finding names the timing.
Red
The check found a possible hazard under ordinary timing, with no delay or fault needed.

04 / Learning

To be trained on a simulator, not on customer code

The plan is to train Eyetory on labelled examples produced by a plant simulator, not on customer code.

05 / Planned forms

Where it is planned to run

VS Code extension
Planned Checks on save, with the finding shown against the line.
CODESYS Store package
Planned For engineers who work in CODESYS.
Git pre-commit check
Planned Runs before code is committed, and in CI.
Offline engine for Windows
Planned For PCs that are not connected to the internet.
API
Planned For teams that want to call the check from their own tools.

Product and store names describe planned use; no endorsement is implied. Third-party names belong to their respective owners.

06 / Not in scope

What it does not do

  • It does not write or repair code. It reads code and reports.
  • It does not connect to a PLC or to the machine.
  • It does not rate code for safety, and it is not a safety function.
  • It does not replace functional-safety validation, risk assessment or commissioning.
  • It does not prove that code is free of hazards; it can miss some and flag harmless code.

See Limits for the full list.

07 / 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.