前言
书接上文，这周我们就开始深入解读下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技术的核心价值体现。
