delphi 串口 关于RS485总线通信协议开发注意事项

http://blog.csdn.net/shjhuang/article/details/9426739

关于RS485总线通信协议开发注意事项

1       前言

近段时间发现我们系统在进行设备组态时，采用的串口复用方式在同一个RS485串口上挂载多个智能设备进行通信、监控。而往往在系统组态的时候就会发现部分设备通信不上，或者工程交付之后出现智能设备经常通信中断的情况。本文描述RS485总线协议的工作原理，从根本上剖析导致以上问题的根本原因。

2       RS485总线硬件特点

2.1     拓扑结构

RS485总线一般采用1对1和1对多的组网方式，很少有多对多的场合，主要原因是RS485没有总线仲裁，多对多会导致多个设备在总线上信号冲撞，最终无法正常通信。

2.2     总线挂载能力

RS485的总线挂载能力一般有三种等级，32节点（MAX485）、128节点（MAX1487）、256节点（MAX1483）。

3       RS485总线软件特点

3.1     交互方式

RS485基本上采用一问一答的交互方式，主设备向从设备发送一条指令，从设备执行指令之后，返回一条应答命令。

特殊情况下，在数据交互不频繁的场合中，为了提高反应速度，也有从设备主动向主设备发送数据的用法。

3.2     地址

为了区分主设备以及多个从设备，在交互的消息帧当中的从设备的地址是必需的，否则无法区分具体的设备。

如果一大堆从设备当中有地址相同的话，将导致通信异常。

3.3     校验

RS485总线一般具备校验，主要是因为通信线路很长，存在干扰的可能性很大，校验是对数据准确性的必要检验手段。

4       协议处理

4.1     帧结构分析

4.1.1 问题

早期485设备的处理器大多采用8为低速单片机。在协议的解析处理上因资源受限，往往做得不是很完善，导致在多设备组网的情况下，发生通信异常的情况。

4.1.2 有起始符和结束符

SOH

ADDR

LEN

DATA0

………

DATAn

CRC

EOH

常用的SOH例如0x7E,EOH例如0x0D。

特点是具备特殊定义的起始符和结束符，在接收端很容易判断是否有接收到完整的数据帧。接收完毕后再进行后处理。后处理包括地址判断、CRC校验、以及协议解析。

4.1.3 无起始符

ADDR

LEN

DATA0

………

DATAn

CRC

因为没有起始符，很难判断是否收到一个完整的数据帧，每收到一个字节都要处理一次。处理起来很痛苦，但是单片机程序恰恰相反，喜欢这么做。

4.2     接收处理方法。

4.2.1 对于有起始符和结束符的协议来说，很少出问题，毕竟只要通过2个字符就可从总线上获取一个完整的数据帧。如果总线上挂的设备都是这种协议的设备，很少发生故障。

4.2.2 对于没有特殊字符的协议帧，处理起来比较麻烦，问题也比较多。

4.2.2.1  方法1

接收到第1个字符之后，就立刻判断是否与本机地址匹配，如果不是，则停止接收数据，等待一段时间之后再接收。停止接收数据的目的在于丢掉该帧后续的数据。

特点：处理方式简单，CPU开销比较少。但是因为停止接收的时间段一般是固定的且预留得比较宽，有可能在停止接收的这个时间段内收到属于本机的数据帧，却没收到。

4.2.2.2  方法2

收到第1个字符之后，不立即处理，直到接收完整的长度描述符（LEN）后，再根据长度描述符定义的长度，接收完一帧之后再处理。处理包括地址判断、CRC校验、以及协议解析等。

特点：能很快的接收到完整的数据包，但是不是本地的数据包也接收进来了，对低端的CPU来说是个压力。

4.2.2.3  方法3

收到1个字符之后，如果超过多长时间没有接收到下一个字符，则认为是数据包结束，对数据进行处理。

特点：和方法2类似，对低端的CPU来说是个压力。另外的好处就是可以降低处理函数的复杂度，不需要计算数据包的长度，并依次接收。

但是字符超时的时间很难把控，如果双发都是自己厂家的设备问题不大，如果接了很多品牌的设备，就会出现其他问题。

4.2.2.4  方法4

结合方法2和方法3，对CPU有一定的压力，但是接收效果最好。响应迅速。

4.2.3 协议解析的错误做法

4.2.3.1  有些协议需要回送确认。例如控制台。

4.2.3.2  有些协议智能在接收到正确的数据包之后才能回送。但是某些设备接收到了非法的数据之后也回送错误代码应答，导致与总线其他厂家设备冲突。

4.3     带来的问题

4.3.1 对于方法1，停止接收的时间段一般是固定的且预留得比较宽，有可能在停止接收的这个时间段内收到属于本机的数据帧，却没收到。如过总线上数据量大的话，可能会一直存在这种问题，一直通信不上。

4.3.2 对于方法2，接收端是没有问题的，但是可能会影响到使用了方法1和方法3的设备，因为方法2接收得快，应答的也快。对于方法1而言，应答的2个数据包紧跟在一起，长度比较长，时间也比较长，有可能接收到中间的部分数据，结果是错误的。更严重的是，因为接收到了错误的数据，从设备会回送一个错误应答，与原有的其他设备的正确数据冲突，导致所有的通信都失败。

5       解决办法

5.1     在协议组态的时候，因为现场设备已经安装好，并且很多并不是我们厂家的设备，让其他厂家来配合我们调整程序并不现实，那么可以通过一下方式来解决这些问题。

5.2     错开波特率

不同厂家设备之间，使用不同的波特率，且错开也大越好，例如两个厂家都支持1200到38400，则一个厂家用最低的，另一个厂家用最高的。

5.3     增加命令之间的间隔时间

5.3.1 在同一个设备当中，需要读取多条指令才能完成数据的采集，那么在每条指令之间做个延时（200ms-500ms）。

5.3.2 在不同设备切换时，上述时间可以更长一点（500ms-2S）。

5.3.3 以上时间可以根据现场情况进行适当调整，多次测试，获取最佳的时间，既要保证可靠的通信，又不能让系统的响应速度受到明显的影响。

5.4     归零

发送指令之前，先清空接收缓冲区，预防累加有其他无效的数据。