前言 – 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的回应报文相比较是为一致。
....
忒懒不写了
没有排版
这只是我个人的理解、当然也借鉴了网上的一些文章。如有出处望请见谅。