使用 ASCII 驱动程序接收数据

可选的结束标准

使用 ASCII 驱动程序进行数据传输时，可以在三种不同的结束标准中进行选择。 结束标准定义何时接收完整的消息帧。 可能的结束标准如下：

字符延时时间结束后

消息帧没有固定长度，也没有定义的结束符；消息的结束由线路上的暂停（字符延时时间结束后）定义。

接收到结束符时

消息帧的结束由一个或两个定义的结束符标记。

接收到固定数目的字符时

接收消息帧的长度始终相同。

代码透明度

程序的代码透明度取决于已组态的结束标准的选择和流控制：

包含一个或两个结束符

- 非代码透明

当结束标准为字符延时时间或固定消息帧长度时

- 代码透明

当使用流控制 XON/XOFF 时，无法进行代码透明操作。

代码透明是指用户数据中可以包含任意字符组合，而*识别结束标准。

结束标准“字符延时时间结束后”

接收数据时，字符延时时间结束时识别为消息帧结束。 从 CPU 中接受所接收的数据。

在这种情况下，必须设置字符延时时间，以使其可在两个连续的消息帧之间可靠结束。 但是该字符延时时间应该足够长，这样，无论连接中的伙伴何时在消息帧内采取发送暂停，都不会错误地识别消息帧结束。

下图说明了使用结束标准“字符延时时间结束后”的接收操作。

图片: 使用结束标准“字符延时时间结束”的接收操作的顺序

结束标准和结束符

接收数据时，如果遇到组态的结束符，将识别为消息帧结束。 从 CPU 中接受所接收到的数据（包括结束符）。

如果在接收消息帧时字符延时时间结束，那么接收操作将终止。 将发出一条错误消息并丢弃消息帧碎片。

如果使用结束符，则传输是非代码透明的，并且必须确保结束代码未出现在用户数据中。

如果接收消息帧中的最后一个字符不是结束符，请注意以下情况。

结束符在消息帧中的其它位置：

所有字符（包括结束符）都被输入到接收 DB 中。 结束符后的字符

- 如果消息帧结束时字符延时时间 (CDT, Character Delay Time) 结束，则这些字符将被丢弃。

- 如果在字符延时时间结束前收到新的消息帧，则这些字符将与下一个消息帧合并。

结束符不包括在消息帧中：

消息帧将出现以下情况：

- 如果消息帧结束时字符延时时间 (CDT, Character Delay Time) 结束，则该消息帧将被丢弃。

- 如果在字符延时时间结束前收到新的消息帧，则该消息帧将与下一个消息帧合并。

下图说明了使用结束标准“结束符”的接收操作。

图片: 使用“文本结束字符”结束标准的接收操作的顺序

结束标准“固定消息帧长度”

接收数据时，如果达到组态的字符数目，则识别为消息帧结束。 从 CPU 中接受所接收的数据。

如果在达到组态的字符数目之前字符延时时间结束，则接收操作将终止。 将发出一条错误消息并丢弃消息帧碎片。

如果接收字符的消息帧长度与组态的固定消息帧长度不匹配，请注意以下情况：

接收字符的消息帧长度大于组态的固定消息帧长度：

在达到组态的固定消息帧长度之后接收的所有字符将出现以下情况

- 如果消息帧结束时字符延时时间 (CDT, Character Delay Time) 结束，则这些字符将被丢弃。

- 如果在字符延时时间结束前收到新的消息帧，则这些字符将与下一个消息帧合并。

接收字符的消息帧长度小于组态的固定消息帧长度：

消息帧将出现以下情况：

- 如果消息帧结束时字符延时时间 (CDT, Character Delay Time) 结束，则该消息帧将被丢弃。

- 如果在字符延时时间结束前收到新的消息帧，则该消息帧将与下一个消息帧合并。

下图说明了使用结束标准“固定消息帧长度”的接收操作。

图片: 使用结束标准“固定消息帧长度”的接收操作的顺序

模块的接收缓冲区

模块的接收缓冲区较多可达 4096 字节，具体取决于通信模块。

在组态期间，用户可*：

CP 和 CPU 31xC-2 PtP
启动时是否删除接收缓冲区以及是否避免覆盖接收缓冲区中的数据。 也可以为缓冲的接收消息帧数*值范围（1 至 250）。

ET 200S 1SI
启动时是否应删除接收缓冲区中的数据以及是否应避免覆盖接收缓冲区中的数据。 此外，还可以激活或阻止对接收到的消息帧的缓冲。

模块的接收缓冲区是环形缓冲区：

如果有多个消息帧输入到模块的接收缓冲区，则以下原则适用： 始终将较早的消息帧从模块发送到 CPU。

如果只想传送较新的消息帧，则必须：

- CP 和 CPU 31xC-2 PtP
将缓冲的消息帧数设置为“1”并禁用覆盖保护。

- ET 200S 1SI
阻止动态消息帧并禁用覆盖保护。