前言

書接上文，這周我們就開始深入解讀下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技術的核心價值體現。