ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

modbus协议 青鸟

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 位数据比如读取传感器测量值。主站通过指定功能码如读线圈、写寄存器和地址就能访问从站对应的数据。有了上面的基础开始解读实际的协议展开看里面都有啥。青鸟JBF293KModbus RTU从下面的原理图决定了上位机必须通过轮询(poll)的方式主动向JBF293K接口卡发送modbus请求才能获取到消防数据。设备Modbus角色Modbus角色上位机主站主动发送请求轮询数据JBF293K接口卡从站被动响应不会主动发数据青鸟控制器数据源头通过 CAN 把报警/故障信息给 JBF293K上图是一个典型的工业协议转换与系统集成示意图。它展示了如何将一个特定品牌青鸟的火警控制器通过一个接口卡JBF293K转换成通用的 Modbus-RTU 协议从而接入第三方设备。第三方设备主站 会通过 485A/485B 线不断向 JBF293K从站发送 Modbus 请求报文比如功能码 03 读保持寄存器。JBF293K从站 收到请求后把青鸟控制器传来的“某某楼层烟感报警”、“某某设备故障”等信息填入到对应的寄存器地址中。JBF293K 再通过 485A/485B 线把 Modbus 响应报文发回给第三方设备。第三方设备解析这些寄存器数据就知道当前消防系统有没有报警。左侧青鸟控制器数据源头这是消防系统的核心设备负责采集火灾报警、设备故障等信息。24V / GND电源正负极端口。GND是Ground的缩写中文通常叫接地或地线。24V是高压端负责把电流推出去GND是低压端或公共端负责让电流流回来。电流必须从 24V 出发经过设备再回到 GND形成一个完整的闭合回路设备才能正常工作。如果只接 24V 不接 GND电流没有回路设备就不通电。外CAN-H / 外CAN-L青鸟控制器对外提供的数据通信接口采用的是 CAN 总线协议。CAN 是消防、汽车等领域常用的现场总线但它是青鸟的“私有语言”或特定工业协议普通第三方设备无法直接听懂。CAN-H为高电平信号线CAN-L为低电平信号线。外标识青鸟控制器对外引出的 CAN 接口中间JBF293K 接口卡翻译官/网关这是整个系统的核心——协议转换网关。它起到“承上启下”的作用承上接青鸟24V 和 GGND从青鸟控制器取 DC24V 电源给自己供电。CHCAN-H和 CLCAN-L连接青鸟的外CAN接口接收青鸟发出的报警、故障等信息。启下接第三方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 请求不能太快也不能太慢文档明确要求了这个节奏。通信参数波特率 96001位起始位8位数据位1位停止位无校验这就是常说的 9600, 8, N, 1。这是 RS-485 上跑 Modbus-RTU 的典型配置拨码开关怎么用拨码开关是干嘛的给 JBF293K 设定身份证号Modbus 从站地址好让上位机知道它找的是谁。JBF293K 上有一排 8 个拨码开关DIP1~DIP8用来设置它的地址和协议。打上去是 ON按下去是 OFF。前 7 个开关DIP1~DIP7组成一个二进制数代表 Modbus 从站地址。对应关系是DIP1 1DIP2 2DIP3 4DIP4 8DIP5 16DIP6 32DIP7 64(如果你拨 DIP1 和 DIP2 为 ON就是 123地址就是 3)DIP8 是协议选择开关OFF 使用 Modbus-RTU 协议你当前场景用的就是这个ON 使用 Modbus-TCP 协议需要接以太网这里不涉及地址设置它规定了 JBF293K 可以设成两种地址范围情况11卡对应1台控制器此时 JBF293K 的地址范围是 1~99。7个开关全ON最大值1248163264127可以代表0127共128个数值但接口文档规定只能用到199这是厂家在协议层面做的限制不是硬件限制。特别注意拨码开关设置的地址必须和它连接的青鸟控制器的“机器号”完全相同。如果青鸟控制器编号是 5那 JBF293K 的拨码开关也必须拨成 5。情况21卡对应多台控制器此时 JBF293K 的地址范围是 100~110因为一个卡对应多台机器所以它的卡号变成了代表“卡本身”的编号地址同样用 DIP1~DIP7 拨码设置但只能设成 100 到 110 之间。1卡对1台时为什么地址要和控制器的机器号相同设计逻辑是青鸟控制器本身有一个“机器号”范围也是 1~99。JBF293K 作为它的“协议翻译卡”被要求沿用同一个编号。上位机通过 Modbus 地址就能直接对应到是哪一台青鸟控制器不需要额外维护一张“Modbus地址 ↔ 青鸟机器号”的映射表。使用约束条件一、1卡对1台控制器只支持消防电源监控类设备。控制器的回路范围必须是 1~14且通道号最大为 2。二、1卡对多台控制器支持的机型更多报警主机、电气火灾、防火门、消防电源监控但每种机型都有各自的“控制器号”范围1~64 或 1~28。重要限制各种机型不能混着接在同一张卡上必须清一色全是同一种机型。每台机器只能有 1 个回路一共最多接 200 个点位。查询指令的坑以前“1卡对1台”时查询指令里的 N 代表“第N回路”现在“1卡对多台”时指令里的 N 代表“第N号控制器”。查询指令格式没变但含义变了写上位机软件的人必须知道这一点。1台青鸟控制器需配置1个JBF293K接口卡。这个限制条件也代表虽然JBF293K 支持1卡多台但实际青鸟采纳的时1卡1台方案。第三方设备发起查询指令先看modbus中字段可以看到地址、数据、数量这三类字段都是16位2个字节地址、数量采用高端序。为什么低字节是0x01或者0x65因为这两个代表的十进制是1和101而每次查询100个寄存器这样就分别覆盖范围1100101200.如果起始地址2则覆盖2~101101则属于后半段数据查询就乱套了。回路是物理上的一条总线上面挂了一串部件。地址是这条总线上每个部件的编号。例如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只装回路号范围0x000x3F对应164回路。但是电源监控系统不一样它引入了通道号的概念Byte3被拆成两半协议说查询时回路号、通道号都-1也就是说查询第1回路高4位为0第1通道低4位为0则Byte3 0x00查询第2回路高4位位1第3通道低4位为3-12则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 CRCJBF293K接口卡反馈数据下表是JBF293K的响应报文结构也就是上位机发完查询指令后JBF293K 回给它的数据长什么样。请求读取100个寄存器每个寄存器2字节所以响应里就是200个字节的数据0xC8200响应总长度112002205字节每2个字节代表1个部件这2个字节里高字节全为0低字节才是真正代表状态的位。为什么高字节全0呢青鸟是为了兼容modbus标准做的空间填充部件状态火警、故障、启动、反馈、屏蔽等1个字节就完全够用了。实际拆解一下部件状态 00 23对照表格,结论是这个部件同时有火警、故障、监管报警三种状态如此看来modbus接口协议很简单下次写一下如果用.net开发上面的协议没有描述CRC的算法是因为modbus协议标准已经规定写了CRC-16的计算方法所有modbus设备都必须用同一套算法
返回列表