西门子S7comm协议解析 —— 利用Wireshark对报文逐字节进行解析详细解析S7comm所含功能码以及UserData功能(path3)

好了开始搞UserData这一块了。html

接着上一篇继续post

西门子S7comm协议解析 —— 利用Wireshark对报文逐字节进行解析详细解析S7comm所含功能码以及UserData功能(path2)url

 

提及这个UserData是属于西门子后期加的一些功能,也就是这些功能让S7这个协议变得更加丰富,也是由于这些功能让S7变得很臃肿,也不利用使用。spa

双刃剑没办法去评判。3d

 

这个我就按照我抓包的顺序进行介绍吧,可能不会介绍完,可是基本上你明白一个其余的也就差很少了。htm

能够利用它明白它的某块字段的含义就好了,暂时我不必去深刻的去了解他的原理,因此有些地方讲的不会太细请见谅。对象

一、读系统状态 — 44 1

为何我把44 1 专门的写上去呢 其实UserData也有对应的功能码 可是太杂乱blog

44 是功能的大致方向 1 是具体功能ssl

发包get

 

 

这个Header头部跟其余的都同样  我就直接把上一篇的复制过来,重点仍是参数部分。

Byte[0] 为 协议ID  这个只要是S7comm协议通常都是指定0x32

Byte[1] 为 PDU类型  这个只要是Userdata都是07

Byte[2]Byte[3] 冗余数据,一般为0×0000

Byte[6]Byte[7] 参数的总长度也就是parameter的长度

Byte[8]Byte[9] 数据的长度、也就是data部分数据的长度若是无即为0

Parameter部分

Byte[0] Byte[1] Byte[2] 00 01 12 参数头部信息

Byte[3] 04 为以后的数据个数

Byte[4] 11 对应的是Request 也就是请求的意思

Byte[5] 44 这个由于wireshark 帮咱们解析了8位前四位 0100 对应的就是Request请求

说明PDU是从主机请求设备的后四位0100 对应的是所属类型也就是CPU功能

Byte[6] 01 前面44是规定了大的方向这个01就是具体要干什么了图中01就是read szl

在这里解释一下szl 是什么ssl缩写是系统状态 S7协议是德国西门子的德国状态的是Z开头的因此缩写为 szl

Byte[7] 字面意思由主机指定顺序

Data部分

Byte[0] FF 返回码 返回码常见如下表

0x00       Reserved 未定义,预留

0x01       Hardware error   硬件错误

0x03       Accessing the object not allowed 对象不容许访问

0x05       Invalid address     无效地址,所需的地址超出此PLC的极限

0x06       Data type not supported     数据类型不支持

0x07       Data type inconsistent 日期类型不一致

0x0a       Object does not exist    对象不存在

0xff     Success  成功

Byte[1] 09 指的数据类型,一般有bit、byte等 常见数据类型如下表

0     NULL

3     BIT bit access, len is in bits

4     BYTE/WORD/DWORD     byte/word/dword access, len is in bits

5     INTEGER    integer access, len is in bits

6     DINTEGER  integer access, len is in bytes

7     REAL    real access, len is in bytes

9     OCTET STRING octet string, len is in bytes

Byte[2]Byte[3] 00 04 后面数据的个数

SZL部分

前四位为操做的对象是什么 0000 为CPU 1100为cp 1000为fm 0100为im

中间0000 0000 0000 0000是wireshark解析错了按照官方的应该为四位

后八位 代表的是局部列表的序号 咱们只须要关注最后两位就行(0x00)下面是各种的序号图

 这么一来是否是看起来UserData这一块也没那么难对吧,继续来看回包吧。

回包

Header头部不作描述了与以前都相同的本身对比就能够

Parameter部分

00 01 12 与发包一致

08  长度

12  对应的Response 回应请求

84  前四位1000 对应的就是 Response  后四位 0100就是要读CPU

01  读系统状态SZL

00  与发包一致

00  数据的编号

00  字译最后一个数据单元

00  错误码

Data部分

FF 返回码

09  指的数据类型

00 e8 后面数据个数

SZL-ID 和 Index 跟发包是同样的不作介绍了

00 02   是一个数据占用多少bytes

00 70   转换为10进制为112 表明了有112个SZL_data_tree (图太大就没截下去)

后面的PDU就不在分析了都是作读取相关类的相关信息、只不过是指定的局部列表不一样、index不一样罢了。

二、时间设置 —— 47 1 

47 1对应的也就是读时间

发包

 能够看出基本与读SZL状态是同样的我在总体标记一下吧

回包

Parameter部分

Data部分

 三、写时间 47 2

发包

与读时间是同样的只不过data部分是在发包阶段。

由于要写时间 那么确定发包的时候会携带时间信息对吧,这个也很容易去理解。

回包

这么一看是否是基本是同样。

本身比对一下就OK了

 

未完待续..... 有一些眼酸了先放着吧明天在添加

相关文章
相关标签/搜索