在Delphi环境下基于SPCOMM控件开发串口通讯报文字节丢失的问题解决

最近做的工具需要实现串口转UDP中间件，中间件与下位机通过RS232通讯，与接收服务器通过UDP通讯。

在传输过程中出现问题如下：

1. 通过PC机安装的虚拟串口进行调试，接收程序完全正常。

2.与下位机进行通讯测试，常规短报文接收都完全正常，但是在传输图片分包文件（包总长度：545）时出现报文内部分字节丢失的问题。

经过不断测试，发现：

1. 下位机发送的报文长度为545，无异常；

2. 串口转UDP转发过程完全正常；

3.中间件的串口接收出现问题，原本545的报文接收到后会变成540、542、543等，总会丢失几个字节；

折腾了一天终于找到原因，是由于在Delphi下使用的SPCOMM组件默认开启了Inx_XonXofFflow、TxContinueOnXOff、Outx_XonXoffFlow三个属性。

将这三个属性值设置为FALSE后测试，报文接收正常，转发也正常，问题解决。

 

经过查找相关资料，对该三个属性的解释如下（以下内容转载自http://blog.csdn.net/jinshaopu/article/details/4646791）：

SPComm的一点小诀窍 spcomm的问题导致数据丢失

最近几天完成了BiasDAC的程序编写。调试的过程还算比较顺利，除了几个有点bt的小问题。其中一个困扰了我两三天的时间，今天上午终于将其解决。

由于BiasDAC是用RS232 Serial Port通信的，延用之前的程序，使用了Delphi的SPComm控件。在之前的使用中，SPComm控件一直工作正常，使用的是一般的string进行消息的传递。

而BiasDAC由于通信协议的限制，消息的发送使用的是hex方式，会用到从0x00到0xFF所有的这些字符。在调试中发现，发送0x11和0x13之后，SPComm的工作就会不正常。

首先是0x11发送之后，返回的0x11消息会被忽略；其次0x13发送之后，只能返回很有限的消息，而且似乎Serial Port就此关闭，如果再发送消息，就会造成Serial Port失去响应，只能通过重新启动计算机才能恢复。

后来上网上查询，原来不能正常处理0x11和0x13的问题早就存在，原因是SPComm空间中两个属性的存在。

OutX_XonXOffFlow/InX_XonXoffFlow：这个属性是指进行发送/接收时的软件握手标志，两个握手信号之间的数据被认为是通讯数据，收到握手信号后，通讯就中止了。

FOutx_XonXoffFlow := True;

FInx_XonXoffFlow := True;
FXoffChar := chr($13);
Comm.Outx_XonXoffFlow:=False;

 

默认的初始化中，这两个属性是默认开启的。

XOffChar/XOnChar：这是指握手的字节，默认的初始中，有

FXonChar := chr($11);

至此，真相大白。0x11，0x13被占用为通讯握手信号，自然不会得到正确的处理。

问题找到了，解决也很容易。只需要在Comm的初始化中，自己定义

Comm.Inx_XonXoffFlow:=False;

关闭软件握手功能即可。在一般通讯中，硬件已经具备了握手功能，所以也不会影响到正常的Comm通讯。

以下内容转载自：

http://hi.baidu.com/firebirdrui/item/fbfe420bd16843e0f55ba66f

COM串口传输文件

spcomm 控件

1. ReadIntervalTimeout属性决定什么时候触发Comm1ReceiveData事件，也就是接收数据事件，例如设为100ms，那么在100毫秒内接收端会这段时间的数据当成一个包的数据，并触发接收事件。超过这100ms的数据成为另一包的数据。

2. 传输文件是有一个奇怪的显现，如果是txt文件的话，那么接收到的字节数是正确的，如果是doc，exe等文件，接收到的字节数是错误。当把接收端outtx_xonxoffflow属性值改成false以后，此问题得到解决,经试验inx_xonxoffflow属性对次没影响，而且发送端的这两个属性跟此情况也无关系

3. Spcomm应用的核心在于主线程、读线程和写线程之间的消息传递机制，而通信数据相关信息的传递也是以消息传递的方式进行的。在使用Spcomm进行串口通信编程，除按照说明使用外，还需要特别注意以下两个问题。

首先，Spcomm是通过ReadIntervalTimeout属性的设置，来确定所接收到的数据是否属子同一帧数据，其默认值是100ms,也就是说，只要任何两个字节到达的时间间隔小于1OOms，都被认为是属于同一帧数据，在与单片机协同工作时，要特别注意这个问题[2]。

另外，Spcomm的默认属性设置是支持软件流控制的，用于流控制的字符是13H(XoffChar)和11H(XonChar)，当单片机以二进制方式发送数据时，必须要禁用Spcomm对于软件流控制的支持，否则，在数据帧中出现的13H，11H会被Spcomm作为控制字符而加以忽略。