# 启用与健康状态

> 树的每一层里什么参与采集、那些圆点和状态文字是什么意思、全部/正常/有问题/已禁用几个筛选项、状态栏、最近错误，以及重新连接、刷新和全部刷新这几条命令。

有两个问题贯穿整个通信栏，而且每一层的回答方式都一样：什么在参与采集，以及此刻什么在应答。第一个是你用“启用”和“禁用”做出的选择；第二个是一个常开的监视器每秒观察一次、并推送到页面上每个圆点、推送到状态栏、也推送到 Logic 和仪表画面所读的那些 Connector 数值上的东西。

## 什么在参与 {#what-takes-part}

启用是按层决定的，上一层的开关从不去改写下一层的开关：

| 层级 | 命令 | 关掉之后的效果 |
| --- | --- | --- |
| 串行线路 | 线路命令栏上的“启用”/“禁用” | 总线对线上每台设备关闭；每台设备保留自己的“已启用”选择，线路重新启用时它们原样回来。线路的参数组无效时，“启用”被拒绝。 |
| Broker | Broker 命令栏或它那一行上的“启用”/“禁用” | MQTT 会话对其下每台设备关闭；每台设备保留自己的“已启用”选择，Broker 重新启用时它们原样回来。Broker 没有主机时，“启用”被拒绝。 |
| 设备 | 设备命令栏或它那一行上的“启用”/“禁用” | 与这台设备的全部通信停下，它的点位离开实时地址空间；点位保留它们自己的开关。默认是开的。 |
| 点位 | 点位命令栏或它那一行上的“启用”/“禁用” | 就这一个点位离开采集和实时地址空间。默认是开的。只写的点位不管启不启用都从不被轮询。 |

每一次“启用”和“禁用”都需要“配置 Connector”，并在有运行占住工作站或运行时已停止时置灰；同一个驱动上的一次扫描也会把线路和设备的这两条命令置灰。一台设备**在运行上算已启用**，是指它自己已启用，而且对串行线路上的设备来说它的线路、对 MQTT 来说它的 Broker 也已启用：轮询、“已禁用”筛选项和健康状态监视器看的就是这个。驱动本身没有开关：安装包带着的每一个驱动都可以选用，读什么由它下面各级决定。

## 一台设备的健康状态 {#the-health-of-a-device}

监视器从一台设备已启用、可读的那些点位推出它的健康状态：

| 健康状态 | 圆点 | 含义 |
| --- | --- | --- |
| **在线** | 绿 | 每一个已启用的可读点位上次读取都答了。OCPP 充电桩或 LoRaWAN 传感器还没发来第一个值的点位（比如第一次充电之前充电接口的 Transaction）不算在内，直到这个值到达。另外三种情况下第一个值还没到的点位也不算在内：File 驱动读取的文件还不存在时，Generic serial and TCP 驱动的监听点位还没收到过滤条件接受的第一条消息时，以及 Database 驱动的点位读取还没有任何行的表的最新一行时。第一个值从设备最近一次连接时算起：充电之后充电桩重新连接时，充电接口的 Transaction 在下一次充电之前又不算在内。设备连接以来已经有过数值的点位，即使在等待，也照常计算。 |
| **部分在线** | 琥珀 | 有的答了，有的没答。 |
| **离线** | 红 | 一个都没答。 |
| **已禁用** | 灰 | 设备被禁用了，或者它的串行线路或 Broker 被禁用了。 |
| **尚未可知** | 灰 | 没有可判的东西：一个已启用的点位都没有；或者设备还没有填写主机，工作站不会去连它；或者工作站在保存之后、或服务器启动时，正把设备重新放进正在跑的服务器，直到它有一个点位应答，或者有一个点位在轮询间隔再加 10 秒之内都没有应答；或者已经连上、但还没为任何一个点位发来数值的 LoRaWAN 传感器；或者像“在线”里说的那样，所有可读点位都还在等待第一个值的设备。 |

设备自己的圆点也和它的点位一样，不等监视器，对“启用”和“禁用”立刻响应：一按“禁用”马上显示已禁用，一按“启用”则显示尚未可知，直到监视器读到启用后的设备为止。启用或禁用它的串行线路时，设备也同样响应，它的文件夹、驱动和“驱动”文件夹的圆点也在同一刻跟着变。

OCPP 充电桩的健康状态取自它与本工作站中央系统的连接，而不是它的点位有没有动静，就像 LoRaWAN 无线集中器取自它网关的连接一样：连着的时候，不管到目前发来了什么，都是在线（它发来的点位有一部分失败时为部分在线）；自工作站打开以来一直没连上来，或者掉线之后，是离线；尚未可知只出现在工作站把它重新放入之后最多十秒内。完整的表在 [OCPP](driver-ocpp#the-charge-points-health) 里。

一台设备如果已启用的点位全是只写的，就没有读数可判，于是改取传输层的连接状态：连着时是在线，没连上时是离线，Connector 还没试过之前是尚未可知。一个带越限故障的越限值是一种过程状况，不是连接问题：它把点位的圆点变成琥珀色，但绝不会把设备算成离线。一个替代值同样让点位保持可读，而设备照旧被报告为离线。内置 OPC UA 服务器不算在这份健康状态里：它停着的时候 Connector 照样在读，每个点位都保留实时值，它自己的状态在[状态](connector-opcua-server)上。只有 Connector 根本没在跑时，每个点位才都是空档，这时状态栏写“Connector：已停止”。

## 点位的圆点 {#the-tags-dot}

点位的圆点在树里和点位页面上是同一个。工作站不读取的点位是灰色的，不管它上次显示的是什么：被禁用的点位，以及被禁用的设备、挂在已禁用线路下面的设备、还没有填写主机的设备的每个点位，所以一按“禁用”，这台设备的点位就立刻变灰。在工作站读取的点位上，数值是替代值、或者限值环节报了故障时是琥珀色的，因为一个读得出来的数字和一次测量不是一回事；读数停止更新时也是琥珀色的；点位有数值时是绿色的；其余情况是灰色的。读数停止更新，是指在点位的轮询间隔再加 10 秒之内没有新的读数到来，比如设备接受了连接之后就不再应答。这时它算作一次失败的读取：点位显示[设备没有回答](connector-value-pipeline#the-device-did-not-answer)时的策略所给出的内容，默认读作空、质量转为不可用，时刻由最后一次到达的读数的源时间戳标明，点位在设备的健康状态里算作没有应答。上次读取失败时，点位行上还带一个红色的错误标记，消息就是它的提示文字。

## 串行线路的状态 {#serial-line-states}

一条串行线路，不论属于哪个驱动，都把物理端口和它的设备分开报告，报告的地方有树里那一行、驱动的线路表，以及线路页面的标题栏：

| 状态 | 圆点 | 含义 |
| --- | --- | --- |
| **已关闭** | 灰 | 线路被禁用了。 |
| **空闲** | 灰 | 已启用，但没有已启用的设备：端口没有打开。 |
| **正在连接…** | 琥珀 | 有一台设备已启用，端口正在打开，或者在一次失败之后正在重开。 |
| **在线** | 绿 | 端口开着并在服务。 |
| **端口故障** | 红 | 端口打不开或者出了故障；原因用工作站的语言打在标题栏下面（另一个程序占用了端口、端口不存在、端口出了故障），并按操作系统的原话作为这一行错误标记的提示文字，而诊断日志把这次故障记一次、把恢复也记一次。 |

线路的概括文字还会加上它的设备在做什么：“在线 · 2/2 台设备在线”“在线 · 1 台在线 · 1 台有问题”“空闲 · 没有已启用的设备”。一条线路可以是在线的，而它上面仍有一台谁也不替它应答的设备。MQTT Broker 也以同样的方式、与设备分开报告自己的会话，它的状态见[MQTT](driver-mqtt#broker-states)。

## 圆点怎么往上汇总 {#how-the-dots-roll-up}

文件夹、串行线路、驱动和“驱动”文件夹对它们的子节点都用同一条规则：只有在线、部分在线和离线的子节点参与计数；已禁用和尚未可知是中性的，永远不会把上一级拉成琥珀色或红色。在参与计数的子节点里，全是在线就是在线，混在里面只要有在线或部分在线就是部分在线，全是离线就是离线，一个参与计数的子节点都没有就是尚未可知。文件夹汇总它里面每一台设备，含子文件夹里的；Modbus RTU 驱动汇总它的线路，Generic serial and TCP 和 SCPI instruments 驱动汇总它的线路和不在线路上的设备，MQTT 驱动汇总它的 Broker；“驱动”文件夹汇总它下面的每一个驱动。一个驱动在线、另一个驱动的设备全部已禁用，“驱动”文件夹读出来是在线，而不是琥珀色。[服务器](connector-servers)文件夹的两行不在这套汇总之内：每个圆点只说明它那台服务器的状况，从不影响“驱动”文件夹的圆点，也不影响状态栏。

## 全部 / 正常 / 有问题 / 已禁用 几个筛选项 {#the-all--ok--issues--off-chips}

树上方那几个筛选项按同样这些状态把每一行归桶：**正常**是在运行上算已启用、并且在线或还无从判断的设备或线路（还没有填写主机的设备也算在内），以及读到的测量值在限值以内的已启用点位；**有问题**是已启用但离线或部分在线的设备或线路，以及在工作站正在读取的设备上、没有数值、数值是替代值、数值超出限值或读数停止更新的已启用点位；**已禁用**是被禁用的设备、线路或点位，挂在一条已禁用线路下面的设备也算在内。点位只在它的设备被读取时才被读取：归在“已禁用”下的设备，它的每个点位都跟着它归在那里；还没有填写主机的设备，它的每个已启用点位都跟着它归在“正常”下，不管显示的是什么。没有数值、但因为第一个值还没到而不计入设备健康状态的已启用点位（见“在线”），也归在“正常”下。两台服务器按自己的状态归桶：已打开且没有失败时在**正常**下，已打开却无法启动时在**有问题**下，已关闭时在**已禁用**下。只要下面有东西通过，驱动那一行和两个文件夹就显示出来；选中的那一行永远保持可见。这些筛选项连同这一栏的其余部分在 [Connector](connector#search-and-the-state-chips) 里讲。

## 状态栏 {#the-status-bar}

窗口状态栏最左边那个 Connector 标记和那段文字，就是同一个监视器折成一行，标记像树上的圆点一样染成绿、琥珀、红或灰色：没有设备离线或部分在线时是“Connector：在线”；否则就是处境最差的那台设备，点名写出来，离线时是“Connector：Furnace 未在通信”，部分在线时是“Connector：Furnace 不稳定”；Connector 本身没在跑时是“Connector：已停止”。它只替 Connector 说话：发布这些设备的内置 OPC UA 服务器有它自己的状态，在[状态](connector-opcua-server)上，服务器停着时 Connector 照样在读。托盘图标说的是同一行。点这个指示器会打开 Connector 页面。状态栏其余部分在[窗口](app-window)里讲。

## 最近错误 {#last-error}

树的每一层都详细说明自己的错误，点名紧挨着的下一层里有错误的项目，错误来自上一层时则指向上面，每个驱动都一样。有自身错误的项目，在树的行里和列出它的每张表里，名称后面都带一个红色标记，原因就是提示文字；这个原因留在项目本身和它自己的页面上，诊断日志把每一条都完整保留。

| 层级 | 自身的错误 | 下一层 | 来自上一层的错误 |
| --- | --- | --- | --- |
| 驱动 | 安装包不包含的驱动，或这台计算机缺少的库，作为页面上的提示 | 有错误的串行线路和 Broker，然后是有错误的设备，逐个点名：“2 台设备有错误：Boiler、Chiller” | 无 |
| 串行线路、MQTT Broker | 打不开的端口，或拒绝工作站的 Broker，用工作站的语言以红色显示在标题栏下面（见下） | 有错误的设备，逐个点名 | 无 |
| 设备 | 连接不上，或连接被拒绝，以红色显示在标题栏下面和驱动设备表的**最近错误**列里；两处都用工作站的语言（见下文），整行文字是该单元格的提示文字 | 有错误的点位，逐个点名：“3 个点位有错误：C3、Opt_Int、T5”，超过三个名称的部分只计数（“+2”） | 在有错误的串行线路或 Broker 下面，设备不带标记，它的页面显示“此设备经由串行线路 Bench bus，该线路有错误。原因见线路页面。” |
| 点位 | 读取或写入失败的原因，以红色显示在标题栏下面 | 无：点位是最后一层 | 设备未连接期间，点位不带标记，它的页面显示“此点位经由设备 Furnace，该设备未连接。原因见设备页面。” |

设备自身的错误在设备重新连上时清掉，无论是在线还是部分在线：仍在失败的点位保留它自己的错误，显示在它自己的行和页面上，设备的行不再带连接错误；设备一直在线时写下的错误，要等工作站从该设备读取的每个点位都在条目写下之后收到一次读数才清掉；在线状态不计入的、还在等第一个值的点位，这里也不计入。点位的错误只要在条目写下之后收到那个点位的一次读数就立刻去掉，不管设备的健康状态变没变，这个点位也随之离开设备的名单。之后的一次读取发现点位只是在等设备连接以来的第一个值时，点位的读取错误也会去掉：充电桩在没有充电进行时重新连接，充电接口的 Transaction 会像第一次充电之前那样重新等待，不带错误。本安装包没带其驱动的设备，在那个位置改为显示“本安装包不包含该驱动。”，因为那里没有故障要查；一台等着证书的 OPC UA 设备显示“正在等待证书批准”。已启用但还没有主机的设备显示“尚未填写主机”：什么都还没试过，所以没有错误可显示，之前的主机留下的错误也会被清掉。完整的诊断日志在事件页面上。

设备、点位、串行线路或 Broker 标题栏下面的红色那一行，设备的**最近错误**单元格，以及点位页面上写入的应答，用工作站的语言说明哪里失败了，每次尝试都是如此，驱动自己写的那一行也一样；不带诊断日志那一行的开头、异常类名、操作系统的英文和工作站接下来要做的事；单元格的提示文字、树中标记的提示文字和事件页面保留整行文字：

| 失败的是什么 | 红色那一行怎么说 |
| --- | --- |
| Modbus 单元以异常应答读取 | 设备拒绝了读取，再加上**寄存器类别**列表所称的类别、设备手册印出的地址（输入寄存器 0 即 30001）和代码，代码 1 到 4、10 和 11 还附上其含义（代码 2：非法地址） |
| 端口拒绝连接 | “设备不接受端口 502 上的连接：该端口上没有服务，或者防火墙拒绝了连接。” |
| 主机响应 ping，端口没有回应 | “10.0.0.5 响应 ping，但端口 502 不响应：防火墙可能在本工作站、设备上或二者之间的网络中阻止了该端口。请允许从本工作站到 10.0.0.5 的 TCP 502。” |
| 端口和 ping 都没有回应 | “10.0.0.5 不响应，连 ping 也不响应：请检查设备是否已开机，以及其主机是否正确。同样阻止 ping 的防火墙看起来也是这样。” |
| 设备没有及时回答 | “设备没有及时回答。” |
| 主机名无法解析 | “名称 plc-7 无法解析为网络地址：请检查设备的主机。” |
| 驱动失败时没有说出自己的话 | “设备失败，未给出原因。技术细节见事件页面。” |
| Modbus 单元以异常应答写入 | 设备拒绝了写入，说法与被拒绝的读取相同 |
| 与设备的连接断开 | “与设备的连接已断开。” |
| 没有通往主机的网络路由 | “没有从本工作站通往设备的网络路由：请检查其主机以及二者之间的网络。” |
| Web 服务以成功范围之外的状态应答 | “设备以 HTTP 状态 503 应答。”，401、403 和 404 后面还附上状态的含义（401：用户名或密码未被接受） |
| 设备对读取的应答中没有值，驱动也没有说原因 | “设备对读取的应答中没有值。” |
| 设备的应答不是点位类型的值 | “设备的应答无法按点位的类型读成一个值。” |
| 另一个程序占用了串口，或者串口不存在 | “串口 COM3 正被另一个程序占用，或者 Windows 不允许工作站打开它。”或“这台计算机上没有串口 COM3：请检查端口名称，以及其适配器是否已插好。” |
| MQTT Broker 拒绝了工作站 | 它拒绝了什么，在哪里改正：“Broker 拒绝了用户名或密码：请检查“Broker 连接”卡片上的“用户名”和“密码”。” |
| 工作站拒绝了现场设备或 Broker 出示的证书 | “这台现场设备的证书（9F2C44A01B7E33D0）正在 Redfish 驱动页面的‘现场设备访问’里等待你的批准。批准之后就开始读取。”；在本工作站被阻止、超出有效期或未通过任何批准都无法替代的检查的证书也以同样方式说明 |
| Siemens CPU 拒绝了连接 | “CPU 接受了 TCP 连接，但拒绝了 S7 连接：请检查设备的“机架”和“槽位”。”；被拒绝的密码、驱动旁边缺少的 OpenSSL 库、不响应按名称访问的 CPU 也以同样方式说明 |
| 设备的读取意外停止 | “此设备的读取意外停止，因此它的标签没有值。重启程序会重新读取；技术细节见事件页面。” |
| 其他任何失败 | 驱动自己的话，说明原因 |

失败的设备命令、**重新连接**和扫描也用同样的话说明它们遇到了什么，工作站自己的拒绝（未连接的设备、尚未进入运行中配置的设备、尚未保存的命令）也是如此；代理和诊断日志保留英文行。

当设备或 MQTT Broker 的 TCP 连接打不开时，工作站会再查看一次该端口，同时 ping 该主机，诊断日志的那一行会在驱动自身的原因之后多带一句话，和原因一样是英文；红色那一行则用工作站的语言说明（见上文）。开着机、端口关闭的设备会立即拒绝，所以主机有应答而端口沉默，就说明端口在途中被过滤了：

| 工作站发现的情况 | 原因之后的那句话 |
| --- | --- |
| 主机应答 ping，端口没有任何回应 | “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.” |
| 端口和 ping 都没有应答 | “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.” |
| 端口拒绝 | “10.0.0.5 refuses connections on TCP port 502: nothing serves on that port there, or a firewall refuses it.” |

端口是设备的协议所打开的那个：大多数驱动是设备自己的端口，Siemens 是 102，Rockwell 和 Omron NJ/NX 是 44818，Beckhoff ADS 是 48898。Broker 的那句话会提到 Broker 所在的计算机，已应答并拒绝了工作站的 Broker 不会带这句话。设备没有自己的端口可查看时不会添加任何内容：串行线路、UDP、VISA、SQLite 文件或 ODBC 数据源、由 SQL Server Browser 服务定位的 SQL Server 实例、由计算机的代理服务器转发的请求。这些句子不指名任何人：无论是在这台工作站、设备上还是工厂网络上开放端口的人，读到的都是同样的话。

## 重新连接、刷新和全部刷新 {#reconnect-refresh-and-refresh-all}

| 命令 | 在哪里 | 作用 |
| --- | --- | --- |
| **重新连接** | 设备的命令栏和右键菜单 | 关掉那台设备的连接再重开一次，不碰别的设备，也什么都不重新加载。消息会等驱动回话：“已重新连接‘Furnace’。”，或者“无法重新连接‘Furnace’：”加上原因，原因的说法与设备的红色那一行相同。 |
| **刷新** | 驱动的命令栏和右键菜单 | 从数据库把配置读回来，并把整棵树重建一遍。正在跑的服务器保持原样。这一栏保持原位：这个驱动仍然选中，它的页面仍然打开，原来展开的仍然展开。“设备已刷新。” |
| **全部刷新** | “驱动”文件夹所打开的目录的命令栏 | 和“刷新”一样，“驱动”文件夹仍然选中，目录仍然打开。 |

“刷新”和“全部刷新”只读不写，所以对每个角色都画出来；“重新连接”会关掉再打开一条连接，所以没有“配置 Connector”权限的角色根本看不到它。有运行占住工作站或运行时已停止时，这三个都置灰；有扫描或配对跑着时，“重新连接”和“刷新”也置灰。在还在等地址的设备上（等的是主机、NI-DAQmx 设备、文件夹或数据库），“重新连接”也置灰，因为没有连接可以重新打开；它的悬停提示会说出驱动缺的是哪一个。一次编辑之后不需要刷新：每一次保存都会自己把改动过的设备调和进正在跑的服务器，而一台够不着的设备会在后台一直重试到它应答为止，在那之前它的点位读作空档。“重新连接”缩短的就是这个等待：它现在就去问，而不是把设备留给下一次自动尝试，并且会报告设备答没答。引起越限故障的那些限值属于[数值转换链](connector-value-pipeline)。