CN105007209B - 一种基于rs485的轮询通讯方法 - Google Patents

Abstract

本发明提出一种基于RS485的轮询通讯方法，子站中断服务程序接收到主站命令后，将缓存的上一次返回帧返回；然后，子站主程序处理响应命令，生成返回帧并缓存；主站发送下一命令后，子站才返回该缓存帧；如此周而复始。在不改变目前同类设备的硬件基础上，大幅度提高了数据的上送速度，并且容许每条RS485线上挂接更多的设备。

Description

一种基于RS485的轮询通讯方法

技术领域

本发明涉及一种轮询通讯方法，具体涉及一种基于RS485的、可提高轮询速度的新型通讯方法。

背景技术

RS485通讯方式是一种基础且简单的半双工通讯组网方式，在工控、电力等多领域大规模使用。基于RS485的规约主要为问答式轮询规约，如MODBUS-RTU，IEC-60870-5-103等。

基于问答式规约，主站端需首先发出命令，然后等待子站发送数据。因为子站设备千差万别，很多都未使用实时OS，导致响应时间一般需要50~200ms左右。更严重的是某些设备因异常未响应，主站必须等待最大超时。

因此依据485的轮询规约，如果挂接设备过多，数据上送就会变慢，很多现场为了保证监控系统响应速度，只能限制每条RS485线上挂接设备数量，通讯带宽利用率很低。

发明内容

本发明所要解决的技术问题是，提供一种基于RS485的轮询通讯方法，在不改变目前同类设备的硬件基础上，提高数据的上送速度，并且容许每条RS485线上挂接更多的设备。

本发明的技术方案如下：

一种基于RS485的轮询通讯方法，其特征在于：子站中断服务程序接收到主站命令后，将缓存的上一次返回帧返回；然后，子站主程序处理响应命令，生成返回帧并缓存；主站发送下一命令后，子站才返回该缓存帧；如此周而复始。

主站命令控制流程以异步方式处理，每个命令和响应都要进行ID标志，在真实接收到对应的响应命令后，一个完整的命令序列才执行完毕。

子站在执行控制命令时，需要同步处理“状态量”信息，命令响应帧生成后覆盖当前“状态量”响应帧。

子站有主动数据时，直接生成“主动数据”响应帧，并覆盖“状态量”响应帧。

选取整个网络中响应最慢的设备为地址1，并规定由该设备响应主站广播命令；主站在接收到响应后，立即开始下一个命令序列。

子站在接收到主站命令后，若没有缓存的响应命令，返回“忙”响应帧；主站接收到忙帧时，按照提示等待一段时间在开启下个命令序列。

本发明的积极效果在于：

因为按照本发明的方法，“接收-响应”流程为一个整体，无需访问其他流程，提高了子站响应速度，该过程全部在中断服务程序中进行，实测可达到5~10ms的响应速度。基于以上效果，本发明容许每条RS485线上挂接更多的设备。

本发明的方法已在保密状态下成功试用于微机保护、智能仪表、采集器、通讯管理机等多种设备中，运行情况稳定。

附图说明

图1是轮询规约通讯时序图；

图2是本发明主站执行流程图；

图3是本发明子站执行流程图。

具体实施方式

下面结合附图和实施例进一步说明本发明。

1、基于485的轮询通讯模型：RS485为单双工通讯，轮询通讯主要有三种模型，如图1所示：

1）、正常问答命令：主站发送命令，被询问的子站返回响应；

2）、广播命令：主站发送命令，等待一段时间后启动下个过程；

3）、问答异常：主站发送命令，子站无返回，超时后启动下个流程。

常规情况下，485链路主要被子站命令响应周期和超时等待周期占用，带宽利用率比较低。

基于485的轮询命令主要包括：

1）、请求状态量命令——返回状态量响应；

2）、发送控制命令——返回控制命令响应；

3）、请求主动上传数据——返回主动上送响应；

4）、广播对时命令——无响应。

2．答非所问机制

为了提高RS485通讯带宽利用率，压缩子站响应周期和超时等待时间，本发明提出一种“答非所问”机制，可以充分利用带宽。

如图2、3所示，基本思想是：子站中断程序接收到主站命令后，并不立即处理，而是将缓存的上一次返回帧立即返回；然后，子站主程序才开始处理响应命令，生成返回帧并缓存；主站下发下一命令时，子站才返回缓存的帧；如此周而复始。

因“接收-响应”流程为一个整体，无需访问其他流程，为了提高子站响应速度，该过程全部在中断服务程序中进行，实测可达到5~10ms的响应速度。

为了在主站第一次发送命令时有帧返回，子站在初始化时必须先准备 “状态量”响应帧。

基于“答非所问”机制，如果仅需要轮询状态量信息，因没有明确的时序关系，因此主站不需要调节，可以将每次返回帧“认为”响应帧立即处理。

3．在“答非所问”机制下的控制命令

如图2、3所示，基于“答非所问”机制，如果主站发送控制命令，因并没有立即返回应答命令，当前控制命令未执行完毕，主站不能简单的将返回帧“认为”响应帧。

为了适应该机制，主站的命令控制流程经过异步化处理，需要标记每个命令和响应，只有真正接收到命令响应帧时，一个命令序列才执行完毕。

因控制命令执行时间一般较长，子站在接收到控制命令后，不仅需要处理命令，而且需要缓存“状态量”响应帧，在命令处理完毕后，可以直接以命令响应帧覆盖当前“状态量”响应帧。

4．在“答非所问”机制下的主动上送命令

如图2、3所示，如果子站有主动上送命令时，可以直接生成主动命令相应帧，然后覆盖当前“状态量”响应帧。这样在主站发送下次命令时，可以直接返回主动上送命令响应帧。

采用该机制，优于传统的轮询命令，需要主站发送主动上送查询命令时，才返回主动命令上送响应帧。

为了防止统一个主动命令多次上传，需要对命令进行ID编号，主站检测到重复帧直接丢弃。

注意在此时，子站也必须缓存主站命令并响应，否则会导致下一次操作会异常。

5．在“答非所问”机制下的广播命令

如图2、3所示，传统的广播命令一般是不应答的，但此时主站必须执行等待超时，以保证所有子站都接收到了广播命令。但因各种组网和设备的差异性，该等待超时设置较长，会严重降低通讯带宽利用率。

为了提供带宽利用率，规定广播命令由地址为1的设备响应，而主站在接收到返回帧时，可立即开始下一次命令序列。一般设置为网络中处理最慢的设备，并适度富余。此时的广播命令执行时间是自适应的，优于通过超时等待的机制。

同时，使广播命令带返回响应，主站端所有的命令都有返回，而没有返回的必定是通讯异常了，简化了主站端程序执行流程。

6．在“答非所问”机制下的时间配合和忙处理

常规“命令-响应”序列一般需要60~150ms左右的执行时间，超时时间一般设定为300~500ms。为了保证2S以内的监控系统响应时间，每条RS485挂接设备数量为6~12个。

而采用“答非所问”机制后，“命令-响应”序列仅需要5~10ms的执行时间，此时超时时间可设定为20~30ms，理论上可挂接100个以上的设备，但因物理限制，一般不超过32个，如果物理条件良好，可增加到50个。

当挂接设备很少时，子站可能在没有准备好下一帧的情况下收到主站命令，此时以忙帧响应，并在忙帧中设定等待时间；主站收到忙帧后按要求等待一段时间在发送命令，以此来优化子站设备的cpu负荷。

Claims (1)

1.一种基于RS485的轮询通讯方法，其特征在于：子站中断服务程序接收到主站命令后，将缓存的上一次返回帧返回；然后，子站主程序处理响应命令，生成返回帧并缓存；主站发送下一命令后，子站才返回该缓存帧；如此周而复始；其中，“接收-响应”流程为一个整体，无需访问其他流程；

主站命令控制流程以异步方式处理，每个命令和响应都要进行ID标志，在真实接收到对应的响应命令后，一个完整的命令序列才执行完毕；

子站在执行控制命令时，需要同步处理“状态量”信息，命令响应帧生成后覆盖当前“状态量”响应帧；

子站有主动数据时，直接生成“主动数据”响应帧，并覆盖“状态量”响应帧；

选取整个网络中响应最慢的设备为地址1，并规定由该设备响应主站广播命令；主站在接收到响应后，立即开始下一个命令序列；

子站在接收到主站命令后，若没有缓存的响应命令，返回“忙”响应帧；主站接收到忙帧时，按照提示等待一段时间在开启下个命令序列。