睿远研究院丨IO-Link规范解读（九）： PD与OD处理模块详解

前言

书接上文，这周我们就开始深入解读下PD与OD模块。PD即周期性数据，每次主从站间通信都会交互的数据类型，它分为PDin与PDout。OD的全称是On-Request Data，即在请求时才会应的报文。OD模块通常分为三个部分，ISDU、Command和Event。

01

主站消息状态机回顾

上回我们讲到消息处理模块最重要的M-Sequence Type以及主从站的消息状态机，主站的消息状态机会稍微复杂一点，我们在开发主站协议栈的时候，也碰到一些无法理解的规则。

在规范中DL_WRITE和DL_READ都是通过Page通道读写通信参数的，应该都是在Startup阶段才能进行，是不允许在PREOP和OP阶段进行的。但是小编在1.1.3版本时就发现一个问题，从PREOP切换到OP时，需要DL_WRITE发送切换模式的命令，同时发送一个masterCycletime的写入指令，这个指令也是DL_Write的命令。

这就造成了一个困惑，虽然在状态机中DL_Write_DeviceMode这个命令属于单独的命令，在PREOP阶段也适用，但是DL_Write(0x01, "MasterCycleTime")可是确确实实的DL_Write，理论上不应该出现在PREOP阶段的它，却出现了，直到目前最新的1.1.4版本尚未给任何说明。

具体如下图，DL_Write(0x01, "MasterCycleTime")这条命令是在从PREOP切换到OP前发出的，也就是其还在PREOP阶段。

好了，我们希望下个版本能够解决这个问题，同时各位小伙伴也可以测试一下自家的主站是否会发出DL_Write(0x01, "MasterCycleTime")这个命令。

这条命令仅仅在这个图中出现了一次，在其他地方再无提及，猜测这个命令未必是必须的，因为主站通知从站我的mastercycletime也没有多大作用，毕竟从站都是被动式应答，只有主站询问了，从站才会回答。

02

关于ProcessData

下面来讲讲PD处理模块，在1.0时代，IO-Link规范规定了PD交互的多种方式，要求每次交互就2字节，PD和OD交错运行，PD多余2个字节，就得拆包，多次发送，这个效率可想而知，非常低下，因此1.1版本做了重大改革，废除了这种低下的方式。

1.1版本后，每次最大32字节PD数据，中间还可以夹带OD数据，大大提升发送效率；当然对于像RFID这种上百个字节的，还是需要拆分字节，多次发送，再组包。

03

主从站的PD状态机

3.1 主站PD状态机

为了兼容1.0版本，状态机里还把遗留的PDInInterleave放到了里面，从1.1版本来看，PD就两个状态，Inactive状态（即Startup和PREOP所处的装状态）和PDSingle状态（即OP所处的状态）。

3.2从站PD状态机

从站的PD状态机也比较简单，从inactive状态被激活后，进入active状态，Handle PD主要是1.0版本的遗留，在多个字节数据挨个处理的时候来回在PD Active和Handle PD之间交互，而1.1版本，直接进行DL_PDInputUpdate就行了。

3.3总结

综上所述，PD就是简单的收发数据，没有太多的处理，应该算IO-Link协议栈内部最简单的模块了。

那么拿到睿远的IO-Link协议栈怎么处理PD数据呢，虽然简单，但PD也是IO- Link最重要的数据，对于老版本的睿远协议栈，可以直接操作PDE_PDIn和PDE_PDOut这个指针就行了。

按照大端排序的原则，PDE_PDIn[0]就是上传主站PD数据的最左边的那个字节，因为PDE_PDIn的内存是动态创建的，故要避免指针越界的问题。

在新版本中我们封装了一个函数：

UIntegerT8 CeresStackSetPDInData(UIntegerT8 *pdin_data, UIntegerT8 pdin_len)

通过该函数，可以尽量避免指针越界的问题。

对于SSP的版本，进一步封装了直接给测量值赋值的函数，这个就后续在SmartSensorProfile这个章节再讲了。

04

主站的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版本增加的内容

05

从站的OD数据处理

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

Param读写模块

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

Command模块

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

ISDU模块

读写ISDU

Event模块

读写Event

06

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模块进行处理：

07

MasterCycleTime&MinCycleTime

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

08

M-sequence Capability编码格式

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

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

09

ProcessDataIn& ProcessDataOut

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

结语

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