第 1 页 共 29 页
开放型 MODBUS-TCP 规范(中文版)
发布时间:2005 年 7 月 5 日
开放型 Modbus/TCP 规范
修订版 1.0,1999 年 3 月 29 日
Andy Swales
Schneider 电气公司
aswales@modicon.com
目录
目录.................... 2
1.该规范的发展概况.................... 3
2.概述................. 3
2.1 面向连接. 3
第 2 页 共 29 页
2.2 数据编码 4
2.3 参考编号的解释........... 4
2.4 隐含长度基本原则....... 5
3. 一致性等级概述........................ 5
3.1 类型 0..... 5
3.2 类型 1..... 5
3.3 类型 2..... 6
3.4 机器/厂家/网络的特殊功能.................... 7
4.协议结构........ 7
5. 一致性等级的协议参考值....... 8
5.1 类型 0 指令详述................ 9
5.1.1 读乘法寄存器 (FC 3)................ 9
5.1.2 写乘法寄存器 (FC 16).............. 9
5.2 类型 1 指令详述.............. 10
5.2.1 读线圈 (FC 1)....... 10
5.2.2 读离散输入 (FC 2).................. 10
5.2.3 读输入寄存器 (FC 4).............. 11
5.2.4 写线圈(FC 5)....... 11
5.2.5 写单一寄存器 (FC 6).............. 12
5.2.6 读异常状态字 (FC 7).............. 12
5.3 类型 2 指令详述.............. 13
5.3.1 强制多点线圈 (FC 15)............ 13
5.3.2 读一般参考值 (FC 20)............ 14
5.3.3 写一般参考值 (FC 21)............ 15
5.3.4 掩模写寄存器 (FC 22)............ 16
5.3.5 读/写寄存器 (FC 23).................. 16
5.3.6 读 FIFO 队列 (FC 24)..... 17
6. 异常代码.... 17
附录.................. 19
A.客户机和服务器应用指导..... 19
A.1 客户机设计.................. 19
A.2 服务器设计.................. 20
A.2.1 多线程服务器 20
A.2.2 单线程服务器..... 21
A.3 必需的及期望的性能. 22
B. 非指令数据的编码.................. 23
B.1 指令字中的比特数..... 23
B.2 多指令字变量.............. 24
B.2.1 984 数据类型..... 24
B.2.2 IEC-1131 数据类型..... 25
该规范的发展概况
第 3 页 共 29 页
原始版本 1997 年 9 月 3 日
作为公共评论的草案。
再版 1999 年 3 月 29 日,即修订版 1.0。
没有大的技术改动,仅作了补充说明。
增加了附录 A 和 B 作为对一些常用执行问题的回应。
该 MODBUS/TCP 规范在万维网上公开发行。它表明开发者的意愿是把它作为工业自动化领
域具有互用性的标准。
既然 MODBUS 和 MODBUS/TCP 作为事实上的“实际”标准,而且很多生产商已经实现了它
的功能,此规范主要是阐述在互连网上具有普遍可用性的基于 TCP 通讯协议的 MODBUS 报
文的特殊编码。
2.概述
MODBUS/TCP 是简单的、中立厂商的用于管理和控制自动化设备的 MODBUS 系列通讯协议
的派生产品。显而易见,它覆盖了使用 TCP/IP 协议的“Intranet”和“Internet”环境中 MODBUS
报文的用途。协议的最通用用途是为诸如 PLC’s,I/O 模块,以及连接其它简单域总线或 I/O
模块的网关服务的。
MODBUS/TCP 协议是作为一种(实际的)自动化标准发行的。既然 MODBUS 已经广为人知,
该规范只将别处没有收录的少量信息列入其中。然而,本规范力图阐明 MODBUS 中哪种功
能对于普通自动化设备的互用性有价值,哪些部分是 MODBUS 作为可编程的协议交替用于 P
LC’s 的“多余部分”。
它通过将配套报文类型“一致性等级”,区别那些普遍适用的和可选的,特别是那些适用于特
殊设备如 PLC’s 的报文。
2.1 面向连接
在 MODBUS 中,数据处理传统上是无国界的,使它们对由噪音引起的中断有高的抵抗力,
而且在任一端只需要最小的维护信息。
编程操作,另一方面,期望一种面向连接的方法。这种方法对于简单变量通过唯一的“登录”
符号完成,对于 Modbus Plus 变量,通过明确的“程序路径”容量来完成,而“程序路径”容量
维持了一种双向连接直到被彻底击穿。
第 4 页 共 29 页
MODBUS/TCP 处理两种情况。连接在网络协议层很容易被辨认,单一的连接可以支持多个
独立的事务。此外,TCP 允许很大数量的并发连接,因而很多情况下,在请求时重新连接或
复用一条长的连接是发起者的选择。
熟悉 MODBUS 的开发者会感到惊讶:为什么面向连接 TCP 协议比面向数据报的 UDP 要应
用广泛。主要原因是通过封装独立的“事务”在一个连接中,此连接可被识别,管理和取消而
无须请求客户和服务器采用特别的动作。这就使进程具有对网络性能变化的适应能力,而且
容许安全特色如防火墙和代理可以方便的添加。
类似的推理被最初的万维网的开发者所采用,他们选用 TCP 及端口 80 去实现一个作为单一
事务的最小的环球网询问。
2.2 数据编码
MODBUS 采用“big-endian”来表示地址和数据对象。 这就意味着当一个数字表示的数量大于
所传输的单一字节,最大有效字节将首先被发送。例如:
16 - bits 0x1234 将为 0x12 0x34
32 - bits 0x12345678L 将为 0x12 0x34 0x56 0x78
2.3 参考编号的解释
MODBUS 将其数据模型建立在一系列具有不同特征的表的基础之上。这四个基本表如下
离散输入 单比特,由 I/O 系统提供,只读
离散输出 单比特,由应用程序更改,读写
输入寄存器 16 比特,数值,由 I/O 系统提供 ,只读
输出寄存器 16 比特,数值,由应用程序更改,读写
输入和输出之间以及可寻址位和可寻址代码的数据对象之间的差别并不意味着任何应用性能
的不同。如果这是我们所讨论的目标机械的最自然的解释,那么认为所有的四个基本表是相
互覆盖的看法也是非常普通而完全可以接受的。
对于每一个基本表,协议允许单独选择 65536 个数据对象中的任何一个,而且对那些对象的
读写操作可以跨越多个连续的数据对象,直到达到基于处理事务功能代码的数据大小限制。
这儿没有假定数据对象代表一种真正邻接的数据阵列,而这是大多数简单 PLC’s 的解释。
“读写常用参考”功能代码被定义为携带 32 位的参考值并且能允许在“非常”大的空间里可以直
第 5 页 共 29 页
接访问数据对象。现在没有可以利用这一特点的 PLC 设备。
一个易造成混乱的潜在来源是用于 MODBUS 功能的参考值和用于 Modicon PLC’s 的“寄存器
值”之间的关系。由于历史原因,用户参考值使用从 1 开始的十进制数表示。而 MODBUS 采
用更普通的从 0 开始的无符号整数进行软件数据整理分析。
于是,请求从 0 读取寄存器的 Modbus 消息将已知值返回建立在寄存器 4:00001(存储类型
4=输出寄存器,参考值 00001)中的应用程序。
2.4 隐含长度基本原则
所有的 MODBUS 请求和响应都被设计成在此种方法下工作,即接收者可确认消息的完整性。
对于请求和响应为固定长度的功能代码,仅发送功能代码就足够了。对于在请求和响应中携
带不定长数据的功能代码,数据部分前将加上一个字节的数据统计。
当 Modbus 通过 TCP 运送,前缀中携带附加的长度信息以便接收者识别消息的边界,甚至
消息被分成若干组进行传输。 外在的和隐含的长度准则的存在,以及 CRC-32 检错代码(以
太网)的使用使请求和响应消息中发生未被识别的错误的机率减至无限小。
3. 一致性等级概述
当从草稿开始定义一种新的协议,有可能加强编码方式和阐述的一致性。MODBUS 由于其
先进的特性,已经在很多地方得到了实施,必须避免破坏它已经存在的实施。
因此,已经存在的成套的处理类型被划分出一致性等级:等级 0 代表普遍使用且总体上一致
的功能;等级 2 代表有用的功能,但带有某些特性。现存装置的不适应于互用性的功能也已
确认。
必须注意到,将来对该标准的扩充将定义附加的功能代码来处理现存事实标准不适用的情形。
然而,被提议扩充的详细资料出现在本手册中将会另人误解。通过将代码“随机的”发送或者
即便是通过检查异常响应的类型来确定特别的目标装置是否支持特别的功能代码总是可能的,
而且该方法将保证引入这些扩充的现使用的 MODBUS 设备的连续的互用性。事实上,这就
是当前功能代码的分级原则。
Modbus 功能代码
共有三种类型分别为:
·
公共功能代码
已定义好的功能码,保证其唯一性,由 Modbus.org 认可。
·
用户自定义功能代码
有两组,分别为 65~72 和 100~110,不需要认可,但不保证代码
使用的唯一性,如想变为公共代码,需要 RFC 认可。
评论0