从业8年工业协议相关工作以后, 我觉得地址这般基础的知识, 每个人都明白。直至去年带领一名新人, 要他配置一台电表的点位。
他讲, 写在手册上的温度寄存器地址是40001, 他于软件当中填的是40001, 然而却读取不到数据, 他如此说道。
我说："你填试试。"
他愣了："40001和有什么关系？"
那一刻我意识到：80%的工程师，都没真正搞懂地址。
的"两套地址系统"
协议里，寄存器地址有两种表示方式，而且两种都在用：
第一套：协议地址（PLC地址）
套, 这个地址, 是用于人机界面的, 那些 PLC 编程软件, HMI 以及设备手册, 平常写的就是这套。
第二套：协议地址（通信地址）
用来作为协议报文所使用的, 是这一套地址, TCP/RTU 的报文中, 这套在所使用地址的字段方面。
为什么40001等于？
因为：
换算规则：
但要留意, 这个换算仅仅适用于"标准实现", 某些厂商所生产的设备, 其手册当中写明的是40001, 而在实际进行通信的时候所采用的（即手册地址减去40000, 并非减去40001）。
我踩过的坑
坑一：手册和实现不一致
针对某一品牌的电表, 其手册表明存在"电压寄存器地址 40001"这种情况。当将其在采集软件里进行填写时, 却无法读取到。然而填写之后, 又能够读取到了。
后来与厂商技术支撑取得联系, 对方有所说明道, 在我们手册之上所提及的"40001", 其对应着协议地址, "40001"属于第1个保持寄存器, 然而在我们的实现情况当中, 第1个却是。
我：？？？
坑二：软件自动换算的陷阱
存在一些采集软件, 好比组态王这类, 其配置界面设定需填写"40001", 于此软件内部会自行作换算。然而又有一些软件, 像是自行编写的脚本那般, 你所填写的内容便会原样发送出去。
假设你运用软件A进行配置（填入40001, 软件会自行展开换算）, 之后将其迁移至软件B（需自行编写脚本，并填入40001进而直接发送报文）, 到头来数据却发生了错位情况。
坑三：功能码和地址的对应关系
的地址空间是按功能码区分的：
同一个协议地址，用不同的功能码读，读的是完全不同的数据。
遇到过最离谱的的bug, 有个工程师, 用功能码0x03去读地址的情况, 他觉得读的一直是保持 （也就是温度咯）, 可事实呢, 实际状况是设备在这个地址存进去的实际是个设备ID.温度数值所在的地址其实是（40002）。他就这么持续了一周都在读设备ID, 浑然不知觉得都没觉得温度有啥变化, 一直以为温度恒定根本没产生任何改变。
坑四：32位数据的地址对齐
具有16位性质的是寄存器, 32位的数据, 也就是float以及int32是具有的, 需要占用2个寄存器, 这就是其情况。
某设备手册写："功率寄存器地址40001，32位浮点。"
这有两种理解：
我平常的做法是, 先运用 Poll 去扫描一回整个地址空间, 瞧瞧实际的数据究竟落在何处, 不要盲目迷信手册。
我的"地址速查表"
现在做项目，我随身携带这张表，发给每个新人：
表格
复制
但记住：手册可能骗人，报文不会。
写在最后
这种被称作"基础知识"的地址, 看上去简单, 然而细节之处却全是魔鬼。比如40001和的关系, 再说功能码与地址的对应, 另外32位数据的对齐方式, 每一个要点都能够致使项目延期一周, 对, 就是一周。
如果此刻你正处于配置设备的状态, 又或者新人老是出现配置错误地址的情况, 那么建议你收藏这张表。在我们的开源驱动框架当中, 还内置了地址自动换算功能以及全地址空间扫描功能:
工业协议驱动框架, 它内置着地址自动换算功能, 还有功能码校验功能, 也有32位数据对齐检测功能。
:
Gitee:
然而, 40001仅只是如此, 可是, 明白这件事情, 与切实做到毫无差错, 其间却横亘着100个项目。