记录自己学习iolink协议的过程 内容仅供参考 望大家指正

IO-link

什么叫IOLINK?

IO-Link是一种用于自动化技术的串行数字通信协议。它将传感器或执行器连接到一个可编程逻辑控制器(PLC) 上。在某种程度上,IO-Link使与传感器和执行器相连的通信链路的完全数字化成为可能。关于IO-Link的定义, 见国际标准IEC 61131-9。在当前仅发送二进制状态(开/关)或模拟信号的情况下,可从传感器或执行器读取状态 信息,并将参数化信息写入传感器或执行器。IO-Link不是另一种现场总线,而是一种连接IO-Link设备和IO-Link主站之间的,点对点的通信协议

IO -Link设备优势?

1.超出传统数据传输的抗干扰能力。传统的数据传,像profinet,EtherNet/IP等,它们传感器和控制器传输的信号是模拟量,IO-Link采用的数据化传输,全数据化的信号抗干扰能力强。

2.没有信号失准。传统的数据传输,需要经过模拟量到数据量的转换,专业的说法叫数模-模数转换,而IO-Link是全数 字化传输,我们都知道,转换的过程会导致信号失准,没有数据类型转换,因此没有精度损失。

3.简化布线网络。IO-Link简化了电路连接,只需要一根标准电缆,这大大减小了布线布局的难度,使得布线网络更加简单。这得益于IO-Link主站从站的体积优异,通过装置可以剩下很多布线成本

4.易于报损替换。参数自动导入配置的功能是IO-Link技术的一大特色、。当有io设备达到工作年限,需要替换的时候,不需要繁琐的多次调试,它会自动将参数配置到新的传感器/执行器中。

5.可远程操作。IO-link技术让系统具备远程操作功能,可以通过接头实现pc端操作,将数据存在云数据库中。

6.时刻监控故障断线。IO-Link使数据传输的点对点连接具备交互的能力。

7.智能设备。IO-Link技术的加入,使传感器可以同时传输多个信号,通过从站,主站再到PLC最后把信号带到视觉设备上。这样的数据采集可以释放传感器所有的潜能,因此设备更加智能化,让接线和工作更加轻松。

IO-link框架

IO-Link是第一种与传感器和执行器通信的I/O技术,将作为国际标准(IEC 61131-9)采用。

IO-Link的系统架构的示例图:

IO-Link系统包含以下基本部分:

  • IO-Link主站
  • IO-Link设备(例如传感器,RFID读取器,阀门,电机启动器,I/O模块)
  • 非屏蔽3芯或5芯标准电缆
  • 用于配置和分配IO-Link参数的工程工具

这里需要主要HUB 和从站的区别:

HUB主要是从站带普通IO模块扩展的从站设备 从站不带扩展功能。

IO-Link通信

线缆接口

首先我们来了解一下线缆接口,这是主从之间的直接物理连接,是IOL通信的物理基础。

IOL通信的物理接口采用的是至多五线芯标准线缆(M12-5),也有使用四线芯线缆(M12-4、M5、M8),其中M12-4与M12-5两种线缆是市面上使用较多的,这里我们也重点讲这两种接口。两者唯一差别是M12-5接口比M12-4接口在中心位置多了一根5号线芯。主站必须采用M12-5接口以满足设备可选的M12-5与M12-4接口的通用性。IOL的端口连接方式按照类型划分有两种:CLass-A与Class-B。两者区别见下方定义:

A类端口上的针脚2功能未详细描述,该端口可由生产商自由定 义。B类端口用于需要特殊电源的设备。

针脚2配置为DO时,主站会传输UA电源过来,此时可以提高输出负载。

PIN1-Us:提供系统电源24V+

PIN2-Ua:提供辅助电源24V+

PIN3-GNDs:提供系统电源0V

PIN4-DI/DQ/IO-Link

PIN5-GNDa:提供辅助电源0V

A类端口能够满足绝大部分场景下的应用,比如常用的数字量I/O从站、各类传感器、报警灯、RFID等等,这类产品一般只需要Us供电即可。

B类端口的产品一般用于大功率的执行器,比如电磁阀,此时Us提供系统电源,Ua提供电磁阀线圈吸合的辅助电源。

对于IP65/67中的连接技术,已经明确的一种可行方案是M12插头连接器,其中传感器通常具有4针插头,执行器具有5针插头。

CQ端口可分为几个模式:SIO(输入输出),IOlink模式, Deactivated(停用)。

IO-Link通信方式

IO-Link通讯使用11位UART(通用异步收发器)帧,即1个起始位 + 8个数据位 + 1个奇偶校验位 + 1个停止位。持续时间由传输速率决定。主站发起通讯后,设备必须在tA < 11位间隔内应答。

传输速率 在IO-Link规范V1.1中为IO-Link模式指定了三种传输速率(波特率): COM 1 = 4.8 kbaud COM 2 = 38.4 kbaud COM 3 = 230.4 kbaud(根据规范V1.0可选) IO-Link设备仅支持定义的数据传输速率之一。 根据规范V1.1,IO-Link主站支持所有数据传输速率,并自动适应设备支持的数据传输速率。

IO-Link电平阈值

IO-Link主站供电电压20 ~ 30 V,IO-Link设备供电电压18 ~ 30 V,上升的IO-Link信号高于13 V时,被称为高电平,下降的IO-Link信号低于8 V时,被称为低电平。

IO-Link交互信息框架

基本上讲,进行的交换有四种数据类型:

Process data 过程数据

设备的过程数据在由设备指定过程数据大小的数据帧中循环发送。根据设备的不同,可能有0到32

个字节的过程数据(对于每个输入和输出)。 传输的一致性宽度不是固定的,因此取决于主机。

Value status 值状态

每个端口都有一个值状态(PortQualifier)。值状态指示过程数据有效还是无效。 值状态与过程

数据循环传输。

Device data 设备数据

设备数据可以是参数,标识数据和诊断信息。它们应IO-Link主站的要求进行非周期性交换。 设备

数据可以写入设备,也可以从设备读取。

Events 事件

当事件发生时,设备将事件的存在发送给主机。 然后,主机读取事件。 事件可以是错误消息(例

如,短路)和警告/维护数据(例如,弄脏,过热)。错误消息通过IO-Link主站从设备传输到控制

器或HMI。 IO-Link主站也可以代表其传输事件和状态。 此类事件的示例包括断线或通信故障。设

备参数或事件的传输独立于过程数据的循环传输。 这些传输不会相互影响或损害。

仅在收到IO‐Link主站请求后,IO‐Link设备才发送数据。主站发出非周期数据和事件显式请求后,设备应答;主站发出IDLE报文后,设备发送周期型数据。

这里注意索引大于1时是通过ISDU报文进行数据交互的。

索引和子索引


index-索引

IOL的“索引”是一个16bit数据,最大支持到65535,即表示有65535的参数或者参数组。虽然定义了这么多参数组,但是并非每一个参数组都是通过ISDU交互的。索引0与索引1强制分配给了直接参数页1和直接参数页2,即上图中最下方黄色区域,这两个参数组通过主站MC字节中“通信通道”的“直接参数页”通道进行交互。所以,实际上ISDU的“索引”范围,是从2开始,到65535结束。

索引可以理解为数据存放的地址,也是每一个参数的位置号。例如一个设备有10个参数,数值编号为0-9,index = 1就表示数据存储区域中第二个参数。那么IOL的ISDU交互,就可以按照索引来对2-65535这些位置上的参数组进行读取或者写入的操作。此后IOL主从之间的交互,便都是依靠ISDU里面的部分参数组了。

Suindex-子索引

子索引数据长度只有8bit,所以子索引所能指代的最大位置号就是255,但是最大能是使用的空间只能到233字节。若想要对子索引进行操作,子索引必须从1开始!如果每一个子索引只对应一个字节的数据,那么最大会有232个子索引号;如果大量使用32bit类型的数据,那么子索引号就会少于232;如果较多使用bool类型的数据。那么子索引号就会大于232,但是不允许超过255。至于子索引0,IOL规定,只要主站启用了子索引0,那么会将该索引对应的一整个参数组,按照顺序上报给主站,有一个字节就上报一个字节,有十个字节就上报十个字节,有232个字节就上报232个字节。这是一个总指令。

这里什么意思呢?我个人的理解如下:一个子索引最大能使用的空间为233个字节,你可以对这233个字节进行合理的分配。比如我一个索引对用4个字节 那么233个字节被用完只能有233/4=59个子索引号,如果你定义一个索引对用1个字节就刚好233个子索引号,如果对应1个bit也将子索引号限制在255个。你也可以自由搭配和定义每个索引和子索引的状态。假设开发者在0x50这个索引上存放了一个4字节的参数组,定义子索引数量为5,即:
subindex = 1-->1bit

subindex = 2-->1bit

subindex = 3-->6bit

subindex = 4-->8bit

subindex = 5-->16bit

那么在主站进行ISDU索引交互的时候,如果要对子索引进行精确操作,比如只是对里面某一个参数的数值进行修改,那么指令的发送就是Index = 0x50,subindex = 1或Index = 0x50,subindex = 2...或...Index = 0x50,subindex = 5,按照这种方法读取全部参数就要发送读取指令5次。如果主站想要节省时间一次就将一整个参数组读取进来,那么就可以一条指令Index = 0x50,subindex = 0。

个人总结:索引和子索引其实就是一些存储空间的地址,索引0 1是系统参数页 ,另外ISDU交互是从索引2开始,设备描述IODD文件里面,对使用的索引内容进行定义,说简单一点就是放了一些信息到IODD文件里面,后续通过交互以获取这些资料。例如下面这个索引16就放的vendor name信息。

IODD设备描述文件

IODD(IO Device Description)文件是 IO-Link 设备(传感器、 执行器)的描述文件,由IO-Link设备厂商创建,用于IO-Link工具 识别设备功能,并能够与之建立通讯连接、配置设备参数、调试和诊 断设备

M序列

M序列简介

Message Sequence是IOL主从之间进行循环信息交互的最小报文单元,主站发出一条报文,从站回复一条报文,这样一组报文,称为一个完整的Message Sequence。为方便书写,后文全部用“M序列”字样代替。

 

IOL通信规定了若干个M序列的报文格式,这些格式被称为M序列类型,主站开发过程中,会从设备供应商提供的IODD中获取设备支持的M序列类型,并严格按照此类型发送主站报文从站会检查主站的报文格式,只有确定主站发出报文的M序列类型与设备自身支持的M序列类型一致,设备才会切换到工作状态并接收主站后续的报文。

目前大多数主站和设备都不支持运行中变M序列类型。

关于PD和OD:

Process Data

过程数据,简称PD。是从站在每一次M序列回应时,根据M序列类型定义,携带的固定数量的设备当前运行数值。例如,从站是一个红外测距传感器,那么PD就是检测到的当前距离,从站在每一次回应时,都将当前数值装载到M序列PD的位置上发给主站。

On-request Data

请求数据,简称OD。是主从之间除了固定的PD以外一切数据的总称。指令、索引号、参数值、事件信息等,全都通过OD字节进行交互。主站会在M序列的第一个字节内携带指示信息,告知从站此时要进行的交互类型,如果是直接参数页,那么接下来主站的OD将会是参数值;如果是ISDU,那么接下来的OD将依次为ISDU服务信息、索引号高八位、索引号低八位、子索引、若干参数值、校验码。因此,OD的具体意义,要根据当前交互的具体内容的变化而变化。

M序列控制字(MC)

该字节是从主站发出的第一个字节,包含一位读\写方向、两位通信通道、五位索引地址

b7

b6

b5

b4

b3

b2

b1

b0

R\W

channel

channel

address

address

address

address

address

bit0-4:address-通信地址或数据流计数

在进行直接参数页的读取或写入过程时,用来对直接参数页1与2的字节地址进行索引。bit4 = 0时,bit0-3这四位共16个地址数就是索引直接参数页1的16个数据;bit4 = 1时,bit0-3这四位共16个地址数就是索引直接参数页2的16个数据。

在进行ISDU通信时,bit0-3这四位则变成ISDU数据流的累加计数,从0累加到15再循环。bit4则表示状态控制,配合bit0-3组合成不同的状态指令,指示当前是准备开始还是等待连接等。

bit5-6:channel-通信通道

这两位指示主站当前要对哪一个通信通道进行操作。因为IOL协议字节资源有限并且部分内容并不需要很频繁地交互。因此,设置了通信通道,根据当前要操作的通信通道,在有限的字节内就可以携带不同内容的数据。

  • 00-过程数据;主站当前无任何需求,从站只需要周期上报PD
  • 01-直接参数页;主站将要索引直接参数
  • 10-事件诊断;主站获知从站上报事件,将要获取详细事件信息
  • 11-ISDU;参数读写交互

bit7:R\W-读写方向

  • 主站指示从站,当前主站要进行的操作方向
  • 0-写入 1-读取
M序列类型与主站校验和(CKT)

该字节是主站发出的第二个字节,携带了两位的M序列类型检查指示代码和六位校验和。其中M序列类型指示代码用来让从站检查主站使用的M序列类型是否与从站使用的M序列类型一致,若不一致从站会忽略主站发来的一切数据,也就无法建立稳定的连接。六位的校验和则是一个特殊的求和校验,主从之间都要满足相同的规则,一旦计算得到的校验和不匹配,设备将舍弃数据。

b7

b6

b5

b4

b3

b2

b1

b0

M-Type

M-Type

checksum

checksum

checksum

checksum

checksum

checksum

bit0-5:checksum

整条序列多有字节计算得到的校验和

bit6-7:M序列类型指示代码

00-type0 01-type1 10-type2 11-保留

从站状态与从站校验和(CKS)

该字节是从站回复的消息序列最后一个字节。携带了一位事件发生标志位、一位PD有效位、六位校验和。

b7

b6

b5

b4

b3

b2

b1

b0

Event Flag

PD status

checksum

checksum

checksum

checksum

checksum

checksum

bit0-5:checksum

与主站CKT字节的checksum相同计算方法得到的校验和

bit6:PD status-PD数据有效指示为

该位如果为0,则表示从站可以提供有效的的PD。如果该位为1,则表示整个通信周期内的从站提供的所有PD都是无效的。

0-PD有效 1-PD无效

bit7:Event flag-事件发生标志位

该位是从站向主站上报的,指示从站当前有事件发送,需要主站立即将通信通道切换到事件通道,从设备中读取当前发生的事件详细信息并做出相应的处理。这对设备正常工作极其有必要。

0-没有事件发生 1-有事件发生

M序列3种类型

在知道了M序列各个字节功能之后,就该来认识一下主从之间数据到底是以什么样的格式交互的。IOL提供了多种M序列类型,开发者根据开发设备的需要,选择合适的M序列类型,满足不同的交互需求。

M序列的常规格式为:

主站:MC+CKT+OD_n+PDout_n

从站:OD_n+PDin_n+CKS

这里值得注意的是,PD数据在主站和从站中,会有额外的角标in或者out。这些角标指示PD数据的传输方向。所有PD数据均以主站为目标,PDout为主站发出的PD数据(主站–>从站),PDin为主站接收的PD数据(从站–>主站)。至于“_n”则表示字节数量,若没有数量角标则表示一个字节。

示例:

M序列类型Type_0:

Type_0这个序列类型是所有设备都应该支持的最基本类型。该类型只互相传输一个字节的OD,没有PD。正因为该类型没有PD,设备运行结果不能立即获取,都需要主站完成一次ISDU传输后才能得到,具有一定的滞后性,因此虽然该类型是设备应该支持的最基本类型,绝大多数设备却不会使用该类型

格式:

主站读:MC+CKT

从站回:OD+CKS

主站写:MC+CKT+OD

从站回:CKS

M序列类型Typ_1_x:

Type_1_1:

该类型互相传输两个字节的PD,没有OD,整个PD左侧高位右侧低位,若PD携带的数据为大于8bit,则PDin_1为高字节PDin_2为低字节。正因为该类型不支持传输OD,也使得该类型不能完成常规意义上的ISDU交互。ISDU是要在OD字节上依次携带信息,来指示ISDU服务的目标地址和数据内容,若没有OD的支持,这些信息就没办法实现,因此,该类型适合参数很少,仅使用直接参数页2作为参数交互的设备。

格式:

主站读:MC+CKT

从站回:PDin_1+PDin_2+CKS

主站写:MC+CKT+PDout_1+PDout_2

从站回:CKS

Type_1_2:

该类型与Type_0类似,也是只传输OD,区别是,该类型传输两个字节的OD,没有PD。值得注意的是,在进行页和诊断通信通道传输过程中,只关注第一个OD字节,其余字节的OD用0x00占位。

格式:

主站读:MC+CKT

从站回:OD_1+OD_2+CKS

主站写:MC+CKT+OD_1+OD_2

从站回:CKS

Type_1_V:

该类型是可变消息长度的M序列,其只传输OD,但是OD的字节数量是可以发生改变的,每个周期交互m字节。值得注意的是,在进行页和诊断通信通道传输过程中,只关注第一个OD字节,其余字节的OD用0x00占位。

虽然该类型叫可变长度的M序列,但是实际上,它的长度只可以在8和32这两个长度之间变化,并且定义的变化也并非是在运行过程中任何时候都可以发生变化,而是由开发人员在设备出厂之前,从程序中预先定义好长度,在连接主站后,主站通过获取从站的信息来知道应用的Type_1_V的具体OD字节数量是8还是32。也就是说,完全可以将其理解为,加长版的Type_0。

格式:

主站读:MC+CKT

从站回:OD_1+OD_2+…+OD_m+CKS

主站写:MC+CKT+OD_1+OD_2+…+OD_m

从站回:CKS

M序列类型Type_2_x:

Type_2_x是市面上大多数智能传感器设备选择的M序列类型,因为这一系列类型中,会同时携带若干字节的OD和若干字节的PD,既能实现ISDU传输满足较大参数的读写,又可以实时上报设备的过程数据,使用起来最为方便。

Type_2_1:

该类型每个周期传输一个字节的PDin和一个字节的OD

格式:

主站读:MC+CKT

从站回:OD+PDin+CKS

主站写:MC+CKT+OD

从站回:PDin+CKS


 

Type_2_2:

该类型每个周期携带两个字节的PDin和一个字节的OD。该类型也是较为常见的使用类型,足以满足绝大多数设备的工况。

格式:

主站读:MC+CKT

从站回:OD+PDin_1+PDin_2+CKS

主站写:MC+CKT+OD

从站回:PDin_1+PDin_2+CKS


 

Type_2_3:

该类型携带一个字节的PDout和一个字节的OD

格式:

主站读:MC+CKT+PDout

从站回:OD+CKS

主站写:MC+CKT+PDout+OD

从站回:CKS


 

Type_2_4:

该类型携带两个字节的PDout和一个字节的OD

格式:

主站读:MC+CKT+PDout_1+PDout_2

从站回:OD+CKS

主站写:MC+CKT+PDout_1+PDout_2+OD

从站回:CKS


 

Type_2_5:

该类型携带一个字节的PDout、一个字节的PDin、一个字节的OD

格式:

主站读:MC+CKT+PDout

从站回:OD+PDin+CKS

主站写:MC+CKT+PDout+OD

从站回:PDin+CKS


 

Type_2_6:

该类型携带两个字节的PDout、两个字节的PDin、一个字节的OD

格式:

主站读:MC+CKT+PDout_1+PDout_2

从站回:OD+PDin_1+PDin_2+CKS

主站写:MC+CKT+PDout_1+PDout_2+OD

从站回:PDin_1+PDin_2+CKS


 

Type_2_v:

该类型携带n个字节的PDout、m字节的PDin、k字节的OD。其中n和m的范围是0-32,k的取值范围为1、2、8、32。与Type_1_v一样,虽然名义上是可变长度的M序列,但是其长度都是要在程序内预先定义好,在建立联系的时候主站获取从站的M序列类型与字节数量,而不像MODBUS那样报文内有专门的字节指示本条序列一共有多少个字节来实现动态可变。

格式:

主站读:MC+CKT+PDout_1+PDout_2+…+PDout_n

从站回:OD_1+OD_2+…+OD_k+PDin_1+PDin_2+…+PDin_m+CKS

主站写:MC+CKT+PDout_1+PDout_2+…+PDout_n+OD_1+OD_2+…+OD_k

从站回:PDin_1+PDin_2+…+PDin_m+CKS

M序列类型Type_3:

该序列类型暂不支持。

M序列能力编码与交互字节数量的确定

操作模式(operate)与预操作模式(preoperate)。

在主从刚刚建立链接时,主站会发送系统命令,让从站的系统状态机从空闲模式切换到预操作模式,在该模式下,主站只会读取从站的直接参数页1,获取设备的信息,这其中包括从站最小循环交互周期时间、M序列能力、版本号、供应商ID、设备ID以及PDin和PDout字节数量。在获取完毕这些信息之后,主站发送命令让从站的系统状态机切换到操作模式,开始周期性的ISDU交互。

从站确定主站信息

因为IOL的主站发起交互的机制,从站不会像主站那样,通过指令获取主站信息。所以,在主站获取到从站的信息后,主站就按照刚刚获取的信息去使用与从站相同的M序列类型。而这些信息都是从站自己定义的。那么,从站就是通过获取接收到的主站M序列字节数量,同设备内部定义的字节数量之和作比较,来确定主站发送的M序列类型是否正确。

ok 了解上述信息 我们实际可以通过设备描述文件IODD文件查看对应的M序列的编码

我们可以看到 预操作模式(preoperate)的M序列是TYPE_0 操作模式的M序列是TYPE_2_3

另外一种方式我们可以通过读取参数页1确定M-Sequence Capability值。

例如 我们这里读取参数1 子索引 4 值为 0x01

编码识别字bit7-6保留不用,bit5-4指示设备处在与操作模式下使用的M序列类型,bit3-1指示设备在操作模式下使用的M序列类型,bit0指示设备是否支持ISDU。

这里0x01 的bit5-4 为0 再根据参数页1的输入输出数据确定通信的M序列。比如输入为8bit 输出无这里就是TYPE_2-1.

基于AM243X-LP开发板的IO-LINK主站DEMO演示:

环境搭建和操作演示

使用的工业通信专用SDK: ind_comms_sdk_am243x_09_00_00_03。版本 09.00.00

演示例程:ind_comms_sdk_am243x_09_00_00_03\examples\industrial_comms\iolink_master_demo

TI 开发板作为master和华茂欧特从站hub AUIO M12-601616-NN67通信/与ST从站输入输出模块通信。

基于TI io_link开发板的接口示意图:

连接逻辑分析仪对时序进行采样:

这里需要注意逻辑分析仪设置的波特率为230.4k,CQ线需要反向,偶校验。

IOL是一个仅仅使用一根线路进行数据交互的通信方式。所有信息交互全都依赖C\Q线,这也是上文一再强调,所有的信息交互全都是由主站发起从站随后回复的原因。在主站占用CQ线路发送数据时,从站必须处在接收态,在接收完毕之后才能切换到发送态发送设备数据给主站。

此外,CQ线的电平状态,与串口的RX、TX线路的电平状态反相,这将是开发过程中诊断通信信号准确性的有力依据。

逻辑分析仪的CQ线的串口配置如下:

通过TI官方上位机实现输出控制。

验证的步骤流程如下:

IO-Link Master: Quickstart - IO-Link Master

我们首先读取参数1的内容和上面逻辑分析仪器采样的数据是一致的。

我们打开华贸HUB参考手册进行查看:

我们对索引1子索引3进行配置为0xff。

我们转到PD过程数据写入ff ff 00 00 00 这里只支持16位前两个字节就是控制16位输出 OE是使能 。

我们看输出结果: 16路输出指示灯亮。

数据分析

通信流程分析
建立连接

首先,从站在上电初始化时,CQ线路被初始化为SIO模式。主站通过在CQ线路上进行一次电平翻转向从站的PHY发起一次唤醒脉冲,该脉冲时长典型值为80us。由上图所示,若CQ线路为初始低电平,则翻转电平到高电平,维持75-85us(虽然表格内未标出,但是典型值80us),再切换到低电平等待从站PHY识别到唤醒脉冲。如果初始电平为高电平,则直接翻转电平到低电平,从下降沿时刻开始80us,从站PHY识别唤醒脉冲。

采集的CQ信号如下:

从电平翻转时刻开始,等待500us,之后主站便发起COM3-COM2-COM1的握手序列。

我们来看从站的处理过程:

从站MCU在处理完毕PHY的WURQ信号后,将PHY切换到接收方向,此后主站按照COM3-COM2-COM1的速度发来握手序列,从站接收到握手序列会诊断序列字节数值的准确性。

那么主站发的是什么?主站的握手序列:0xA2 0x00。实际上,从站主要识别的第一个字节0xA2,这包含了主站的信息:0xA2 = 1010 0010。意思是,读方向-直接参数页通信通道-地址为2。握手成功后接下来就是主站读取从站的参数页1的过程。

参数页1读取

以下是对每个参数和相关通信的数据进行进行描述:

MasterCycleTime

直接参数页1地址0x01,在这个位置上,主站会将主站的M序列循环周期事件写入进去,其作用是,给从站一个指示时间,当从站在超过3个该时间之后仍然没有收到一条M序列,从站需要认定与主站断开连接,切换设备状态到FallBack或其他处理。


 


 

不过这个位置的数据比较特殊,其包含了两部分,第一部分是时间基准,是IOL主从提前定义好的时间基准的代码。00表示间隔0.1ms时基,时基基础值为0ms;01表示间隔0.4ms时基,时基基准值为6.4ms;10表示间隔1.6ms时基,时基基准值为32.0ms;11保留不做使用。第二部分是时基系数,数值范围0-63,表示有多少个时基,在解析时,让该系数值乘上时基代码对应的时基,再加上一个时基基础值。以0100 0111为例,时基代码01,表示实际间隔为0.4ms,时基基础值6.4ms,乘数为7。那么主站M序列循环时间就是:6.4+0.4*7 = 9.2ms。
 

·MinCyclTime

直接参数页1地址0x02 对应min cycle time,主站只读此地址数值,用来获取从站的M序列循环周期,此后主站会兼顾从站的性能,以从站所能接收的循环周期性能来发送M序列循环。这里就是一个握手指令以获取从站的最小循环周期。

我们来看这两条指令:可以计算出时间为0.1*0x32(50)=5ms 后续主从交互的时间的确为5ms一个周期。

M-sequenceCapability

编码识别字被四种颜色划分成四个区域,bit7-6保留不用,bit5-4指示设备处在预操作模式下使用的M序列类型,bit3-1指示设备在操作模式下使用的M序列类型,bit0指示设备是否支持ISDU。

直接参数页1地址0x03,向主站展示从站的M序列能力编码识别字,这里0x08 预操作模式下代表TYPE_0模式

RevisionID

直接参数页1地址0x04,表示从站协议栈使用的版本,在从站开发期间请将其固定为0x11。正常情况下只读,但是IOL定义其部分情况下可写,由主站更改其内容,即在更新固件期间将IOL协议栈的版本进行更新,该版本号出现差异,可由主站修改改版本号。然而个人认为,完全可以在程序编辑过程中有开发者管理版本号,减少代码开销,也因此非常多的从站设备都是不支持写入。

·ProcessDataIn

直接参数页1地址0x05,表示设备传输的PDin字节的数量,主站通过读取该参数明确,避免在通信期间发生错误。

这里解释0XC4转换为二进制数据为 1100 0100 我们对用上表 BYTE为 1 length为4 所以为4+1=5 字节。

·ProcessDataOut

直接参数页1地址0x06,表示设备传输的PDout字节的数量,主站通过读取该参数明确,避免在通信期间发生错误。

这个数据的计算方式和ProcessDataIn一致计算的结果也是5字节。

·VendorID

直接参数页1地址0x07与0x08,0x07为高八位,0x08为低八位,两个字节组合表示IOL设备供应商全球唯一ID,主站设备会读取该参数作为确定设备身份的一个环节,如果上位设备做了功能,读取到该参数与IODD定义的VendorID不匹配,主站设备将放弃连接。该ID为IOL联盟授权,请所有IOL设备供应商在生产制造IOL设备之前,务必在IOL联盟申请获得该ID,避免自定义ID号后产生纠纷造成财产损失。

DeviceID

直接参数页1地址0x09、0x0A、0x0B,0x09为第一字节,0x0A为第二字节,0x0B为第三字节。三个字节组合成为供应商内部定义的唯一设备ID,用来区分制造的不同设备。主站设备会读取该参数作为确定设备身份的一个环节,如果上位设备做了功能,读取到该参数与IODD定义的DeviceID不匹配,主站设备将放弃连接。

·FunctionID直接参数页1地址0x0C与0x0D,0x0C为高八位,0x0D为低八位。该参数在目前版本中没有使用,为保留项。

·SystemCommand直接参数页1地址0x0F,在设备不支持ISDU传输时,用来存储主站发送的系统命令,参与从站设备的运行,若从站支持ISDU,主站务必将系统命令交互在ISDU中以避免出现错误。

关于系统命令的解释:

这里的系统命令,是设备开发人员可以定义的参与设备运行的指令,例如LED闪烁控制指令等一些单次执行动作的指令,包括ISDU中也有相同的参数空间执行相同的功能,可以灵活的控制设备运行。

先,从站在初次上电时,IOL处于SIO模式,此时CQ线路无法传输数据,只能进行输入或输出控制,在输出方向下可以设置PNP、NPN或推挽(具体受到PHY芯片功能约束),也因此,此时从站IOL的系统状态机处于非活跃状态。此时主站发出唤醒脉冲,从站在诊断确认唤醒后通过将CQ从SIO模式切换到通信接收(因为IOL只使用一根线路进行信息传输,因此主从之间一方为发送另一方必须为接收),等待主站握手序列发送过来。与此同时IOL协议栈系统用状态机切换到“通信建立”状态,等待握手序列验证通过。

在主站发送握手序列从站验证握手后,主从间达成连接,此时主站进入到上一期说明的直接参数页1的操作中,读取从站直接参数页1存储的信息,同时通过主站命令字节将从站IOL系统状态机切换到预操作preoperate模式。

在预操作模式下,主从之间可以通过带有更长OD字节的M序列进行ISDU交互,主站可以快速获取vendertext、devicetext、productname等很长字节的字符串信息,向上层设备传递,实现设备管理和信息确认。但是需要注意的是,处在预操作模式下,从站不会上报非“通知”类事件,即使有此类事件发生,例如硬件短路造成的过温,从站产生过温事件,只要主站没有将模式切换到操作模式operate,便不会上报事件。这是主站设备开发人员需要注意的事情,切勿在预操作模式内完成交互任务后停留很长时间。

主站获取完毕信息后,通过直接参数页1的mastercommand字节发送数据,控制从站将IOL系统状态机切换到操作模式operate,紧接着,主站通过mastercommand字节发送ProcessDataOutputOperate命令,提示从站此时主站发出的PDout已经是有效数据,从站可以正常解析并信任。主站可以通过ISDU获取到从站所有信息,同时从站也会上报所有发生的事件。主从之间处在稳定的数据交互过程。

在preoperate与operate模式下,主站可以通过mastercommand字节主动发出DeviceStartup或者Fallback命令,让从站IOL系统状态机切换到startup模式或者fallback到SIO模式。

至于MasterIdent与deviceident指令,并非每一次建立连接都会发送,只有在协议栈版本ID发生变化或者主站主动发起时,才会执行该命令。而在执行完毕后,从站会转换状态机到startup模式,等待主站发出preoperate指令或者operate指令切换到对应模式。

读取完参数页之后之后就对从站状态进行切换为预操作状态 具体的命令如下:

我们来分析这个命令:

0x20通过上述MC控制字分析为对参数页1位置0x00进行了主命令写入

·MasterCommand

直接参数页1地址0x00,为主机命令,是主站下发给设备,变更设备运行状态的指令。其指令包含:

指令代码

指令名称

描述

0x5A

FallBack

主站在发出这个指令后,从站从当前状态回落到SIO模式。从站需要在收到命令后的3个主循环周期到500ms之间完成动作

0x95

MasterIdent

当主站发出这一帧指令后,向从站指示主站的版本号高于1.0,在实际应用中,较多的主站不会发送。

0x96

DeviceIdsent

在主站发出该条指令之前,会对从站直接参数页1中的部分可以写的参数进行修改(从站必须支持这些参数写),之后主站发送该命令,从站对上述修改后的数据进行检查。

0x97

DeviceStartup

从站从Preoperate或operate模式切换到startup模式

0x98

ProcessDataOutputOperate

在发送词条命令后,表征主站接下来发送的PD数据将是有效的,在没有发送该指令之前,从站需要认为主站发过来的M序列中PD数据位置的数据均无效。

0x99

DeviceOperate

令从站进入到operate模式

0x9A

DevicePreoperate

令从站进入到preoperate模式

上述指令中较为重要的就是最后两个,从站能否正常运行,完全取决于最后两条指令能否顺利发送到从站。从站在操作直接参数页1期间处在startup状态,这期间不能上报非通知类事件,不能进行ISDU交互,一般不能进行有效的PD交互。必须处在operate状态下才可以完整进行,而从站的状态切换又是完全取决于主站。

发送了0x99这个命令,从设备从预操作状态切换到操作状态。

ISDU和相关报文详解
ISDU:indexed service data unit。

即索引服务数据单元,是IOL通信中最为重要的交互手段,ISDU的支持,使得设备可以通过众多参数实现智能型传感器的使用。通过ISDU,使用者可以与设备进行参数的读写交互,控制设备的运行状态,也可以通过ISDU参数的变更来完成设备的版本规划。即使是一个功能简单的光电开关传感器,设备供应商一样可以设置一些参数,改变传感器的触发距离、触发方式、信号传输方式,实现同一套软件代码适配不同的硬件并满足不同的工况。

ISDU指令的构成

ISDU的指令构成比较复杂,一条指令包含了:服务控制字(I-service服务控制代码+length字节数量信息)、extlength额外数量信息字、index索引高八位、index索引低八位、subindex子索引、data_n携带n字节数据、CHKPDU校验字这些数据。

受制于选取的M序列类型内定义的OD字节数量,主站想要传递一个完整的ISDU指令,就需要传递若干条M序列,在接收到M序列的OD数据后,组装成ISDU指令,然后再去完成指令指代的动作。例如,有一条ISDU指令:一字节服务控制字、一字节index_H、一字节index_L、一字节data、一字节CHKPDU,共计五个字节,想要向设备写入一个字节的参数(data),若选取的M序列类型支持一个字节的OD,那么就需要花费5个M序列,分别将上述五个字节发送给从站,从站组装ISDU指令完成相应动作并做出响应回复。

注意:一条ISDU指令至多携带232个字节的data,不得超过该数量.ISDU 索引和子索引地址有多个方式将其在下面服务控制字里面讲解。

M序列的变化与操作

因为IOL所有的数据交互最小的交互单元就是一帧M序列,ISDU也是在M序列交互基础之上组合成的二次指令。那么在传输ISDU指令的过程中,M序列必然要发生数据上的变化,指代期间所有M序列携带的内容都是ISDU的内容。


 


 

在之前的内容中我们已经知道了M序列的结构。首先是读写方向,对于主站,无论想要通过ISDU执行的是读参数操作还是写参数操作,其根源都是要向从站告知内容,所以,在向从站发送ISDU指令期间,M序列读写方向均为写,在发送完毕接收从站数据时切换为读。第二是通信通道。在执行ISDU交互期间,通信通道恒常保持为ISDU通信通道,以此指示从站。

第三是address地址,见下面FlowCTRL数据流控制字详解。

FlowCTRL数据流控制字

在ISDU交互期间,M序列的address区域共5bit,其名称发生转变,新名称为:FlowCTRL,即数据流控制。这几位既起到控制ISDU数据流收发开始结束的作用,也起到计数的作用。

计数功能很简单,如果FlowCTRL的最高位即bit4为0,那么就表示当前的数值为计数,会从0向上计数到F,然后再次回到0继续计数,只要ISDU没有结束或者中止,就不断循环。需要注意的是,ISDU开始时,count值为1,只在此后的循环中count会循环到0向上计数。

如果FlowCTRL最高位即bit4为1,那么整个FlowCTRL起到控制ISDU的作用。按照功能划分一共有三种指令

指令代码

名称

指令功能

0x10

START

为ISDU指令交互的第一个M序列,表示从此帧M序列开始,以下M序列均为主站此次发出的ISDU指令。同时,也作为激活从站回传ISDU的开始命令,从站只有在收到主站的START控制字之后才会回传从站ISDU,否则将中止此次回传。如果从站未完成此次ISDU指令动作,会返回忙碌响应,主站要保持START不变。

0x11or0x12

IDLE_1orIDLE_2

表示ISDU交互处于空闲状态,主从之间无任何ISDU指令交互。此时从站根据idle控制将状态机切换到待命,等待新的ISDU指令发送。因此,主站在完成以此ISDU交互后,需要在下一次ISDU交互之间插入若干次IDLE指令,让从站重置系统状态机到IDLE,并确保从站也是做出IDLE响应后再开始下一次ISDU交互

0x1F

ABORT

主站指示从站,本次ISDU指令传输中止,接收到的ISDU指令数据请全部清空,接收新的ISDU指令或根据主站通信通道控制切换到其他动作。

通过指令代码我们也能理解,正因为设定START代码为0x10,而紧接着START就是其后的第一帧M序列,所以count在ISDU计数的第一次为1,用以区分。所以,FlowCTRL字的变化过程是:IDLE-START-1-2-3-4-5-6-7-8-9-A-B-C-D-E-F-0......-IDLE。

服务控制字

0000:表示没有ISDU服务,一般为从站较多使用。若字节数量为0则表示从站未进行ISDU交互;若字节数量为1,表示从站忙碌,无法立即响应主站,请主站等待直到返回的控制码具有服务。

0001、0010、0011:这三个代码都表示主站对从站进行参数写入。但是三个代码指代的索引子索引不同。0001要执行的索引号在0-255之间,不操作子索引。0010要执行的索引号在0-255之间,操作子索引。0011要执行的索引号在0-65535之间,操作子索引。这样从站只用通过服务控制码就能快速确定自身该怎么确定ISDU指令数据流每一个字节代表的含义。如果不发送这些控制码,从站分不清楚发过来的字节是索引的低字节还是子索引还是携带数据,很有可能造成错误。0100与0101都是从站针对主站写入动作回复的控制码,表示从站已经收到主站的写入命令并且做出了动作。虽然从站都是意图执行动作,如果参数可以顺利执行写入,从站返回0101积极的正确的响应表示参数写入成功。如果开发人员定义该参数虽然存在但不应在此时进行修改,上报0100负面的响应表示此次参数写入是失败的。主站也会根据从站的响应做出人机显示,提示使用者。

1001、1010、1011:类同写入控制码,为参数读取。

1100、1101:类同写入的两个响应,前者为读取失败,后者为读取成功。

下面以ST的的从站开发板和TI的开发板进行ISDU的通信数据分析:

ISDU报文分析

我们选用ST的从站模块进行测试 建立连接并读取IODD文件(ST官方提供IODD文件)

我们通过TI的上位机软件读取ST从站开发板的的iodd文件的地址17 读取的结果为www.st.com 然后对逻辑分析仪采集的数据进行逐一分析理解ISDU数据传输的过程。

第一组数据如上图所示; 0x70 根据MC控制字表示ISDU 读 地址为0X10表示一个START表示从此帧M序列开始. 0x93服务控制码 1001为参数读取,并且不需要子索引号, length为3。

0x61表示ISDU发送的第一个字节 (01100001 这里的后5位就是ISDU的计数)0x11表示索引为17

0x62表示ISDU发送的第二个字节 0x82 表示CHECK PDU.这里刚好对应上LENGTH 为3.

接下来就是从站开始回应的数据0xf0(11110000) 表示读IDSU START 0X01表示应用繁忙需要等待我们来看官方手册的说明如下图 最后一个.

0xDC (1101 1100) 1101代表读取数据成功 1100 意义:12个字节长度

0XE1 代表ISDU 回复计数值 0x77 代表ascii码w

0x77 代表ascii码w

0x77 代表ascii码w

0x2e代表ascii码.

0x73代表ascii码s

0x74代表ascii码t

-------将内容www.st.com传输完-----------

0XCD为CHECK PDU

至此 一个完整的ISDU请求数据完成 我们需要注意的是 m序列的的类型是什么 以及需要传输的ISDU的方式是什么。

周期性PD数据交互

PD过程数据是周期性交互的数据 每隔一个循环周期交互一次

例如这里是ST的从站输入模块的一个过程数据交互 。

这里采用的是M序列TYPE_2_1 返回的数据是0x00。但是这里不知道为什么要用ISDU通道 而不选择PD过程数据通道 ,还需要后续注意一下. TI 和ST的主站都是这样通信的。

事件

事件分为两种 一种是没有细节的 一种是有细节的。

主机如何知道从机产生了事件呢?答案是通过CKS携带了一位事件发生标志位来提示主站 从站有事件产生。

事件的优先级比ISDU要高 若正在进行IDSU通信 产生事件会优先处理事件。

我们来看官方提供的一个示例:

带细节的事件:

每个位对应一个事件代码,每个事件代码对应一个 事件详情和事件代码 事件代码是一个2字节的数据可以参考附录。根据上面一个事件报文 包括 StatusCode type + EventQualifier +2字节 EventCode。

事件细节描述字 包括有事件的类型 模式 来源等信息

不带细节的事件:

这里无细节只指定了几个事件 映像到EventCode 2就是如上。

我们来看下实例:

0xc0 事件读取 0x81 StatusCode type带事件细节的eventcode1

0x54(01010100) EventQualifier APPLICATION+DEVICE+EVENT_NOTIFICATION+SINGLE_SHOT

2 BYTE EVENTCODE 0X18 0X03

//程序自定义 0x1803 按键事件

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值