睿远研究院丨IO-Link OD模块解析

前言

书接上文，这周我们就开始深入解读下OD模块。OD的全称是On-Request Data，即在请求时才会应的报文。OD模块通常分为三个部分，ISDU、Command和Event，这也是我们解读OD状态机的过程中，重点分析的内容。

01 主站的OD数据处理

上图是主站的状态机，主站的On-request处理程序是DL-Mode处理模块中“Startup_2”“PreOperate_3”和“Operate_4”状态下的一个从属状态机。它控制其他三个状态机，即ISDU处理模块、command处理模块和Event处理模块的状态机，默认情况下，它始终在ISDU状态。

1 当收到EventFlag时，状态机将切换到Event处理模块，在完整读取Event信息后，它将返回到ISDU处理状态；

2 当收到DL_Control，则状态机将切换到Command处理模块；完成相关命令后，状态机将返回到之前的状态（ISDU或Event状态）

3 当收到DL_Write_DeviceMode命令，也会切换到Command模块，用于处理DL Mode的状态切换，这是1.1.4版本增加的内容

02 从站的OD数据处理

从站对OD的请求重定向4个独立的小模块：

⭐️Param读写模块

该模块主要读写DPP部分的数据，专门走了Page通道

⭐️Command模块

用于切换从站的状态，保持和主站的同步

⭐️ISDU模块

读写ISDU

⭐️Event模块

读写Event

03 DPP&ISDU的处理

DPP即Direct Parameter Page，其实属于ISDU部分，DPP1对应ISDU的Index 0x00，DPP2对应ISDU Index 0x01。

规范中明确如果不支持ISDU，就直接采用DPP1和DPP2进行参数的读写，这是为了方便一些简化版本的协议栈进行简单的IO-Link控制。

那么我们看DPP和ISDU在规范中的定义：

DPP1和DPP2就是从属于ISDU的，只是协议栈规定了DPP走的PAGE通道，其余ISDU走ISDU通道，个人认为，其把简单的东西复杂化了，如果合二为一岂不是更好。

其中0x00：MasterCommand主要用于接收主站的各类命令，进入Command模块进行处理：

04 MasterCycleTime&MinCycleTime

MinCycleTime是从站主动上传汇报给主站的循环时间，而MasterCycleTime则是主站最终根据字节大小，从站汇报的循环时间决策出的实际时间，都是采用Timebase｜Multiplier的方式，具体如下：

05 M-sequence Capability编码格式

这个编码在前面的章节中已经详细介绍，这里就不多说了，直接看一个例子：

这是从站回复的一个示例，这回复的0x21这个数据中，表明了自己分别在Preop和OP模式下的OD字节大小

06 ProcessDataIn& ProcessDataOut

PDIn和PDOut的字段，都是采用是否Byte位和Length来组成，把一个字节的作用抠到了极致。

写在最后  

好了，以上就是本期OD处理模块与DPP主要字节的解析，DPP作为IO-Link的关键参数，包含了IO-Link设备的关键信息。下一期，我们就开始介绍与参数配置相关的ISDU部分，这也是IO-Link技术的核心价值体现。