睿远研究院丨IO-Link M序列解析

前言

上回咱们分解到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，第一时间获取内容更新！