modbus协议 青鸟

工作需要，不得不搞一下.net项目。以前是做java的，还是有不少差异。

先找到两者之间的差异，就好办了。

modbus基础

Modbus 是一种工业通信协议，核心是主从（Master-Slave）架构：

• 主站（Master）：主动发起请求的设备，比如电脑上的 Modbus Poll、HMI 触摸屏或上位机软件。
• 从站（Slave）：被动响应的设备，比如 PLC、传感器、变频器、仪表等。

主站发出请求，从站根据请求返回数据或执行操作，从站之间不会主动通信。这种模式让协议逻辑简单、易于实现，对硬件资源要求也很低。

通信方式

Modbus 最初基于串行链路，后来又扩展到以太网，常见的有三种变体：

• Modbus RTU：最常用的串行版本，采用二进制编码，传输效率高，通常跑在 RS-485 或 RS-232 上。

• Modbus ASCII：串行版本，用可读的 ASCII 字符传输，效率较低，但便于人工调试。

• Modbus TCP/IP：跑在以太网上，把 Modbus 报文封装在 TCP 包中，速度更快，适合现代工业网络。

数据模型

Modbus 把设备中的数据抽象成四种区域，用地址来区分：

• 线圈（Coils）：可读可写的开关量，比如控制继电器通断。
• 离散输入（Discrete Inputs）：只读的开关量，比如读取按钮状态。
• 保持寄存器（Holding Registers）：可读可写的 16 位数据，比如设置设备参数。
• 输入寄存器（Input Registers）：只读的 16 位数据，比如读取传感器测量值。

主站通过指定功能码（如读线圈、写寄存器）和地址，就能访问从站对应的数据。

有了上面的基础，开始解读实际的协议展开看里面都有啥。

青鸟JBF293K

Modbus RTU

从下面的原理图，决定了，上位机必须通过轮询(poll)的方式，主动向JBF293K接口卡发送modbus请求，才能获取到消防数据。

设备	Modbus角色	Modbus角色
上位机	主站	主动发送请求，轮询数据
JBF293K接口卡	从站	被动响应，不会主动发数据
青鸟控制器	数据源头	通过 CAN 把报警/故障信息给 JBF293K

上图是一个典型的工业协议转换与系统集成示意图。它展示了如何将一个特定品牌（青鸟）的火警控制器，通过一个接口卡（JBF293K），转换成通用的 Modbus-RTU 协议，从而接入第三方设备。

1. 第三方设备（主站） 会通过 485A/485B 线，不断向 JBF293K（从站）发送 Modbus 请求报文（比如功能码 03 读保持寄存器）。

2. JBF293K（从站） 收到请求后，把青鸟控制器传来的"某某楼层烟感报警"、"某某设备故障"等信息，填入到对应的寄存器地址中。

3. JBF293K 再通过 485A/485B 线，把 Modbus 响应报文发回给第三方设备。

4. 第三方设备解析这些寄存器数据，就知道当前消防系统有没有报警。

左侧：青鸟控制器（数据源头）

这是消防系统的核心设备，负责采集火灾报警、设备故障等信息。

• 24V / GND：电源正负极端口。GND是Ground的缩写，中文通常叫接地或地线。24V是高压端，负责把电流推出去，GND是低压端或公共端，负责让电流流回来。电流必须从 24V 出发，经过设备，再回到 GND，形成一个完整的闭合回路，设备才能正常工作。如果只接 24V 不接 GND，电流没有回路，设备就不通电。
• 外CAN-H / 外CAN-L：青鸟控制器对外提供的数据通信接口，采用的是 CAN 总线协议。CAN 是消防、汽车等领域常用的现场总线，但它是青鸟的"私有语言"或特定工业协议，普通第三方设备无法直接听懂。CAN-H为高电平信号线，CAN-L为低电平信号线。外标识青鸟控制器对外引出的 CAN 接口

中间：JBF293K 接口卡（翻译官/网关）

这是整个系统的核心------协议转换网关。它起到"承上启下"的作用：

1. 承上（接青鸟）：

• 24V 和 G（GND）：从青鸟控制器取 DC24V 电源，给自己供电。

• CH（CAN-H）和 CL（CAN-L）：连接青鸟的外CAN接口，接收青鸟发出的报警、故障等信息。

2. 启下（接第三方）：

• A 和 B：这是一对 RS-485 通信线。接口卡把从 CAN 总线上收到的青鸟私有信息，转换成标准 Modbus-RTU 协议，通过 A、B 线发送出去。RS-485 只是物理层电气标准，上面跑什么协议由上层决定（比如 Modbus-RTU）

右侧：第三方设备（数据接收方）

这可以是电脑上的上位机软件（比如你之前问的 Modbus Poll）、消防图形显示装置（CRT）、楼宇自控系统（BA）等。

• 485A / 485B：接收来自 JBF293K 接口卡的 RS-485 信号。

• 角色：在 Modbus 网络中，这台第三方设备充当主站（Master），而中间的 JBF293K 接口卡充当从站（Slave）。

Modbus RTU协议说明

协议描述了如何配置JBF293K接口卡的Modbus从站地址。协议拆解：

核心通信原则

• 角色确认：JBF293K 是从机（从站），第三方设备（上位机）是主机（主站）。

• 通信模式：主机查询，从机应答（也就是你上一问确认的"轮询"）。

• 轮询间隔：1秒。这意味着上位机每隔 1 秒发一次 Modbus 请求，不能太快也不能太慢，文档明确要求了这个节奏。

• 通信参数：波特率 9600，1位起始位，8位数据位，1位停止位，无校验（这就是常说的 9600, 8, N, 1）。这是 RS-485 上跑 Modbus-RTU 的典型配置

拨码开关怎么用

拨码开关是干嘛的？给 JBF293K 设定身份证号（Modbus 从站地址），好让上位机知道它找的是谁。

JBF293K 上有一排 8 个拨码开关（DIP1~DIP8），用来设置它的地址和协议。打上去是 ON，按下去是 OFF。

前 7 个开关（DIP1~DIP7）组成一个二进制数，代表 Modbus 从站地址。对应关系是：

• DIP1 = 1
• DIP2 = 2
• DIP3 = 4
• DIP4 = 8
• DIP5 = 16
• DIP6 = 32
• DIP7 = 64
  (如果你拨 DIP1 和 DIP2 为 ON，就是 1+2=3，地址就是 3)
  DIP8 是协议选择开关：
• OFF = 使用 Modbus-RTU 协议（你当前场景用的就是这个）
• ON = 使用 Modbus-TCP 协议（需要接以太网，这里不涉及）

地址设置

它规定了 JBF293K 可以设成两种地址范围

情况1：1卡对应1台控制器

• 此时 JBF293K 的地址范围是 1~99。
  7个开关全ON，最大值=1+2+4+8+16+32+64=127，可以代表0_{127共128个数值，但接口文档规定只能用到1}99，这是厂家在协议层面做的限制，不是硬件限制。
• 特别注意：拨码开关设置的地址，必须和它连接的青鸟控制器的"机器号"完全相同。
• 如果青鸟控制器编号是 5，那 JBF293K 的拨码开关也必须拨成 5。
  情况2：1卡对应多台控制器
• 此时 JBF293K 的地址范围是 100~110（因为一个卡对应多台机器，所以它的卡号变成了代表"卡本身"的编号）
• 地址同样用 DIP1~DIP7 拨码设置，但只能设成 100 到 110 之间。

1卡对1台时，为什么地址要和控制器的机器号相同，设计逻辑是青鸟控制器本身有一个"机器号"，范围也是 1~99。JBF293K 作为它的"协议翻译卡"，被要求沿用同一个编号。上位机通过 Modbus 地址就能直接对应到是哪一台青鸟控制器，不需要额外维护一张"Modbus地址 ↔ 青鸟机器号"的映射表。

使用约束条件

一、1卡对1台控制器

1. 只支持消防电源监控类设备。
2. 控制器的回路范围必须是 1~14，且通道号最大为 2。

二、1卡对多台控制器

1. 支持的机型更多（报警主机、电气火灾、防火门、消防电源监控），但每种机型都有各自的"控制器号"范围（1~64 或 1~28）。
2. 重要限制：各种机型不能混着接在同一张卡上，必须清一色全是同一种机型。
3. 每台机器只能有 1 个回路，一共最多接 200 个点位。
4. 查询指令的坑：以前"1卡对1台"时，查询指令里的 N 代表"第N回路"；现在"1卡对多台"时，指令里的 N 代表"第N号控制器"。查询指令格式没变，但含义变了，写上位机软件的人必须知道这一点。
5. 1台青鸟控制器需配置1个JBF293K接口卡。这个限制条件也代表虽然JBF293K 支持1卡多台，但实际青鸟采纳的时1卡1台方案。

第三方设备发起查询指令

先看modbus中字段，可以看到地址、数据、数量这三类字段都是16位2个字节，

地址、数量采用高端序。

为什么低字节是0x01或者0x65，因为这两个代表的十进制是1和101，而每次查询100个寄存器，这样就分别覆盖范围1_100，101200.

如果起始地址=2，则覆盖2~101，101则属于后半段，数据查询就乱套了。

回路是物理上的一条总线，上面挂了一串部件。地址是这条总线上每个部件的编号。

例如，64个回路是物理与架构的天花板。回路数量主要受制于控制器的物理扩展能力和总线负载：

• 硬件插槽有限：青鸟控制器采用"积木式拼装"结构，回路数量取决于机箱里能插多少块"报警回路板"。主流柜式控制器最多预留了64个回路板的槽位，这就是物理上限
• 总线负载与距离：每条回路总线本身有供电和信号衰减的限制。如果一条线上挂太多设备，电压会下降，信号也会变弱，导致巡检超时。青鸟每回路定为200点，正是为了在 1500米 的长距离下，依然保证 2.8秒 左右的巡检周期能稳定完成

200个地址受国家消防规范和工程可靠性的约束

• 国标硬性规定：根据《火灾自动报警系统设计规范》，每一总线回路连接的设备总数不宜超过200点，且必须留有不少于额定容量10%的余量。这就是200这个数字最直接的来源。

• 留出"生命余量"：工程上不会把200个点全部占满。留出10%（即20个点）是为了后期维护和故障隔离。如果一条回路满载200个点，一旦某个设备或线路短路，可能导致整条回路瘫痪。留有余量，能有效降低这种"一损俱损"的风险。

回路号要转成16进制

• 查第1回路的前100个部件 01 03 00 01 00 64 CRC CRC
• 查第1回路的后100个部件 01 03 00 65 00 64 CRC CRC
• 查第5回路的钱100个部件 01 03 04 01 00 64 CRC CRC
• 查多线设备 01 03 41 01 00 64 CRC CRC

查询电源监控系统第三方设备发起查询指令

报警系统中byte3只装回路号，范围0x00_{0x3F，对应1}64回路。但是电源监控系统不一样，它引入了通道号的概念，Byte3被拆成两半：

协议说查询时回路号、通道号都-1，也就是说

• 查询第1回路，高4位为0；第1通道，低4位为0，则Byte3 = 0x00
• 查询第2回路，高4位位1；第3通道，低4位为3-1=2，则Byte3 = 0x12
  
  为什么电源监控要引入"通道号"？
  这是电源监控系统和报警系统的物理结构差异决定的。
  
  电源监控控制器（比如监控消防设备电源的电压、电流）通常有多个通道，每个通道下再挂设备。所以定位一个设备需要三级坐标：
  
  但Modbus 起始地址有16位，Byte3只有8位，怎么装下三级信息？于是就有了Byte3高4位代表回路号，低4位代表通道号。范围是1~16
  报警系统 Byte3 只用了低 6 位（0~63），高 2 位空着。
  电源监控把 Byte3 的 8 位全用上了：高 4 位 + 低 4 位，正好装下回路和通道两个信息。
  
• 查第 2 回路、第 3 通道、第 1~100 个设备： 01 03 12 01 00 64 CRC CRC

JBF293K接口卡反馈数据

下表是JBF293K的响应报文结构，也就是上位机发完查询指令后，JBF293K 回给它的数据长什么样。

• 请求读取100个寄存器，每个寄存器2字节，所以响应里就是200个字节的数据，0xC8=200
  响应总长度=1+1+200+2=205字节
• 每2个字节代表1个部件，这2个字节里，高字节全为0，低字节才是真正代表状态的位。为什么高字节全0呢，青鸟是为了兼容modbus标准做的空间填充，部件状态（火警、故障、启动、反馈、屏蔽等）1个字节就完全够用了。
  
  实际拆解一下，部件状态 00 23
  
  对照表格,结论是这个部件同时有火警、故障、监管报警三种状态
  
  如此看来modbus接口协议很简单，下次写一下如果用.net开发
  上面的协议没有描述CRC的算法，是因为modbus协议标准已经规定写了CRC-16的计算方法，所有modbus设备都必须用同一套算法