前言

上回咱們分解到IO-Link的消息處理模塊，消息處理模塊就是對每個字節進行初步分析，按照不同的通道交給不同的處理模塊來處理，可以認為他是初步的消息分揀機制，合格的消息交給后續處理，不合格的消息直接丟棄，減少后端工作量。

那么今天我們就來深入研究下，消息處理模塊中提到的各類M-Sequence，以及主從站的消息處理狀態機！

01 M-Sequence Type

上回講到主站發出來的MC和CKT兩個報文，其中CKT 前的2bit是指M-Sequence Type，那么這個M-Sequence type到底有啥用，我們看規范里M-Sequence有好多種，到底怎么區分，今天就來好好講講。

在規范的A.2.6部分，就詳細介紹了關于STARTUP、PREOPERATE、OPERATE三種模式下的M-Sequence Type。

01 / STARTUP下的M-Sequence Type

上圖就是STARTUP模式下的M-Sequence Type，規范就定了一種即TYPE_0，1字節，同時規定了其最小recovery time是100TBit。

這個最小的recovery time簡單理解為循環時間就行，也就是主站每隔100TBit主動發起數據，這個時間和通訊速率有關系，如果是COM3，則是400多us的時間；如果低于這個時間在規范看來是不合理的。

02 / PREOPERATE下的M-Sequence Type

PREOPERATE模式下，M-Sequence Type 可以有TYPE_0和TYPE_1，TYPE_1又分解為TYPE_1_2和TYPE_1_V，也就是OD字節長度不一樣而已；

一般市面上的從站，都是TYPE_1_V類型，字節長度在8字節左右，也有部分是2字節，比如巴魯夫的某些產品就是2字節。

M-Sequence code就是對他的編碼，用于在IO-Link報文中進行傳輸，可以看到PREOPERATE模式下有4個code可以用。

03 / OPERATE下的M-Sequence Type

再來看看OPERATE下的M-Sequence Type，其一下子增加了好多code，有21個之多，但大部分都是重復的0，而且沒有2和3這兩個code，很是奇怪。

那么這么多code怎么來區分呢，它是根據OD的字節和PD字節來區分的。

??1~4行：

這里很好辨認，就是OD字節不同，其code也不同，OD的字節只有1,2,8,32四種，沒有其他字節選項；

??5~13行：

OD都是1個字節（除了兼容1.0版本OD是2個字節外），然后根據PD的字節數，拆分為多個類型，覆蓋TYPE_2_1~TYPE_2_V；

??14~21行：

根據不同的OD字節，確定不同的code，但都是TYPE_2_V類型。

02 主站消息處理狀態機

03 從站消息處理狀態機

T1

從Inactive_0到Idle_1，通過消息模塊的初始化實現。

T2

從Idle_1到GetMessage_2，當物理層有中斷，接收到一個報文后，觸發PL_Transfer事件，在OPERATE狀態下動"MaxUARTframeTime"和"MaxCycleTime"定時器。

T3

持續接收報文，每次接到報文需要重新啟動"MaxUARTframeTime"計時器，用于判斷下一個消息是否會超時。

T4

判斷報文接收完畢后，觸發”Completed”事件，進入CheckMessage_3狀態，重置"MaxUARTframeTime"定時器，直到下次收報文的循環再開啟。

T5

檢查接收的報文是否有錯誤，如果沒有錯誤則開始發送相關回應的報文，需要調用OD.ind和PD.ind服務。

T6

編譯并調用PL_Transfer.rsp服務回應報文，此時設備發送響應消息。

T7

檢查主站發送的報文，如果是Checksum Error，則直接回到Idel狀態。

T8

檢查主站發送的報文，如果不是checksun error ，而是M-Sequence的Type錯誤，則通過MHInfo（ILLEGAL_MESSAGETYPE）將錯誤指示給DL-mode處理程序。

T9

在GetMessage_2狀態下，如果超過了最大MaxUARTframeTime，則返回Idle狀態，并重置"MaxUARTframeTime"和"MaxCycleTime"兩個計時器。

T10

超過MaxCycleTime時間，則通知傳感器或者執行器采取相關措施。

T11

從站收到MH_Conf_INACTIVE事件，將狀態更改為Inactive_0。

結語

本篇內容就先介紹到這里，下期我們開始分解PD和OD處理模塊，還請各位關注微信公眾號：Rasight，第一時間獲取內容更新！