具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

首先对本发明所涉及的名词进行解释：

可编程逻辑控制器(Programmable Logic Controller，简称PLC)：是一种采用一类可编程的存储器，用于其内部存储程序，执行逻辑运算、顺序控制、定时、计数与算术操作等面向用户的指令，并通过数字或模拟式输入/输出控制各种类型的机械或生产过程。

套接字SOCKET：应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。套接字允许应用程序将I/O插入到网络中，并与网络中的其他应用程序进行通信。网络套接字是IP地址与端口的组合。

仓库设备控制系统(Warehouse Control System，简称WCS)：设备控制是指一种用来协调、调度底层物流设备作业的机制。WCS将负责控制实物的流动。

OPC UA：基于OPC基金会提供的新一代技术，提供安全，可靠和独立于厂商的，实现原始数据和预处理的信息从制造层级到生产计划或ERP层级的传输。通过OPC UA，所有需要的信息在任何时间，任何地点对每个授权的应用，每个授权的人员都可用。这种功能独立于制造厂商的原始应用，编程语言和操作系统。OPC UA是目前已经使用的OPC工业标准的补充，提供重要的一些特性，包括如平台独立性，扩展性，高可靠性和连接互联网的能力。OPCUA不再依靠DCOM，而是基于面向服务的架构(SOA)，OPC UA的使用更简便。现在，OPC UA已经成为独立于微软，UNIX或其他的操作系统企业层和嵌入式自动组建之间的桥梁。

此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

本发明实施例提供的数据通信方法，具体应用于仓储物流系统中的可编程逻辑控制器PLC和仓库设备控制系统WCS。仓储物流系统的整体架构如图1所示，仓储物流系统大致可分为三个层次，最上层是仓库管理系统WMS，负责仓储业务逻辑的处理；最下层包括是具体的可编程逻辑控制器PLC控制的仓库设备等；仓库设备控制系统WCS是位于WMS与PLC之间的中间层，负责协调、调度底层的各种仓库设备。

目前PLC与WCS之间的一种通信方式是：在WCS服务器上安装OPC UA服务器。通过OPC UA服务器从仓库设备中采集数据、定期更新，WCS通过接口文件从OPC UA服务器中提取数据，需要根据仓库设备的操作系统购买安装OPC UA服务器软件，现场部署成本很高。为了降低成本，PLC与WCS之间多采用另一种通信方式：通过建立套接字Socket连接，定义通信报文，实现PLC与WCS之间的数据交互。目前，PLC与WCS通过Socket连接进行通信时报文长度固定，为了满足需求，报文长度固定为所需的最大值，严重浪费通信带宽，带宽占用率低。

本发明提供的数据通信方法，用于PLC与WCS之间的数据传输，可以应用于PLC或者WCS，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本发明的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。

图2为本发明实施例一提供的数据通信方法流程图。本发明实施例针对现有技术中PLC与WCS通过Socket连接进行通信时报文长度固定，报文长度固定为所需的最大值，严重浪费通信带宽，带宽占用率低的问题，提供了数据通信方法。

本实施例中的数据通信方法涉及到报文的发送端和接收端，发送端在需要接收报文时也可以作为接收端，而接收端在需要发送报文时也可以作为发送端。在实际应用中PLC和WCS都同时具有发送端和接收端的功能。如图2所示，该方法具体步骤如下：

步骤S101、当需要发送指令数据时，发送端根据待发送指令数据对应的指令类型，生成包含待发送信息及对应的指令类型的第一报文，第一报文的长度与待发送信息对应的指令类型对应的预设报文长度一致，其中至少两种指令类型对应的报文长度不同。

本实施例中，报文的结构如图3所示，报文包括报文头、是否需要应答、接收方设备号、指令类型、指令序号、指令数据和报文尾。其中指令数据是指待发送的数据信息，指令类型是指指令数据的类型。指令序号用于唯一标识一个报文，不同的报文对应指令序号不同。

为了描述方便，本实施例中报文的指令类型是指报文中包含指令类型，也就是报文中携带的指令数据对应的指令类型；某一指令类型的报文是指报文中包含该指令类型的报文。

示例性地，指令类型可以包括：注册、应答、任务、任务状态上报、设备状态上报等类型。

对于不同的设备，所需要发送的指令数据的指令类型可能不同，也就是不同的设备能够发送的报文的指令类型可以不同。例如，PLC需要向WCS发送的报文对应的指令类型可以包括：应答、任务状态上报和设备是否可用等，WCS需要向PLC发送的报文对应的指令类型可以包括：注册、应答和下发任务等。

本实施例中，同一指令类型对应的报文长度固定，可以预先设定每一个指令类型对应的报文长度。不同的指令类型对应的报文长度可以不同，至少两种指令类型对应的报文长度不同。

步骤S102、发送端向接收端发送第一报文。

步骤S103、在接收到第一报文之后，接收端根据第一报文的指令类型，验证第一报文的长度是否正确，其中至少两种指令类型对应的报文长度不同。

由于不同指令类型的报文的长度可以不同，接收端在接收到第一报文之后，需要根据第一报文的指令类型对第一报文的长度进行验证，只有在第一报文的实际长度与第一报文的指令类型对应的预设报文长度一致时，确定第一报文的长度正确。

步骤S104、若第一报文的长度正确，则接收端对第一报文进行处理。

在对第一报文的长度正确之后，才可以对第一报文进行后续地处理。

本实施例中，对接收到的报文的验证除了对报文长度的验证之外，还可以包括先用技术中对接收到的报文的任意其他内容的验证，本实施例此处不再赘述。

例如，在接收到第一报文之后，对第一报文的验证还可以包括：接收端对第一报文中的接收方设备号和结束符等进行验证，在验证接收方设备号和结束符均正确之后，才对第一报文进行后续地处理。

另外，在对接收到的第一报文验证通过之后，对第一报文进行后续地处理具体可以采用现有技术中对接收到的具有相同功能或者类似功能的报文的处理过程实现，例如保存报文中携带的数据，修改报文对应的状态信息等等，本实施例此处不再赘述。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

图4为本发明实施例二提供的数据通信方法流程图；图5为本发明实施例二提供的数据通信方法的整体流程图。在上述实施例一的基础上，本实施例中，以仓储物流系统可以是穿梭车系统为例，在穿梭车系统中，PLC是客户端，WCS为服务端。当PLC与WCS网络硬件正常时，PLC会主动尝试创建与WCS的Socket链接。链接建立成功后，开始报文交互。

本实施例以PLC向WCS发送注册报文为例，对数据通信方法的一种实施方式进行说明，本实施例中，第一报文对应的指令类型为注册类型，第一报文为注册报文，第二报文对应的指令类型为应答类型，第二报文为对第一报文的应答报文。如图4和图5所示，该方法具体步骤如下：

步骤S201、PLC根据注册类型对应的第一预设报文长度，生成注册报文。

在进行设备注册时，PLC将生成注册报文所需数据拼接，生成注册报文。注册报文中是否需要应答的值为需要应答，接收方设备号为WCS的设备号，指令类型为注册类型，指令数据可以为注册所需的信息。

步骤S202、PLC将注册报文对应的是否需要应答状态标记置为需要应答状态，并将发送状态标记置为需要发送状态。

其中，报文对应的是否需要应答状态标记用于表示该报文是否需要接收端应答，包括需要应答状态和不需要应答状态。

示例性地，注册报文对应的是否需要应答状态标记可以用1标记位(bit)来存储，该标记位的值为“true”(或者“1”)表示需要应答状态，该标记位的值为“false”(或者“0”)表示不需要应答状态。

示例性地，可以使用报文需要应答状态字Need_Response来存储各类报文是否需要应答状态标记的信息。例如，如图6所示，报文需要应答状态字Need_Response可以是整型(sint型)的，占用一个字节，包括8个标记位，其中第0位可以作为注册报文是否需要应答标记位，第1位可以作为保留的位，第1至7位分别作为不同指令类型的报文对应的是否需要应答标记位。

步骤S203、若发送状态标记为需要发送状态，则PLC向WCS发送注册报文。

其中，发送状态标记用于表示是否有报文处于待发送的状态，也即是当前是否是需要发送报文的状态，发送状态标记包括需要发送状态和不需要发送状态。如果发送状态标记为需要发送状态，则PLC不再处理其他报文的生成程序，触发报文发送功能，将当前待发送的报文发送给WCS。

示例性地，发送状态标记可以用statTsend.require表示，发送状态标记statTsend.require可以用1标记位(bit)来存储，statTsend.require标记位的值为“true”(或者“1”)表示需要发送状态，statTsend.require标记位的值为“false”(或者“0”)表示不需要发送状态。

本实施例中，在生成注册报文之后，通过将发送状态标记置为需要发送状态，触发该步骤的执行，PLC向WCS发送注册报文。

步骤S204、WCS在接收到注册报文之后，验证接收方设备号是否正确。

在接收到注册报文之后，WCS通过解析注册报文可以获知注册报文中的接收方设备号。WCS可以先验证注册报文中的接收方设备号与自身的设备号是否一致。

如果注册报文中的接收方设备号与自身的设备号不一致，则说明收到了错误的报文，丢弃该报文。

如果注册报文中的接收方设备号与自身的设备号一致，则继续后续步骤S205。

步骤S205、WCS根据注册报文的指令类型，验证注册报文的长度是否正确。

WCS通过解析注册报文可以获知注册报文中的指令类型，该步骤中，WCS可以根据注册报文的指令类型对注册报文的长度进行验证。

具体地，该步骤具体可以采用如下方式实现：

WCS确定注册报文的指令类型对应的第一预设报文长度；判断注册报文的长度与第一预设报文长度是否一致。若注册报文的长度与第一预设报文长度一致，则注册报文的长度正确，继续执行步骤S206。若注册报文的长度与第一预设报文长度不一致，则注册报文的长度不正确，丢弃该注册报文。

其中，第一预设报文长度可以根据实际应用场景进行设定和修改，本实施例此处不做具体限定。

本实施例中，对接收到的报文的验证除了对接收方设备号和报文长度的验证之外，还可以包括先用技术中对接收到的报文的任意其他内容的验证，本实施例此处不再赘述。

步骤S206、WCS对注册报文进行注册处理。

示例性地，WCS可以存储注册报文中的指令数据，进行PLC的设备注册。

步骤S207、WCS根据注册报文确定需要向PLC发送对注册报文的应答报文，根据应答报文的指令类型，确定应答报文的长度，生成对注册报文的应答报文。

WCS通过解析注册报文可以获知注册报文需要应答。

WCS根据应答报文对应的指令类型，可以确定应答报文对应的第二预设报文长度。WCS将生成对注册报文的应答报文所需数据拼接，生成对注册报文的应答报文。

其中，第二预设报文长度可以与第一预设长度不同，第二预设报文长度可以根据实际应用场景进行设定和修改，本实施例此处不做具体限定。

步骤S208、WCS向PLC发送对注册报文的应答报文。

步骤S209、PLC接到对注册报文的应答报文之后，将注册报文对应的是否需要应答状态标记置为不需要应答状态，并将发送状态标记置为不需要发送状态。

PLC接到对注册报文的应答报文之后，会将注册报文对应的是否需要应答状态标记置为不需要应答状态，设备注册成功。

步骤S210、若在预设时长内未接收到对注册报文的应答报文，则再次发送注册报文。

本实施例中，可以配置超时重传机制，发送端在发送一个报文之后，如果在预设时长内没有接收到接收端的应答，则重新向接收端发送报文，并重新开始计时，若再次超时仍然未接收到接收端的应答，则继续重新向接收端发送同一报文，并重新开始计时……，直至接收到接收端对报文的应答。

本实施例中，PLC在发送注册报文之后，可以启动重发计时器(TimeReSend)开始预设时长的计时，如果计时完成前，没有收到对注册报文的应答报文，则执行步骤S202及后续步骤，重新向WCS发送注册报文，并复位重发计时器，重新开始计时，直至执行完步骤S209，设备注册成功。

其中，预设时长可以根据实际应用场景进行设定和修改，本实施例此处不做具体限定。

本发明实施例以PLC向WCS发送注册报文，第一报文对应的指令类型为注册类型为例，对数据通信方法的一种实施方式进行详细地说明，实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

图7为本发明实施例三提供的数据通信方法流程图。在上述实施例一或者实施例二的基础上，本实施例中，以仓储物流系统可以是穿梭车系统为例，在穿梭车系统中，PLC是客户端，WCS为服务端。当PLC与WCS网络硬件正常时，PLC会主动尝试创建与WCS的Socket链接。链接建立成功后，开始报文交互。

本实施例以PLC注册成功后，PLC接收WCS发送的任务下发报文，并向WCS发送应答报文为例，对数据通信方法的另一种实施方式进行说明，本实施例中，第一报文对应的指令类型为任务下发类型，第一报文为任务下发报文，第二报文对应的指令类型为应答类型，第二报文为对第一报文的应答报文。如图7所示，该方法具体步骤如下：

步骤S301、PLC接收WCS发送的任务下发报文。

在需要向PLC下发任务指令时，PLC将生成下发任务指令所需数据拼接，生成任务下发报文，并向PLC发送任务下发报文。

示例性地，任务下发报文中的是否需要应答的值为需要应答，接收方设备号为PLC的设备号，指令类型为任务下发类型，指令数据可以为任务指令数据等信息。

本实施例中，WCS生成报文并向PLC发送报文的过程，与PLC生成报文并向WCS发送报文的过程中，除报文具体内容不同之外，其他处理过程类似，本实例此处不再赘述。

步骤S302、PLC接收到任务下发报文后，根据任务下发报文的指令类型，验证任务下发报文的长度是否正确。

PLC通过解析任务下发报文可以获知任务下发报文中的指令类型，该步骤中，PLC可以根据任务下发报文的指令类型对任务下发报文的长度进行验证。

具体地，该步骤具体可以采用如下方式实现：

PLC确定任务下发报文的指令类型对应的第三预设报文长度；判断任务下发报文的长度与第三预设报文长度是否一致。若任务下发报文的长度与第三预设报文长度一致，则任务下发报文的长度正确，继续执行步骤S303。若任务下发报文的长度与第三预设报文长度不一致，则任务下发报文的长度不正确，丢弃该任务下发报文。

其中，第三预设报文长度可以与第一预设长度和第二预设长度不同，第三预设报文长度可以根据实际应用场景进行设定和修改，本实施例此处不做具体限定。

通过对任务下发报文的验证，如果PLC确定任务下发报文的长度不正确，那么丢弃该任务下发报文。

本实施例中，PLC对接收到的报文的验证，除了对报文长度的验证之外，还可以包括先用技术中对接收到的报文的接收方设备号、报文结束符等其他内容的验证，本实施例此处不再赘述。

另外，通过对任务下发报文的验证，如果PLC确定任务下发报文的长度、接收方设备号、结束符、或者其他任意需要验证的信息不正确，则丢弃该任务下发报文。

步骤S303、若任务下发报文的长度正确，则PLC判断任务下发报文是否是重复发送的报文。

本实施例中，可以配置超时重传机制，发送端在发送一个报文之后，如果在预设时长内没有接收到接收端的应答，则重新向接收端发送报文，并重新开始计时，若再次超时仍然未接收到接收端的应答，则继续重新向接收端发送同一报文，并重新开始计时……，直至接收到接收端对报文的应答。

WCS向PLC发送任务下发报文后，如果在超时前仍然未接收到PLC的应答报文，则会重复向PLC发送同一任务下发报文。

本实施例中，PLC对任务下发报文验证成功后、在对任务下发报文进行数据处理之前，可以先判断任务下发报文是否是重复发送的报文。

如果确定任务下发报文是重复发送的报文，则说明已经存储了任务下发报文中的指令数据，则无需再次存储指令数据，直接执行步骤S305及后续步骤，向WCS发送应答报文。

如果确定任务下发报文不是重复发送的报文，则PLC执行步骤S304及后续步骤，先存储任务下发报文中的指令数据，然后再向WCS发送应答报文。

步骤S304、如果任务下发报文不是重复发送的报文，则PLC存储任务下发报文中的指令数据。

具体地，PLC按照预先设定的存储地址，存储任务下发报文中的指令数据。

步骤S305、若确定任务下发报文需要应答，PLC将是否需要生成应答状态标记置为需要发送应答状态。

其中，是否需要生成应答状态标记用于表示是否需要向报文的发送端发送当前接收到的报文的应答报文，包括需要发送应答状和不需要发送应答状。

示例性地，是否需要生成应答状态标记可以用1标记位(bit)来存储，该标记位的值为“true”(或者“1”)表示需要发送应答状态，该标记位的值为“false”(或者“0”)表示不需要发送应答状态。

步骤S306、若是否需要生成应答状态标记为需要发送应答状态，则PLC根据应答报文的指令类型，确定应答报文的长度，生成对任务下发报文的应答报文。

若是否需要生成应答状态标记为需要发送应答状态，则PLC根据应答报文对应的指令类型，可以确定应答报文对应的第二预设报文长度。PLC将生成对任务下发报文的应答报文所需数据拼接，生成对任务下发报文的应答报文。

其中，第二预设报文长度可以根据实际应用场景进行设定和修改，本实施例此处不做具体限定。

步骤S307、将是否需要生成应答状态标记置为不需要发送应答状态，并将发送状态标记置为需要发送状态。

PLC生成对任务下发报文的应答报文之后，将是否需要生成应答状态标记置为不需要发送应答状态。

PLC生成对任务下发报文的应答报文之后，将发送状态标记置为需要发送状态，触发报文发送功能。发送状态标记置为需要发送状态时，PLC不再处理其他报文的生成程序。

步骤S308、PLC向WCS发送对任务下发报文的应答报文。

若发送状态标记置为需要发送状态，PLC向WCS发送对任务下发报文的应答报文。

本发明实施例以PLC接收WCS发送的任务下发报文，并向WCS发送应答报文，第一报文对应的指令类型为任务下发类型，第二报文对应的指令类型为应答类型为例，对数据通信方法的另一种实施方式进行详细地说明，实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

图8为本发明实施例四提供的数据通信方法流程图。在上述任一实施例的基础上，本实施例中，以仓储物流系统可以是穿梭车系统为例，在穿梭车系统中，PLC是客户端，WCS为服务端。当PLC与WCS网络硬件正常时，PLC会主动尝试创建与WCS的Socket链接。链接建立成功后，开始报文交互。

本实施例以PLC注册成功后，PLC向WCS发送其他报文为例，对数据通信方法的另一种实施方式进行说明。如图8所示，该方法具体步骤如下：

步骤S401、当有指令数据需要上报给WCS时，PLC将该指令数据对应的是否有需要发送的数据的状态标记置为有需要发送的数据。

本实施例中，可以使用报文需要发送状态字Need_Send来存储各指令类型是否有需要发送的数据的状态标记。例如，如图9所示，报文需要发送状态字Need_Send可以是整型(sint型)的，占用一个字节，包括8个标记位，其中第0位可以作为保留位，第1位可以作为是否需要生成应答状态位，第2至7位分别表示对应指令类型的数据数组是否不为空，也就是是否需要发送数据。如果某一位对应的指令类型的数据数组不为空，则说明存在待发送的该指令类型的数据，需要生成该指令类型的报文并发送。如果某一位对应的指令类型的数据数组为空，则说明没有需要发送的该指令类型的数据，不需要生成该指令类型的报文。

例如，报文需要发送状态字Need_Send中得到第3位可以表示设备状态上报的数据是否不为空，没有需要发送的设备状态上报数据；如果第3位的值为“true”或者“1”，则说明设备状态上报类型的数据不为空，有需要发送的设备状态上报数据，需要生成设备状态上报类型的报文并发送。

示例性地，当PLC有数据需要上报给WCS时，会先将上报的数据采用先入先出的方式放入对应的数据数组中，PLC发现数组第一个元素中的数据不为0时，说明有需要上报的数据，则将对应的报文需要发送状态字Need_Send中的对应的标记位置为有需要发送的数据，例如，可以将报文需要发送状态字Need_Send中的对应的标记位置为“true”或者“1”，表示有需要发送的数据。如果报文需要发送状态字Need_Send中的对应的标记位置为“false”或者“0”，表示没有需要发送的数据。

步骤S402、若一指令类型的指令数据在报文需要发送状态字Need_Send中对应的标记位的值表示有需要发送的数据，则PLC根据待发送指令数据对应的指令类型，生成包含待发送信息及对应的指令类型的第一报文。

本实施例中，至少两种指令类型对应的报文长度不同。

其中，第一报文的长度与待发送信息对应的指令类型对应的预设报文长度一致。

在生成第一报文时，PLC将所需数据拼接，生成第一报文。

例如，第一报文可以是穿梭车系统中的穿梭车PLC向WCS发送的任务状态上报报文，生成第一报文所需的数据可以包括：上报类型、任务号、任务对应的目标位置信息、穿梭车当前的位置、任务完成状态等等。其中，任务对应的目标位置信息和穿梭车当前的位置可以包括巷道、层、列、进深等等信息。

步骤S403、PLC将指令类型在报文需要发送状态字Need_Send中对应的标记位的值置为没有需要发送的数据，并将发送状态标记置为需要发送状态。

在生成用于发送该指令类型的指令数据的第一报文之后，将该指令类型在报文需要发送状态字Need_Send中对应的标记位的值置为“false”或者“0”，表示没有需要发送的数据。

在用于发送该指令类型的指令数据的第一报文之后，通过将发送状态标记置为需要发送状态，触发步骤S404的执行，PLC向WCS发送第一报文。

步骤S404、若发送状态标记为需要发送状态，则PLC向WCS发送第一报文。

步骤S405、若第一报文需要应答，则PLC将第一报文对应的是否需要应答状态标记置为需要应答状态。

示例性地，可以使用报文需要应答状态字Need_Response来存储各类报文是否需要应答状态标记的信息。例如，如图5所示，报文需要应答状态字Need_Response可以是整型(sint型)的，占用一个字节，包括8个标记位，其中第0位可以作为注册报文是否需要应答标记位，第1位可以作为保留的位，第1至7位分别作为不同指令类型的报文对应的是否需要应答标记位。

该步骤中，如果第一报文需要应答，PLC根据第一报文对应的指令类型，将第一报文在报文需要应答状态字Need_Response中对应的是否需要应答状态标记置为需要应答状态。

如果第一报文不需要应答，PLC根据第一报文对应的指令类型，将第一报文在报文需要应答状态字Need_Response中对应的是否需要应答状态标记置为不需要应答状态。

步骤S406、若在预设时长内接收到对第一报文的应答报文，将第一报文对应的是否需要应答状态标记置为不需要应答状态，并将发送状态标记置为不需要发送状态。

该步骤中，在接收到对第一报文的应答报文之后，将发送状态标记置为不需要发送状态，PLC可以开始处理其他报文的生成程序。

步骤S407、若在预设时长内未接收到对第一报文的应答报文，则再次发送第一报文。

本实施例中，可以配置超时重传机制，发送端在发送一个报文之后，如果在预设时长内没有接收到接收端的应答，则重新向接收端发送报文，并重新开始计时，若再次超时仍然未接收到接收端的应答，则继续重新向接收端发送同一报文，并重新开始计时……，直至接收到接收端对报文的应答。其中预设时长可以根据实际应用场景进行设定和修改，本实施例此处不做具体限定。

如果第一报文对应的是否需要应答状态标记置为需要应答状态，在发送第一报文之后，可以启动重发计时器(TimeReSend)开始预设时长的计时，如果计时完成前，没有收到对第一报文的应答报文，则重新向WCS发送第一报文，并复位重发计时器，重新开始计时；直至接收到WCS对第一报文的应答报文，第一报文发送成功。

本实施例中，如图5所示，在第一报文发送成功后，还可以通过循环执行本实施例的流程，继续发送其他报文。

本发明实施例以PLC向WCS发送其他报文为例为例，对数据通信方法的一种实施方式进行详细地说明，实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

图10为本发明实施例五提供的数据通信装置的结构示意图。本发明实施例提供的数据通信装置可以执行数据通信方法实施例提供的处理流程。如图10所示，该数据通信装置50包括：报文生成模块501和发送模块502。

具体地，报文生成模块501用于当需要发送指令数据时，根据待发送指令数据对应的指令类型，生成包含待发送信息及对应的指令类型的第一报文，第一报文的长度与待发送信息对应的指令类型对应的预设报文长度一致，其中至少两种指令类型对应的报文长度不同；

发送模块502用于发送第一报文。

本发明实施例提供的装置可以具体用于执行上述实施例一中发送端所执行的处理流程，具体功能此处不再赘述。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

图11为本发明实施例六提供的数据通信装置的结构示意图。本发明实施例提供的数据通信装置可以执行数据通信方法实施例提供的处理流程。如图11示，该数据通信装置60包括：报文验证模块601和报文数据处理模块602。

具体地，报文验证模块601用于在接收到第一报文之后，根据第一报文的指令类型，验证第一报文的长度是否正确，其中至少两种指令类型对应的报文长度不同。

报文数据处理模块602用于若第一报文的长度正确，则对第一报文进行处理。

本发明实施例提供的装置可以具体用于执行上述实施例一中接收端所执行的处理流程，具体功能此处不再赘述。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

在上述实施例五和实施例六的基础上，本实施例七中，该数据通信装置可以同时具有发送端和接收端的功能，该数据通信装置可以同时包括：报文生成模块，发送模块，报文验证模块和报文数据处理模块。

具体地，报文生成模块用于当需要发送指令数据时，根据待发送指令数据对应的指令类型，生成包含待发送信息及对应的指令类型的第一报文，第一报文的长度与待发送信息对应的指令类型对应的预设报文长度一致，其中至少两种指令类型对应的报文长度不同；

发送模块用于发送第一报文。

报文验证模块用于在接收到第一报文之后，根据第一报文的指令类型，验证第一报文的长度是否正确，其中至少两种指令类型对应的报文长度不同。

报文数据处理模块用于若第一报文的长度正确，则对第一报文进行处理。

本发明实施例提供的装置同时具有上述实施例一中发送端和接收端的功能，能够执行上述发送端和接收端所执行的处理流程，具体功能此处不再赘述。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

在上述实施例五或者实施例七的基础上，本实施例八中，上述作为发送端的数据通信装置还可以包括：状态处理模块。

状态处理模块用于：将发送状态标记置为需要发送状态。

在一种可能的设计中，报文生成模块还用于：若发送状态标记为需要发送状态，则发送第一报文。

在一种可能的设计中，状态处理模块还用于：若第一报文需要应答，则将第一报文对应的是否需要应答状态标记置为需要应答状态。

在一种可能的设计中，报文生成模块还用于：若在预设时长内未接收到对第一报文的应答报文，则再次发送第一报文。

在一种可能的设计中，状态处理模块还用于：接收到对第一报文的应答报文之后，将第一报文对应的是否需要应答状态标记置为不需要应答状态，并将发送状态标记置为不需要发送状态。

本发明实施例提供的装置可以具体用于执行上述实施例二至四中发送端所执行的处理流程，具体功能此处不再赘述。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

在上述实施例六或者实施例七的基础上，本实施例九中，上述作为接收端的数据通信装置中，报文验证模块还用于：

确定第一报文的指令类型对应的预设报文长度；若第一报文的长度与预设报文长度一致，则第一报文的长度正确；若第一报文的长度与预设报文长度不一致，则第一报文的长度不正确。

在一种可能的设计中，报文数据处理模块还用于：

若第一报文的长度正确，存储第一报文的指令数据。

在一种可能的设计中，报文数据处理模块还用于：

若第一报文的长度正确，且根据第一报文的指令序号确定第一报文不是重复发送的报文，则将存储第一报文的指令数据；

若根据第一报文的指令序号确定第一报文是重复发送的报文，则不再存储第一报文的指令数据。

在一种可能的设计中，作为接收端的数据通信装置还可以包括：状态处理模块。状态处理模块用于：若第一报文需要应答，则将第一报文对应的是否需要生成应答状态标记置为需要发送应答状态。

在一种可能的设计中，作为接收端的数据通信装置也可以作为数据发送端，还可以包括报文生成模块和发送模块。报文生成模块用于：若第一报文对应的是否需要生成应答状态标记为需要发送应答状态，则生成指令类型为应答类型的第二报文，第二报文为对第一报文的应答报文。

在一种可能的设计中，状态处理模块还用于：

将第二报文对应的是否需要生成应答状态标记置为不需要发送应答状态，并将发送状态标记置为需要发送状态。

在一种可能的设计中，发送模块用于：若发送状态标记为需要发送状态，则发送第二报文。

本发明实施例提供的装置可以具体用于执行上述实施例二至四中接收端所执行的处理流程，具体功能此处不再赘述。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

图12为本发明实施例十提供的数据通信设备的结构示意图。如图12所示，该数据通信设备100包括：处理器1001，存储器1002，发送器1003，接收器1004以及存储在存储器1002上并可在处理器1001上运行的计算机程序。

其中，处理器1001运行计算机程序时实现上述任一方法实施例中接收端和/或发送端所执行的数据通信方法。

本发明实施例通过发送端在发送报文时，根据待发送指令数据的指令类型确定待发送的报文的长度，接收端在接收到报文时，根据报文的指令类型验证报文的长度，从而实现将指令数据分成多个不同的指令类型，用于发送不同指令类型的指令数据的报文的长度可以不同，也即是不同指令类型对应的报文长度不同，使得携带指令数据多的报文长度较长，携带指令数据少的报文长度较短，能够节省带宽，提高带宽占用率。

另外，本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现上述任一方法实施例中接收端和/或发送端所执行的数据通信方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求书指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求书来限制。