前言 – Fins歐姆龍這個協議網上極少有相關的模擬器、Tcp的這一塊倒是有但是Udp的基本都是不可用

1、 Fins協議結構也很簡單 協議分為兩種 一種tcp一種udp

2、 Tcp比Udp的報文會多一層tcp的head頭部

3、 Udp迴應報文在Wireshark中是解析不到（因為他按照UDP的格式去解那指定是解不到）

好長時間沒有更新過部落格了、也比較懶= = 。

一、Read（TCP）

發包

那麼這個就很輕易的看出來這是個tcp的

Magic byte[0]-[3] 46 49 4e 53  ASCII碼：FINS

Length byte[4]-[7] 00 00 00 1a 從command之後的資料長度

Command byte[8]-[11] 00 00 00 02  命令 就是傳送幀

Eroor code byte[12]-[15] 00 00 00 00 沒用，接收結束後不需要檢測錯誤

走完這一層接下來就是fins header這一層

ICF byte[0] 80 請求位 看下面的這張圖

RSV byte[1] 00預留 這些位被系統使用。不在響應中訪問它們 預設為00即可

GCT byte[2] 07此值供系統使用

DNA byte[3] 00 目的網路地址

DNA1 byte[4] 00 目的節點的地址

DA2 byte[5] 00目標單位地址

SNA byte[6] 00源網路地址

SA1 byte[7] fb源節點的地址

SA2 byte[8] 00源單位地址

SID byte[9] 31服務ID 用於標識生成傳輸的程序

Command Code byte[10][11] 01 01 核心部位 這個就是功能碼了

接下來就是data這一部分 這一部分通常攜帶的就是資料

Memory Area code byte[0] b3 磁碟號

Beginning address byte[1][2]00 62 讀取的起始位置

Beginning address bits byte[3] 00  固定為00

Number of items byte[4][5] 00 01讀取的數量

發包看完了接下來看回包

也很為簡單、要讀取資料那麼肯定要回復讀取的內容

而且可以對照一下發包、基本上是一直的無非是data部分不太一樣那我們直接說data部分吧

Response code byte[0][1] 00 00 這個就是Fins協議的返回碼、不論其他包如何變化data部分的第一條一定是這個

Response data byte[2][3]00 00 這個就是讀取到的資料、但是我這個是沒有資料所以是00 00

Fins協議有很多功能、比如說 I/O區讀寫、引數區讀寫、程式區讀寫、但是他們的報文的格式都一樣（除了功能碼不一樣）所以我就不過多介紹截幾張圖就好了

二、讀取控制器狀態

發包

這個就是為讀取控制器的狀態 那麼他就只發送了請求並沒有攜帶任何的資料 所以沒有data部分

回包

前面的就不用看了 直接看data部分就可以了

那麼跟我說的是一樣、他的返回碼是在data部分的第一條。

剩下的就是返回一些系統的狀態了

三、讀週期時間

發包

回包

這種協議的結構很清晰、變化的地方也只有data部分 很容易理解

四、看一下fins的連線吧

發包

46 49 4e 53 是Fins的ASCII碼

00 00 00 0c 則為至此往後的長度

00 00 00 00 則為命令 為客戶端連線服務端

00 00 00 00 沒啥用

00 00 00 00 客戶端的節點地址

回包

清晰無比 Server node address 就是服務端的節點地址 其他都是與發包一致

 五、寫檔案

發包

之前的圖就不截了 跟read都是一樣的

Disk no byte[0][1] e0 01 磁碟號

Parameter code byte[2][3] 引數的程式碼

Filename byte[4][15] 檔名

File position byte[16][19] 00 00 00 00 檔案的位置

Data length byte[20][21]  80 bb file data的長度

File data byte[22]到尾 為要寫的資料

回包

只回復了錯誤碼、00 00 代表的就是無錯誤

其他的的功能與我介紹的也都差不多一致、看懂了read和write其他的也都可以看懂，那麼接下來就再說一下udp的

六、Read（UDP）

發包

可以看到跟tcp的是完全一樣 但是隻是少了個tcp的head頭部

那麼可以對照tcp的去看udp的協議

回包

因為Wireshark沒有解析到所以也沒有什麼價值就不貼出來了。

但是根據他迴應的報文與TCP的迴應報文相比較是為一致。

....

忒懶不寫了

沒有排版

這只是我個人的理解、當然也借鑑了網上的一些文章。如有出處望請見諒。

&n