Enabling and health
What takes part in acquisition at each level of the tree, what the dots and state texts mean, the All/OK/Issues/Off chips, the status bar, Last error, and the Reconnect, Refresh and Refresh all verbs.
Two questions run through the whole Communication column, and both are answered the same way at every level: what is taking part in acquisition, and what is answering right now. The first is a choice you make with the Enable and Disable verbs; the second is what an always-on monitor observes once a second and pushes to every dot on the page, to the status bar, and to the Connector values that Logic and dashboards read.
What takes part
Enabling is decided per level, and a switch never rewrites the switch below it:
| Level | Verbs | Effect when off |
|---|---|---|
| Serial line | Enable / Disable on the line's bar | The bus closes for every device on it; each device keeps its own Enabled choice and comes back exactly as it was when the line is enabled again. Enable is refused while the line's tuple is invalid. |
| Broker | Enable / Disable on the broker's bar or its row | The MQTT session closes for every device under it; each device keeps its own Enabled choice and comes back as it was when the broker is enabled again. Enable is refused while the broker has no host. |
| Device | Enable / Disable on the device's bar or its row | All communication with the device stops and its tags leave the live address space; the tags keep their own switches. On by default. |
| Tag | Enable / Disable on the tag's bar or its row | That one tag leaves acquisition and the live address space. On by default. A Write only tag is never polled, enabled or not. |
Every Enable and Disable needs Configure connector and is greyed while a run holds the station or the runtime is stopped; a scan on the same driver greys the line and device ones too. A device is operationally enabled when it is enabled and, on a serial line, its line is, and for MQTT, its broker is: that is what polling, the Off chip and the health monitor look at. A driver has no switch of its own: every driver the package carries is offered, and the levels below it decide what it reads.
The health of a device
The monitor derives a device's health from its enabled, readable tags:
| Health | Dot | Meaning |
|---|---|---|
| Online | green | Every enabled readable tag answered its last read. A tag whose first value an OCPP charge point or a LoRaWAN sensor has not sent yet (a connector's Transaction before its first charge) is left out until that value arrives, and so is a tag whose first value has not come yet in three other cases: a file the File driver reads that does not exist yet, a listening tag of the Generic serial and TCP driver before the first message its filter accepts, and a tag of the Database driver that reads the most recent row of a table that has no row yet. The first value counts from the device's latest connection: when a charge point reconnects after a charge, its connector's Transaction is left out again until the next charge. A tag that has had a value since its device connected counts as usual, even while it waits. |
| Partly online | amber | Some answered, some did not. |
| Offline | red | None answered. |
| Disabled | grey | The device is disabled, or its serial line or broker is. |
| Not known yet | grey | Nothing to judge: no enabled tag; a device whose host is not entered yet, which the station does not try to reach; or a device the station is putting back into the running server after a save or when the server starts, until one of its tags answers or one goes its poll interval plus 10 seconds without answering; a LoRaWAN sensor that is connected and has not sent a value of any of its tags yet; or a device all of whose readable tags are still waiting for their first value, as described under Online. |
The device's own dot answers Enable and Disable at once, as its tags do, without waiting for the monitor: Disable shows Disabled straight away, and Enable shows Not known yet until the monitor has read the device switched on. Switching its serial line does the same to it, and the dots of its folder, its driver and the Drivers folder follow in the same moment.
An OCPP charge point takes its health from its connection to this station's central system rather than from the silence of its tags, as a LoRaWAN radio concentrator does from its gateway's: Online while it is connected, whatever it has sent so far (Partly online when some of the tags it sent fail), Offline when it has not connected since the station opened or after it dropped, and Not known yet only for up to ten seconds after the station put it back. OCPP has the whole table.
A device whose enabled tags are all Write only has no reading to judge and takes the transport's connection state instead: Online while connected, Offline while not, Not known yet before the Connector has tried. An out-of-range value with a limit fault is a process condition, not a connection problem: it turns the tag's dot amber but never counts the device offline. A stand-in value likewise keeps the tag readable while the device is still reported offline. The embedded OPC UA server is not part of this health: while it is stopped the Connector goes on reading and every tag keeps its live value, and its own state is on Status. Only a Connector that is not running at all leaves every tag a gap, and the status bar then says "Connector: stopped".
The tag's dot
A tag's dot reads the same in the tree and on the tag's page. A tag the station does not read is grey whatever it last showed: a disabled tag, and every tag of a device that is disabled, sits under a disabled line or has no host entered yet, so a Disable turns the device's tags grey at once. On a tag the station reads, the dot is amber when the value is a stand-in or the Limits stage raised a fault, because a readable number is not the same as a measurement, and amber when the reading went silent; green while the tag has a value; grey otherwise. A reading goes silent when no new one arrives for the tag's poll interval plus 10 seconds, as when a device accepts the connection and then stops answering. It then counts as a failed read: the tag shows what its policy for a device that did not answer presents, no value and bad quality by default, dated by the source timestamp of the last reading that landed, and it counts toward its device's health as not answering. The tag row also carries a red error marker when the last read failed, with the message as its tooltip.
Serial line states
A serial line, whatever its driver, reports the physical port separately from its devices, in the tree row, in the driver's line table and in the line page's header:
| State | Dot | Meaning |
|---|---|---|
| Off | grey | The line is disabled. |
| Idle | grey | Enabled, but no enabled device: the port is not open. |
| Connecting… | amber | A device is enabled and the port is being opened, or reopened after a failure. |
| Online | green | The port is open and serving. |
| Port failure | red | The port could not be opened or failed; why is printed under the header in the station's language (another program holds the port, the port does not exist, the port failed) and, in the operating system's words, as the row's error tooltip, and the journal records the failure once and the recovery once. |
The line's summary text adds what its devices are doing: "Online · 2/2 devices online", "Online · 1 online · 1 with issues", "Idle · no enabled devices". A line can be Online and still hold a device nothing answers for. An MQTT broker reports its session the same way, apart from its devices; its states are on MQTT.
How the dots roll up
Folders, serial lines, drivers and the Drivers folder all apply one rule to their children: only Online, Partly online and Offline children count; Disabled and Not known yet are neutral and never pull a parent amber or red. Of the counting children, all Online is Online, any Online or Partly online among others is Partly online, all Offline is Offline, and no counting child at all is Not known yet. A folder rolls up every device inside it, subfolders included; a Modbus RTU driver rolls up its lines, a Generic serial and TCP or SCPI instruments driver its lines and its devices off a line, and an MQTT driver its brokers; the Drivers folder rolls up every driver under it. With one driver Online and another whose devices are all disabled, the Drivers folder reads Online, not amber. The two rows of the Servers folder are outside this roll-up: each dot says only how its server stands, and neither moves the Drivers folder's dot or the status bar.
The All / OK / Issues / Off chips
The chips above the tree bucket every row by these same states: OK is an operationally enabled device or line that is Online or has nothing to judge yet, a device whose host is not entered yet included, and an enabled tag reading a measurement within its limits; Issues is an enabled device or line that is Offline or Partly online, and an enabled tag that has no value, a stand-in, a value outside its limits or a reading that went silent, on a device the station is reading; Off is a disabled device, line or tag, a device under a disabled line included. A tag is read only while its device is: every tag of a device that is off sits under Off with it, and every enabled tag of a device whose host is not entered yet sits under OK with it, whatever it shows. An enabled tag with no value that its device's health leaves out because its first value has not come yet (see Online) sits under OK too. The two servers are bucketed by their own state: OK while on and not failed, Issues while on but unable to start, Off while turned off. A driver row and the two folders show when something below them passes; the selected row always stays visible. The chips are described with the rest of the column on Connector.
The status bar
The Connector's mark and the text at the left of the window's status bar are the same monitor, folded to one line, the mark tinted green, amber, red or grey like a dot of the tree: "Connector: online" when no device is Offline or Partly online; otherwise the worst-off device by name, "Connector: Furnace not communicating" for Offline or "Connector: Furnace unstable" for Partly online; "Connector: stopped" while the Connector itself is not running. It speaks for the Connector alone: the embedded OPC UA server publishing the devices has its own state on Status, and the Connector reads while it is stopped. The tray icon says the same line. Clicking the indicator opens the Connector page. The rest of the status bar is on The window.
Last error
Each level of the tree says the error that is its own, names the items just below it that have one, and points up when the error comes from above, the same way under every driver. An item with an error of its own carries a red marker after its name, in its tree row and in every table that lists it, with the reason as its tooltip; that reason stays on the item and on its own page, and the journal keeps every line whole.
| Level | Its own error | The level below | An error from above |
|---|---|---|---|
| Driver | A driver the package does not carry, or a library this computer lacks, as a notice on its page | Its serial lines and brokers with an error, then its devices with an error, by name: "2 devices with errors: Boiler, Chiller" | None |
| Serial line, MQTT broker | The port that does not open, or the broker that refuses the station, in red under the header in the station's language (below) | Its devices with an error, by name | None |
| Device | It does not connect, or the connection is refused, in red under the header and in the Last error column of the driver's device table, both in the station's language (below), the cell's tooltip keeping the whole line | Its tags with an error, by name: "3 tags with errors: C3, Opt_Int, T5", the rest counted past three names ("+2") | On a serial line or a broker that has an error, the device carries no marker and its page says "This device goes through serial line Bench bus, which has an error. The line's page says why." |
| Tag | Why its read or its write failed, in red under the header | None: a tag is the last level | While its device is not connected, the tag carries no marker and its page says "This tag goes through device Furnace, which is not connected. The device's page says why." |
A device's own error clears when the device reconnects, Online or Partly online: a tag that still fails then keeps its own error on its row and page, and the device's row no longer carries the connection error; one written while the device stayed Online clears once every tag the station reads of it has had a reading arrive after the entry was written; a tag still waiting for its first value, which Online leaves out, is left out here too. A tag's goes as soon as a reading of that tag arrives after the entry was written, whether or not the device's health changed, and the tag leaves its device's list with it. A tag's read error also goes when a later read finds the tag simply waiting for its first value since its device connected: when a charge point reconnects with no charge under way, its connector's Transaction waits again, as before its first charge, with no error. A device whose driver the package does not carry shows the notice "Driver not included in this package." in that place instead, because there is no fault to investigate; an OPC UA device waiting for its certificate shows "Waiting for certificate approval". An enabled device with no host yet shows "Host not entered yet": nothing has been tried, so there is no error to show, and an error an earlier host left behind is cleared. The full journal is on the Events page.
The red line under the header of a device, a tag, a serial line or a broker, the device's Last error cell and the answer of a write on the tag's page say what failed in the station's language, without the journal's opening, the exception's class, the operating system's English or what the station does next, at every attempt, a line the driver wrote on its own included; the cell's tooltip, the tree marker's tooltip and the Events page keep the whole line:
| What failed | What the red line says |
|---|---|
| A Modbus unit answers the read with an exception | That the device refused the read, the class as the Register class list names it, the address as the device's manual prints it (input register 0 is 30001) and the code, with what it means for codes 1 to 4, 10 and 11 (code 2: an illegal address) |
| The port refuses the connection | "The device does not accept connections on port 502: nothing serves on that port, or a firewall refuses it." |
| The host answers ping, the port says nothing | "10.0.0.5 answers ping, but port 502 does not: a firewall probably blocks that port, on this station, on the device or on the network between them. Allow TCP 502 from this station to 10.0.0.5." |
| Neither the port nor the ping answers | "10.0.0.5 does not answer, not even ping: check that the device is on and that its host is right. A firewall that also blocks ping looks the same." |
| The device does not answer in time | "The device did not answer in time." |
| The host's name does not resolve | "The name plc-7 does not resolve to a network address: check the device's host." |
| The driver failed without any words of its own | "The device failed without giving a reason. The Events page keeps the technical detail." |
| A Modbus unit answers a write with an exception | That the device refused the write, said as a refused read is |
| The connection to the device breaks | "The connection to the device was lost." |
| No network route leads to the host | "No network route leads from this station to the device: check its host and the network in between." |
| A web service answers with a status outside the success range | "The device answered with HTTP status 503.", with what the status means after it for 401, 403 and 404 (401: the user name or the password was not accepted) |
| The device answers a read without a value, and its driver says nothing about why | "The device answered the read without a value." |
| The device's answer is not a value of the tag's type | "The device's answer does not read as a value of the tag's type." |
| Another program holds the serial port, or the port does not exist | "The serial port COM3 is in use by another program, or Windows does not let the station open it." or "The serial port COM3 does not exist on this computer: check the port's name and that its adapter is plugged in." |
| The MQTT broker refuses the station | What it refused and where that is corrected: "The broker refused the user name or the password: check Username and Password on the Broker connection card." |
| The station refuses the certificate the equipment or the broker presents | "This equipment's certificate (9F2C44A01B7E33D0) is waiting for your approval under Equipment access on the Redfish driver's page. Reading starts once you approve it.", and the same way a certificate blocked at this station, outside its validity dates or failing a check no approval stands in for |
| A Siemens CPU turns the connection away | "The CPU took the TCP connection and refused the S7 connection: check the device's Rack and Slot.", and the same way a refused password, the OpenSSL libraries missing beside the driver or a CPU that does not answer the access by name |
| Reading the device stopped unexpectedly | "Reading this device stopped unexpectedly, so its tags have no value. Restarting the program reads it again; the Events page keeps the technical detail." |
| Any other failure | The driver's own words, which say why |
A device command, a Reconnect and a scan that fail say what they met in the same words, and so do the station's own refusals of them (a device that is not connected, a device not yet in the running configuration, a command not saved yet); the agent and the journal keep the English line.
When the TCP connection of a device, or of an MQTT broker, does not open, the station looks at the port a second time and pings the host at the same time, and the journal line carries one more sentence after the driver's own cause, in English like the cause, which the red line says in the station's language (above). Equipment that is on with its port closed refuses at once, so a port that stays silent while its host answers is filtered on the way:
| What the station finds | The sentence after the cause |
|---|---|
| The host answers ping, the port says nothing | "10.0.0.5 answers ping, but TCP port 502 does not: a firewall probably blocks that port, on this station, on the device or on the network between them. Allow TCP 502 from this station to 10.0.0.5." |
| Neither the port nor the ping answers | "10.0.0.5 does not answer ping either: check that the device is on and that the address is right. A firewall that also blocks ping looks the same." |
| The port refuses | "10.0.0.5 refuses connections on TCP port 502: nothing serves on that port there, or a firewall refuses it." |
The port is the one the device's protocol opens: the device's own port for most drivers, 102 for Siemens, 44818 for Rockwell and an Omron NJ/NX, 48898 for Beckhoff ADS. A broker's sentence names the broker's computer, and a broker that answered and refused the station gets none. Nothing is added where the device has no port of its own to look at: a serial line, UDP, VISA, a SQLite file or an ODBC source, a SQL Server instance the SQL Server Browser service locates, a request the computer's proxy carries. The sentences name no one: whoever opens the port, on this station, on the equipment or on the plant's network, reads the same words.
Reconnect, Refresh and Refresh all
| Command | Where | What it does |
|---|---|---|
| Reconnect | A device's bar and right-click menu | Closes that device's connection and opens it again, touching no other device and reloading nothing. The message waits for the driver: "Reconnected 'Furnace'.", or "Couldn't reconnect 'Furnace':" with the cause as the device's red line says it. |
| Refresh | A driver's bar and right-click menu | Reads the configuration back from the database and rebuilds the whole tree. The running server is left as it is. The column keeps its place: the driver stays selected with its page open, and what was expanded stays expanded. "Devices refreshed." |
| Refresh all | The bar of the Drivers folder's catalog | The same as Refresh, with the Drivers folder staying selected and the catalog open. |
Refresh and Refresh all only read, so they are drawn for every role; Reconnect closes and reopens a connection, so a role without Configure connector is not drawn it at all. All three grey while a run holds the station or the runtime is stopped, and Reconnect and Refresh also grey while a scan or a pairing runs. Reconnect also greys on a device still waiting for its address (its host, its NI-DAQmx device, its folder or its database), which has no connection to reopen; its tooltip names the one its driver is missing. Neither refresh is needed after an edit: every save reconciles the changed device into the running server by itself, and an unreachable device is retried in the background until it answers, its tags reading as gaps until then. Reconnect is what shortens that wait: it asks now instead of leaving the device to the next automatic attempt, and it reports whether the device answered. The limits that raise a limit fault are part of the value pipeline.