Appearance
The Scan Cycle
Last updated
License feature: Ladder LogicUnderstanding exactly what happens in a scan avoids most surprises.
One scan
- Read inputs. For every Device Tag used by an enabled rung (or SFC transition or action) in a scheduled program, the engine copies the tag's current value in Scada.Ink into an input image. It does not poll the device: the value is whatever the driver last delivered. Tag quality is ignored — if a device drops offline, the logic keeps seeing the last value.
- Solve logic. For each scheduled program, in creation order, run its Main routine:
- Rungs run top to bottom; disabled rungs are skipped.
- On each rung, elements run left to right. Every element on the rung is evaluated even after power has gone false (so timers reset and one-shots see every edge).
- A JSR calls the routine after its rung has been evaluated; the scan then continues with the next rung.
- Task Tags and Program Tags change the moment an element writes them, so a later rung in the same scan sees the new value.
- Writes to Device Tags are collected in an output image. A device tag read later in the same scan still has its start-of-scan value. If several elements write the same device tag, the last one wins.
- Write outputs. Every device tag written this scan is sent where it belongs — but only when its value has changed — see Tags and Addresses.
- The scan time is recorded, and at most every 250 ms the live state is sent to editors in Monitor mode.
Scan modes
| Mode | Behavior |
|---|---|
| Periodic | A scan starts every Period (ms) (minimum 10). If a scan takes longer than the period, the next one simply starts late — scans never overlap, and nothing reports an overrun |
| Continuous | The next scan starts as soon as the previous one finishes (about 1 ms later). The task uses as much CPU as it can get |
Everything shares one thread
The scan engine runs inside the Scada.Ink server process, on the same thread as the web API, workflows, scripts and the tag engine. So:
- a slow scan delays web pages, API calls and other tasks;
- a logic loop that never ends — for example a JMP back to an earlier LBL whose rung stays true — is caught by a 1-second watchdog: the scan is cut off, the task faults and stops, and everything else on the appliance keeps running. Fix the loop and start the task again;
- tasks don't pre-empt each other; each scans on its own timer.
Scan time
The status bar shows Last (the latest scan), Avg (the last 100 scans), Max (the longest since the service started) and the scan count. The task card's Scan: … ms avg shows the same average.
Typical figures on the appliance: a few dozen rungs of contacts, compares and math solve in well under a millisecond. The cost that matters is output writes.
Every output is solved on every scan, but a device tag or Local Tags tag is only sent when its value changes (a real device is also written again if it still reads differently two seconds later — see Tags and Addresses). So a coil that holds steady costs nothing; one that flickers costs a lot. Each write to a Local Tags tag updates the database, notifies every open dashboard, fires any workflow or script that watches the tag, and, if history is on, stores a history point.
Warning: A value that changes on most scans — a free-running counter, a timer accumulator copied out with a MOV, a bit that toggles every scan — is written on most scans. In a 100 ms task that is ten database writes a second per tag, and a Tag Change workflow on it runs ten times a second.
To keep a task light:
- Use Task Tags or Program Tags (
B_Run,N7:0) for internal bits and values. They cost nothing to write. - Publish to Local Tags only the few values a dashboard needs, and where possible from a rung that runs only on a change (an OSR in front of a MOV).
- Don't turn on history for tags whose value changes on most scans.
- Use a period of 100–500 ms.
Timing accuracy
Timers measure real elapsed time between scans, so a TON with Preset (ms) 5000 in a 100 ms task finishes between 5000 and about 5100 ms after its rung went true — later if the appliance is busy. Don't use ladder timers for anything that needs better than roughly one scan period of accuracy.