前言
今天我們來好好聊聊ISDU。ISDU是Indexed service data unit的縮寫,這個名字吧,也怪奇怪的,直接翻譯叫索引服務數據單元,聽起來更是怪怪的,小編更喜歡直接稱他為從站的參數。傳感器的各項參數設置都要靠它,它不僅可以設置參數,也可以作為只讀參數來讀取,甚至可以作為命令,基本是無所不能了。
1
ISDU總覽
ISDU與PD數據不同,在請求的狀態下才會發起,一般由主站發起相關請求,比如讀ISDU和寫ISDU。
ISDU的數據可以和PD數據一起傳輸,即在發送PD數據的同時發送ISDU數據,考慮到PD數據的及時性,ISDU作為OD數據,并非一次性發送完畢,而是把數據拆分到多個循環中,發送完畢由接收端來組裝數據報文。
規范規定,ISDU的最大長度為231字節,這是一個很奇怪的數字。反正它一定得小于256。
——ISDU的通用結構——

ISDU中對參數的標識采用了Index和subindex的組合,index的取值范圍從0x0000~0xFFFF,不過大部分都是被規范做了保留和定義,用戶能自定義用的范圍只有0x40~0xFE以及0x0100~0x3FFF。
雖然范圍有限,但絕對綽綽有余了,下圖就是一個大概的劃分。

規范劃分ISDU為2大部分,一部分是系統預定義的,index從0x02到0x3F;另一部分屬于客戶自定義ISDU區域以及行規使用的范圍。
系統參數(System)
0x02~0x0F 系統參數使用
客戶標識(Identification)0x10~0x1F 客戶的標識信息等
診斷信息(Diagnosis)
0x20~0x27 從站的診斷信息
行規參數(Profile)
0x31~0x3F從站行規使用,比如SSP
建議區域(Preferred)
0x40~0xFE 從站設備首選的自定義ISDU空間
擴展區域(Extended)
0x0100~0x3FFF 可以可使用的擴展區域
行規指定(Profile specific)
0x4000~0x4FFF 從站行規使用,比如SSP
2
ISDU的結構
ISDU分為讀/寫兩個操作,這個和前面所講的報文的讀寫是兩個概念。報文的讀寫是指OD是主站發出還是從站發出,而ISDU的讀寫就是我把參數設置到從站內,還是從從站讀取ISDU數據。
無論是讀ISDU還是寫ISDU,一開始都是寫方向的報文,可以理解為給從站發送命令,因為讀寫ISDU就是一個命令。
命令發送完畢,就是讀報文,這時候可能是讀取ISDU的具體數值,也可能是從站對寫ISDU的確認報文,這些報文是由從站發給主站的,所以是讀操作。
理解完讀寫ISDU的命令后,我們看詳細的報文結構

I-Service作為ISDU的第一個報文的前4個bit,規定了讀寫方向和具體的模式,有用的就3個寫,3個讀,還有一個no service。我們簡化它就是如下的公式:

因為長度既用了第一個字節的后4bit,考慮到231字節的ISDU,又用了一個字節,導致感覺IO-Link又想節約字節,但又沒有節約到位,增加了協議棧的復雜性。
如下圖所示,這個ExtLength是若隱若現,猶抱琵琶半遮面;有時候有,有時候又沒有,所以造成一個怪現象,你會發現,length這個字段從來沒有16這個數值。

length是一個感覺雞肋的一個定義,現在這個index和subindex又是類似的,你這統一定義有index和subindex不就完了嗎,非得定義一會有,一會沒有,增加代碼開發復雜度,又沒有感覺字節節約到哪里去。下圖給一個直觀的感受。

3
ISDU的FlowCtrl機制
ISDU比較重要的一個機制是FlowCtrl機制,即當一個ISDU需要通過多個M-Sequence來傳輸時,需要流控進行消息計數。
每次傳輸完一段數據,FlowCtrl就需要+1,如果FlowCtrl沒有變化,說明上個傳輸的數據對端沒有收到或者收到數據有誤,需要重發。主站是ISDU的發起方,因此主站需要通過ISDU的數據長度和FlowCtrl兩個組合進行傳輸完整性的判斷。
FlowCtrl的詳細定義如下:

簡化了看就是如下圖:

ISDU的通道是0x11,結合讀寫位和地址位的首位,有如下幾個組合:
0xFx(1111xxxx):
寫ISDU命令(start/IDLE)
0xEx(1110xxxx):
寫ISDU命令(count)
0x7x(0111xxxx):
讀ISDU命令(Start/IDLE)
0x6x(0xx0xxxx):
讀ISDU命令(count)
舉例來看:

第一行 70 52 表示主站要寫一個ISDU命令,93 15 86表示ISDU index 15的命令,這個命令就是讀取序列號
第二行,主站要讀取從站的回應了,這時候從站尚未回應,則返回系統忙
第三行,主站再次讀取從站的ISDU回應,這時候從站準備好數據,準備輸出,按照ISDU res+的格式回應。
首先是D113 表示正確回應,字節數在19個。后續跟著相關數據。30 31 34 38 34 32 表示ASCII,轉換成字符串就是01 48 42,最后一個2E是校驗碼。
第四行和第五行就是接著第三行沒有輸出完的數據繼續輸出。前面兩個字節,E1 70和E2 40都是主站發出的數據,表示繼續讀取從站的數據。
整體ISDU回應的數據就是01 48 42 52 b0 00 02 D9。
結語
OK,本篇詳細介紹了ISDU的報文結構以及讀寫的示例,下篇就ISDU的狀態機做個簡單的介紹,期待各位看官持續關注!
-
IO-Link
+關注
關注
2文章
195瀏覽量
20534 -
IO-Link收發器
+關注
關注
0文章
13瀏覽量
6279
發布評論請先 登錄
睿遠研究院丨IO-Link規范解讀(三):物理層概覽
睿遠研究院丨IO-Link規范解讀(七):消息處理模塊
睿遠研究院丨IO-Link規范解讀(八):M-Sequence Type 與消息處理狀態機
睿遠研究院丨IO-Link規范解讀(十一):ISDU狀態機與EVENT事件
睿遠研究院丨IO-Link規范解讀(十二):SM模塊與CM模塊解析
睿遠研究院丨IO-Link規范解讀(十三):參數模塊解析
IO-Link 節點簡化應用設計
什么是IO-Link
解讀IO-Link 1.1版的三個全新特性
IO-Link通信系統應用概述 ADI在IO-Link Master設計中的優勢
初識IO-Link及IO-Link設備軟件協議棧
虹科直播回放 | IO-Link技術概述與虹科IO-Link OEM
睿遠研究院丨IO-Link規范解讀(二):IO-Link通信技術概述

睿遠研究院丨IO-Link規范解讀(十):ISDU詳解
評論