Openprotocol协议解析1

简介

开放协议是远程通信接口。它是独立于系统平台的，可以在Linux、PLC、打印机和所有Windows上实现。
开放协议同时支持串行和以太网连接。
本文是以阿特拉斯扭矩枪为例，说明开放协议的使用。

本文用到的术语表。

术语	定义
控制器（Controller）	支持开发协议的服务器
接收器（Integrator）	接收器可以为电脑、PLC或打印机。接收器安装使用开放协议的应用。
报文（Message）	一条报文由三部分组成：头、数据字段和报文结束符。根据通信类型，发送或接收的包包括报文和报文前后标识符的封装。
MID	由四位数字组成的报文ID，例如0052。
MID版本	一个MID有多个版本。默认版本正为1。一个MID通常被修改为包含更多的数据，从而增加了报文的长度。添加了中期版本以确保向后兼容。
订阅（Subscribe）	订阅是控制器将特定数据发送到订阅者或每次生成的多个订阅者。
取消订阅（Unsubscribe）	取消订阅是订阅方取消订阅，数据将不再从控制器发送。
PSET	一组用于工具拧紧的参数。

通信方式

开放协议可以使用以太网或串行通信。开放协议是全双工的协议，这意味着数据可以同时发送和接收。每个通信设备必须能够同时操作收发设备。

• 以太网通信
  控制器通信的默认端口是4545，通信流程如下：

1. 控制器接听4545端口。
2. 接收器作为客户端连接控制器。
3. 控制器接受连接。
4. 接收器发送MID 0001通信开始。
5. 控制器带有 Cell ID，通道ID和控制器名称的MID 0002应答通信开始确认。

• 串口通信
  包含两个串口协议：串行ASCII协议；具有3964R握手的串行ASCII协议。

报文结构

通过通信链路发送的大部分报文是ASCII格式的。一些信息也可以包含二进制数据，可以在具体的MID命令中查看。
一条报文由三部分组成：报文头、数据字段和报文结束符。

报文头

报文头包含20个字节，如下表所示：

消息部分	字节数	参数含义	参数值
报文头	1-4	长度	这个长度包括报文头和数据字段，但是不包含Null结束符。报文头包含报文长度信息，长度用ASCII数字表示，范围为0000-9999. 使用消息链接功能时，请注意长度表示每个报文部件号的长度。当一个ASCII部分后面跟着一个二进制部分时长度是报文的总长度。
	5-8	MID	MID由四个ASCII数字（0...9）字节组成，代表报文类型
	9-11	版本值	MID的版本由三个ASCII数字（0...9）字节组成。MID版本在每个MID中是唯一的，可用于不同的版本使用相同的MID的情况。使用版本号，接收器可以实现对同一MID的不同版本的订阅或请求。默认情况下MID版本号为三个空格。如果需要初始的MID版本(版本1)，则有有三种不同的方式，发送三个空格或者000或001。
	12	无Ack标志	仅用于订阅MIDs。 无Ack标志用于设置订阅信息。如果无响应标识在订阅信息中没有设置，意味着订阅者将响应控制器推送的每个报文（可靠模式）。 如果设置了，控制器只推送订阅的信息，不等待订阅者返回的接收确认信息（不可靠模式）。 注意!使用序列号处理时无效！
	13-14	站点ID	控制器有多个站点配置时指定站点报文地址。站点ID由两个ASCII数字（0...9）字节组成。两个空格代表站点1（默认值）
	15-16	轴ID(Spindle ID)	在多个Spindle连接相同的控制器时，指定Spindle报文地址。Spindle ID由两个ASCII数字（0...9）字节组成，两个空格代表spindle 1（默认值）。
	17-18	序列号	来自OP规范2.0.1-99-1。与MIDs 0997和0998在“连接级别”上确认。 空格或0和非1-99时不使用。 在通信重启MID 0001/MID 0002时，它必须被设置为1, MID 0002中的信息会告诉你是否可以使用。它是向后兼容的，如果使用它将代替无Ack标志和所有特殊的订阅数据消息Ack MIDs。
	19	报文部件组数	来自OP规范2.0。链接功能最大为9 =可以发送9 * 9999字节的消息。 〜90 kB。当消息长度超过最大长度9999时使用。空格或零时不使用。
	20	报文部件数	来自OP规范2.0。链接功能，消息长度> 9999时可以为1-9。不用于空格或零。
数据区	21	21-Length	请参阅变量数据字段的修订或数据模式
报文结束符		查看参数值列	以ASCII表示的整个消息结尾= NULL。 OP规格2.0 在ASCII消息的第一部分，然后是二进制部分，在二进制部分的第一个数据开始之前，ASCII部分以NULL字符结束。

OP2.0使用的新MID编号

所有新创建的MIDs必须使用如下定义的MID号组。它分为数据类型/功能类型组。适用于OP规范2.0版或更高版本。

这些是MID编号系列的现有组：

• Job message MID 600-699
• Tool messages MID 700-799
• VIN Messages MID 800-899
• Tightening result messages MID 900-999
• Alarm messages MID 1000-1099
• Time messages MID 1100-1199
• Multi-spindle status messages MID 1200-1299
• Multi-spindle result messages MID 1300-1399
• User interface messages MID 1400-1499
• Job messages, advanced MID 1500-1599
• Multiple identifiers messages MID 1600-1699
• I/O Interface MID 1700-1799
• PLC user data messages MID 1800-1899
• Selector messages MID 1900-1999
• Tool Location System messages MID 2000-2099
• Controller messages MID 2100-2199
• Statistic messages MID 2200-2299
• Automatic/Manual mode messages MID 2300-2399
• Open Protocol Commands Disabled MID 2400-2499
• Parameter Set Messages MID 2500-2599
• New groups from MID 2600.
  因此，当希望在现有组或新组中传输新数据类型时，需要指定新的MID。

OP2.0中ASCII和二进制数据的MID

二进制数据的MID有一个ASCII数据部分和一个二进制数据部分。ASCII部分总是与报文头一起先发送，并以NUL字符结束。此后，二进制数据开始，在二进制数据之后不发送NUL字符。

标头中长度是消息的总长度，即ASCII数据的长度（包括报文头，NUL字符）和所有的二进制数据。

在报文中二进制数据的MIDs如下所示

MID	名称	描述
0090	MID 0900跟踪曲线数据消息	所有曲线样本以二进制格式发送。

OP规范2.0中的序列号功能

序列号与MID 0006和MID 0007一起用于在应用链路层进行通信确认。序列号设置为1-99-1等。

如果字段设置为1-99（而不是空格或者0）时使用序列号。

在通过MID 0001 / MID 0002交换进行通信重新启动时，必须将序列号初始化为01，以作为用于数据传输的第一个序列号和期望在第一次接收数据消息时使用的第一个序列号。

在MID 0002中，信息是否可以使用。请参阅有关MID 0002的说明。

如果使用，它将覆盖No Ack标志和所有特殊订阅数据消息的ACK MID。

使用序列编号以及MID 0006和MID 0007确认的好处是，无需应用程序级别的性能依赖性或通信确认延迟，就可以实现对收到消息的更快确认。

此外，还可以识别重发，避免使用MID0004、MID 0005或直接请求应答数据的应用程序级别已经处理但尚未完全执行和确认的命令、请求或订阅加载控制器。

使用序列号功能意味着所有消息(请求、命令或订阅)将在应用程序链接级别(MID 0007)上得到快速确认，这也意味着消息已被正式检查并正确接收。

如果格式不正确，则将使用MID 0006确认消息，并使用错误代码告诉接收者原因。

如果正确接收到所需的控制器操作将在应用程序级执行，并且稍后将通过MID 0005消息或直接请求应答数据消息响应成功执行操作。

如果操作失败，MID 0004消息确认响应。

在这种情况下，MID 0004和MID 0005不再被视为确认者，消息将由MID 0006或MID 0007确认。

来自OP规范2.0的报文链接功能

报文链接功能用在报文长度超过9999个字节的情况。另一个原因可能是，使用开放协议的设备不太可能有巨大的缓冲区，但无论如何都希望有可能发送巨大的消息。

链接消息是被划分为若干个传输的消息，每个传输由消息头和整个消息数据字段的一部分组成。

要放入部件数据字段的下一部分消息的断点必须与参数数据字段大小对齐。

消息数据字段的下一部分总是在消息头之后的第21字节处开始。

“消息部分”字段的数目最多可达9个，如果与空格不同则使用该字段。有效值为1-9。这样就可以发送99999字节的消息。~ 90 kB。
（Number of Message parts” field can be up to 9 and are used if different from space. Valid values are 1-9.
This gives the possibility to send 99999 bytes messages. ~ 90 kB）

静态数据字段使用

静态数据字段是表示数据的ASCII数据。数据包含一个由MID决定的参数列表，每个参数由一个ID和参数值表示。注意，ID总是2字节。数据字段可以为空，也可以包含最大9979字节。

数据字段内容

消息部分	字节数	参数含义	参数值
数据字段	21-22	01	参数ID(00…99)，长度为两个字节。参数ID在左边用ASCII字符“0”填充
	23-	参数01的值	参数值由参数选择（固定的字节数）定义。 ASCII数字（'0'...'9'）或0x20到0x7F十六进制之间的ASCII字符。 如果仅通过ASCII数字指定参数值，则在参数值的左侧填充ASCII字符“ 0”。 如果参数值是由ASCII字符指定的，则参数值将在右边用空格（ASCII字符0x20 Hex）填充。 如果不支持“参数”值，则整个参数字段均用空格（ASCII字符0x20十六进制）填充。
	n-	02	参数02
	n+2-	参数02的值	参数02的值
		03	参数03
		参数03的值	参数03的值

静态数据字段实现规则

必须发送数据字段的所有参数。

每个消息的数据字段都可以通过添加MID修订版本进行将来的修改。新修订版可以包含新参数或数据字段的长度增加。

在实现现有的具有多个版本的MID时，必须支持所有版本。

如果在尝试使用现有MID时可以将不支持的参数确定为从不支持，则必须定义一个不包含这些参数的新MID，从长远来看，这将提供一个更简洁的界面。

默认情况下，数据部分中发送的所有扭矩和角度值均以Nm和度为单位发送。 1圈代表360度。

来自OP规范2.0的可变数据字段的使用

可变数据字段可以使用完全可变的方式发送数据。
该模式将替代对静态字段实现规则和修订处理的所有使用。

变量字段模式中的数据可以放在消息头之后的任何位置，也可以不发送。应该发送哪些数据是每个产品中的配置问题。

单元名称和数据类型名称是在与产品无关的全局名称空间中定义的。可以在本文档的后续版本中定义新名称。

有关单元名称、参数id和数据类型，请参见第6.0章。
如果使用MID描述，会对它们进行描述（In each MID description they are also described if used）。

如果使用，则在每个MID描述中描述此模式的使用。

可变数据字段内容

消息部分	字节数	数据类型	描述
数据字段数量	3	UI	在报文中的可变数据字段数量。如果数据字段不存在，则发送“000”。必须是变量数据字段部分的第一个
数据字段	可变		此部分是重复数据字段的次数。如果数据字段数= 000，此部分不发送。
			参数	大小（字节）	数据类型	描述
			参数ID(PID)	5	UI	可用的PID可能因系统类型的不同而不同
			长度	3	UI	数据值的长度
			数据类型	02	UI	数据值的类型
			单元	3	UI	数据单元
			步骤	4	UI	结果变量的步骤号。如不相关，以0000发送
			数据值	长度		数据值

注意!所有带字符串的字段都向左调整并用空格填充。所有数值字段都是右调整并填充0

报文结束

报文结束符为空。

报文结束内容

消息部分	字节数	参数名	参数值
报文结束	1	报文结束	如果消息是纯ASCII的，则消息是NUL终止的。NUL终止不包括在消息长度中。在本手册中，这是用NUL ASCII 0x00来说明的。 从OP规范2.0开始:如果使用变量数据字段，则可能有二进制的数据字段，然后使用数据字段的长度作为消息结束确定。

注意！在消息中发送二进制数据之前，应始终有一个NUL字符。

实施和通信准则

应用程序启动消息交互

接收器和控制器建立连接后，发送MID 0001报文，如果OK，控制器返回MID 0002。如果NOK，控制器返回带有错误代码的MID 0004。

消息确认方法

使用两种不同的消息头，则有两种不同的确认方法，分别叫“应用层确认”和“链接层确认”方法。接收器必须选择这两种方法中的一种。

该协议允许实现者以某种方式来实现“链接级别确认”，以便可以选择在消息级别使用任一方法。

如果以这种方式实现并且控制器支持序列号和链接级别确认，则接收器可以通过将序列号设置为零来选择不对特定消息使用序列号和链接级别确认。

在这种情况下，接收器必须等待命令、请求和订阅的应用程序级响应。如果启动是用Rev 6或更高版本完成的，那么响应仍然是按顺序编号的，并且需要在接收器端进行链路级别确认和顺序编号处理。

同样的方法也适用于控制器->接收器的方向，具体取决于接收器端的实现。

如果可能在消息级别上混合使用序列号/非序列号消息，请在每个控制器的参考文档中进行描述，因为这取决于实现。
下面将介绍这两种方法。

应用级别确认方法

在此方法中，有两个用于确认的MID。 MID 0005是正确响应，是在成功执行命令或订阅操作时给出的。

对于请求，正确响应本身就是请求的数据。

MID 0004是带错误代码的否定响应，如果请求、命令或订阅操作由于某种原因失败，则给出该响应。

一次只能发送一条未处理/未确认的消息，然后才能发送下一条。换句话说，在发送下一条消息之前，接口必须等待MID 0004或MID 0005确认或直接的REQUEST REPLY DATA确认，这取决于发送的请求，命令或订阅的类型。

与此方法结合使用时，可以使用No确认标志从接收器端确认订阅数据消息。

在MID 0004响应下，无法继续处理序列中的下一条消息，请参见“生产消息序列”一章中的更多信息。

如果在响应超时之前未收到命令的应答，则集成商最多应重新发送3次命令。 3次后，连接被视为丢失，必须建立新的连接。

这种方法的缺点是，应用程序级性能的依赖性建立在有时非常缓慢的通信确认上，这对于处理已经在控制器中处理过的命令的重传也是一个问题。

来自OP规范2.0中的链接层确认方法

当使用报头序列编号MID 9998和MID 9997时，用于快速识别，开放协议的实现由应用链路层和应用层组成。

OBS！由于存在大量的客户报告的问题，因此实际上建议使用该方法代替应用方法确认，这几乎是强制性的，OBS将解决该问题！

在应用链接层，MID 9998和9997被处理，并且一次只允许一个未确认的消息。

在本例中，MID 0004和MID 0005消息作为应用层消息处理，并由MID 9998或MID 9997确认消息确认。

订阅数据消息的所有特殊确认消息均不能使用。

当使用MID 0001/MID 0002交换重新启动连接和通信时，序列号必须初始化为01，作为第一个用于数据传输的序列号，以及第一个用于接收数据消息的序列号。

在使用MID 0001/MID 0002交互进行连接和重启通信时，必须将序列号初始化为01，以作为用于数据传输的第一个序列号和期望在第一次接收数据消息时使用的第一个序列号。

因此，序列号必须在接收器-控制器通信的每个方向上独立持有和处理，并通过1-99-1进行包装。

一旦报文头和长度检查通过并且接收到的序号+1，就应立即完成MID 9998或MID 9997的数据消息确认。新的序号将成为下一个数据消息中的下一个预期值。

如果报头检查失败，则应使用MID 9998确认数据消息，其中接收到的序列号为+1，和带有错误类型的错误代码。

如果再次接收到具有相同序列号的已确认数据消息，则该消息是重传，并且必须以与上次相同的确认进行确认，但是对于应用程序级别处理，不应采取任何措施。

如果数据消息的序列号不是重传的，也不是下一个期望的序列号，则确认应为带有错误代码的MID 9998，并且序列号设置为下一个期望的序列号，告诉发送方下一个期望的序列号是什么。在这种情况下，正确的操作是执行会话断开/重新连接以进行同步。

如果发送的数据消息在一定的超时时间内未收到MID 9998或MID 9997应答，则该数据消息应最多重传3次。如果此后未收到应答，则断开连接并尝试进行新的连接，从而从头开始重新编号。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mu6sQoTX-1571885776536)(images/普通通信.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sQFPbx1U-1571885776538)(images/No_Ack_received.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HeADAxeO-1571885776539)(images/Wrong_sequence_number.png)]

会话控制连接

在一些控制器中有可能几个接收器同时连接到控制器。这些连接可以分为Actor、Viewer(查看连接器)或Classic。

这些类别代表MID类型的类别权限。

对于Actor类型的连接，接收器拥有执行订阅、命令和请求的所有权限，如果连接，将阻止Viewer连接器的“命令”权限。

Viewer连接器仍然可以执行请求和订阅。

如果存在许多Classic连接，并且接收器是Actor连接，则应将这些Classic连接转换为Viewers。

只要只有Classic连接，它们都拥有所有权利，并且接收器必须负责防止多个连接可以同时执行命令。

当使用Actor连接类型时，这应该在控制器实现中处理。

例如，控制器实现可以为不同于Viewer和Claasic连接类型的Actor通过不同的TCP端口来实现会话控制。

在控制器开放协议规范文档中说明了实际实现方式。

以下是会话控制功能对控制器的总体要求:

1. Actor会话连接将无法执行来自其他连接的命令。

2. 在与Actor会话连接时，仍然可以从转换为Viewer的所有其他连接进行订阅和数据请求（上传）。

3. 在Actor会话断开连接的情况下，命令仍将可以从Classic Sessions（从Viewer session转换）执行。

4. 总的会话连接的最大值应该是有限的。

5. 尝试超过有限的会话连接将导致mid0004出现错误代码16“连接被拒绝”。

6. 当存在Actor连接时，尝试在Classis/Viewer连接上执行命令将导致mid0004出现错误代码92 =“命令被禁用”。

7. 尝试另一个Actor连接将导致mid0004和错误代码35“其他Actor客户端已经连接”

8. Actor会话连接将无法执行来自其他连接的命令。
   2.在与Actor的会话连接时，仍然可以从转换为Viewer的所有其他连接进行订阅和数据请求（上传）。
   3.在Actor会话断开连接的情况下，命令仍将可以从Classic Sessions（从Viewer session转换）执行。
   4.总体上最大会话连接数应受到限制。
   5.尝试超过有限的会话连接数将导致MID 0004出现错误代码16“连接被拒绝”。
   6.当存在Actor连接时，在Classis / Viewer连接上尝试命令的结果将导致MID 0004，错误代码为92 =“命令已禁用”。
   7.尝试进行另一个Actor连接将导致MID 0004出现错误代码35=“已连接其他Actor客户端”。

订阅事件

该示例显示了MID 0060上一次拧紧数据订阅和MID 0061上一次拧紧数据上传的顺序。必须实现这些消息才能获得结果。先决条件:已经建立了通信会话。该示例只显示发送的数据，而不显示协议帧。虚线用于在MID 0006和MID 0007确认的情况下使用序列编号。这些图未显示按顺序编号使用时的不同层。

1. 接收器发送MID 0060订阅最新的拧紧结果数据。订阅是针对版本6。
2. 如果使用序列编号，控制器发送MID 9997，如果命令接收，发送MID 0005命令(如果使用序列编号，作为应用程序消息)