标签：master 交互 获取 eid mod -- 业务 发送请求 根据
一、文章背景
1个master，30个slaver，485 RTU通信。
master主动读取slaver的寄存器信息，下面用来做啥就省略了，本文只介绍如何处理通信逻辑。
关于协议的基本信息省略。
由于计算机加密，文字都是在博客编辑框中现写的。
二、注意点
1、 master不可同时与30个从站通信，必须挨个轮询，而且一问一答，串口的半双工特性就决定了这种通信方式，同一时刻只允许一个人占用这个信道。
2、 广播模式不适用该项目，广播模式通常用于写入slaver，而且slaver不回应数据。
3、 slaver回应时，可能会分几次回应，这一点与tcp类似。
4、 一个机器接30个串口设备，用的扩展板卡，光线缆就一捆，前面说了需要挨个轮询，通常一次通信大约在100ms，30个设备轮询完了就需要3秒钟了，特别要注意这一点，如果对实时性要求很高，则必须将slaver分组，比如用三个串口，每个串口接10个slaver，本文就介绍这种方法。
三、实现方法
1、 使用三个串口、每个串口接10个slaver。相当于三个master，每个master与10个slaver通信。
2、 建立slaverid的映射关系，master编号1、2、3，每组slaver编号1、2、3、4…10，主站获取slaver数据后，往业务层反馈数据时加上master编号，用两个字节表示，第一个字节是主站编号，第二个字节是slaver编号。这样业务层根据id映射就能区分出哪一个slaver设备反馈的数据。
3、 业务层与通信层交互时引入一个转换回调层。
业务层---->回调层（业务数据结构转换成adu）---->通信层
通信层---->回调层（adu转换成业务数据结构）---->业务层
4、 master向slaver发送请求后，需要等到回应后，才能执行下一步操作，前面说了回应可能分几次进行，处理回应数据方式如下：
（1） 根据发送的请求，我们可以知道期望的回应是什么，比如读一个线圈（slaveID=1线圈地址2），则发送adu为01 01 0002 0001 CRC，期望返回是01 01 01 XX，异常则是01 80 XX CRC，因此可以读取功能码判断后面期望的adu的总长度到底是多少。
（2） 回应获取以后crc校验，然后将数据转发给回调层处理，一个slaver的通信逻辑就算完成了，然后执行下一个。
（3） 异常情况，等回应需要加上超时（500ms），把超时的slaver信息回调给上一业务层。
四、总结
要扩展的话，就创建多个master对象就行了，上层业务处理映射关系就行。把启用多少个master及slaver映射放到配置文件，这样 扩展就很方便了。
标签：master 交互 获取 eid mod -- 业务 发送请求 根据
原文地址：https://www.cnblogs.com/shelwinnee/p/12850844.html
