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

时间:2021-10-06 17:49:20

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     归零

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