Nobody sells a product they cannot learn

Work through it in order. One: is the SCADA Runtime Windows service running? Field polling is done by that process, not the API, so no connection is attempted while it is stopped. Two: is the connection record enabled? A disabled connection is never attempted and simply shows as Disconnected. Three: is the state Disconnected or Error? Disconnected usually means reachability — wrong IP, closed port, firewall. Error means the device answered and refused at protocol level: wrong unit id, wrong rack/slot, failed authentication. Four: build a second connection with the Simulation protocol. If Simulation runs and the real one does not, the problem is between the network and the device, not in the configuration.

A connected link does not mean the address is right. One: check the tag type — Calculated and Scheduler tags are never polled from the field, and a Calculated tag with a broken expression stays empty. Two: does the address match the register area? Reading a coil address out of the holding register area does not raise an error, it just returns meaningless data. Three: does the data type match the device layout? Word order on 32-bit values is the most common mistake, and it shows up as a number that is wildly too large or too small. Four: the deadband. Set wider than the real range of movement, the value is read but never published, and the screen sits on its first reading. If in doubt, zero the deadband and retry.

One: is the alarm enabled? Two: the threshold is compared against the engineering value, not the raw register. If you defined Scale and Offset, the threshold has to be written in the same unit — a threshold written against raw counts is the hardest alarm fault to spot. Three: the on-delay. If the value crosses the threshold but stays above it for less than the delay, the alarm is never born; watch the live value and count the seconds it holds. Four: hysteresis. It separates the clearing threshold from the raising one, so an oversized hysteresis delays seeing the alarm clear rather than raise — which people report as "the alarm will not go away".

Live monitoring and the historian are separate paths; one can run while the other is off. One: is history logging enabled on the tag? Important: after the upgrade that introduced this field, existing tags may have had logging silently turned off; this is the first place to check post-upgrade. Two: the logging interval is independent of the poll interval — the field can be read once a second while history is kept once a minute, so a short time window may legitimately contain no points. Three: the query range and the server clock. Four: TimescaleDB compression ships disabled; that costs no data, it only makes long-range queries slower.

This is almost always the live channel rather than the data source. A screen fetches its opening values over REST and then receives updates over a WebSocket. If refreshing the page updates the value once and then it freezes again, the channel is not being established. A reverse proxy or firewall may be blocking the WebSocket upgrade, and the browser console will show the connection error. If the operator interface and the API sit on different hostnames, make sure they share the same root domain.

A fresh install has an empty configuration; this is not a fault. There are two ways forward: walk the getting-started path above and build the first connection by hand, or import a configuration bundle if you have one. Our demo installation carries a flour mill configuration that loads through the same JSON import endpoint.