我的每种Modbus设备FB，都具备自动匹配485波特率的功能。

就是在西门子支持的11种波特率中，依次尝试派发任意一个读写任务，并记录下每次的成败。全部波特率遍历尝试结束后，根据成败记录，选择合适的波特率，为该设备的端口进行初始化。

这种自动匹配波特率操作中，多数通信任务必定失败。所以这个期间，必须要禁用设备FB内部的淘汰环节，否则通信无法继续，该设备FB会HMI报警，并自动退出轮询。

这个自动匹配485波特率的功能，是设备FB在执行通道初始化环节中启动的一个子项。

这可以让连接在同一个485端口上的不同MB设备，以不同的速率来工作。

但是，今天遇到了一个设备FB在自动匹配波特率的时候，卡在57600，就不再往下执行了。

上线监控发现，这个设备FB的内部功能，停在了通信部分的执行后调度环节。

进入该环节发现，这个停滞是由于modbus通信中的第三种情形的出现导致的： 既不报Done，也不报Error。该环节中的相应调度子项，没有启动后续执行。所以程序只是空扫描，功能链却断在这里。

而这第三种情形，在通信的任务执行环节中，是有专门的超时处理子项的（3秒超时）。为什么还会出现异常呢？继续回溯原因。

进入该环节发现，在第三种情形处理的子项中，关于自动匹配波特率的执行记录，有一句话忘写了。因为这种卡死情形极少出现在自动匹配中，以前没注意。本来自动匹配485波特率这种事就很少去做，只在更改硬件设定的时候做一次。

把这句代码粘贴上，再次测试自动匹配波特率，ok了。

HMI界面上显示，该设备尝试57600速率的时候，派发的是一个写任务。它的最近一次执行时间是3000毫秒且失败，这正符合上述超时处理的设定。就是这个原因

这个问题的解决只用了几分钟。类似的以前调试遇到过多次，也都很快解决。

关键在于：设备FB内部的诸多环节之间，必须是低耦合组装的，才能容易，

根据问题的性质，精确定位到FB内部的某个环节，该环节中的某个子项元素，而其他无关环节完全不用理睬。对问题溯源，可以按照一步一步的结构必然性，倒推出原因所在位置。否则就要满篇胡乱去找，肯定搞懵，耗时费力。

分享是说明一点：模块化与低耦合，不仅仅是分割成FB或FC。一个块，其内部的数据和逻辑结构的设计，是可以按照场景细节分隔的，这样效率会高。在诊断的时候区别很大。

大家可能注意到：最后一个环节通信子集的监视信息回馈，没有被放进上面大的IF语句中。

这是因为：每一个设备FB，可以单独被控制是否允许参与进入轮询，和对端口通信资源的竞争。即使不允许进入轮询，在该设备的HMI页面上，依然还要动态更新：

• 该设备目前是被连接在哪一个485端口上，

• 该端口目前总共连了几个设备被允许参与Online轮询，

• 该设备在端口队列中的次序，

• 该设备在同类设备队列中的次序，

• 该设备的MB站号，

• 该设备的当前波特率，

• 该设备当前是否上线轮询，

等等信息，都会显示在界面上，便于现场了解和诊断。便于根据硬件情况，在现场动态更改通信通道是连接配置。

每个设备的HMI通信监控效果如下：

比如：某品牌的Modbus设备总共有10个，其中的第6个设备，被连接在第2个485模块上，且和其它种类或品牌的设备一起在该端口排队，被排在了该端口的第3位。

你可能有多个485模块，每个模块连接了多个不同种类或品牌的Modbus设备。你的多种品牌或多类设备，每一品牌或每一类，都可以有多个相同的Modbus设备。

每个485模块，和设备种类与品牌之间，不一定是有规律按分组连接的。很可能由于种种历史和现状原因，在现场穿插交错和更改接线，等等情况。

这都要求调度的灵活性。也就是架构的低耦合，随时扩展，随时剪裁增删。且还要功能完善，健壮易用易诊断，程序要尽量简洁，尽量缩短需求变化带来的编程时间，尽量易于隔离调试错误，提高调试的一次通过率，等等要求。

可以在HMI界面上，根据现场接线的实际情况，参数化配置通信通道。效果如下。

一个设备是否被允许参与485轮询，和在轮询中被淘汰，两者不是一回事。

比如：一个485模块，连个5个Modbus设备，可以启用和禁用其中某个设备的上线。被允许上线参与轮询的设备，如果通信质量出现问题，可以被临时淘汰退出轮询。等后来线路质量改善，可以再恢复上线继续参与轮询。

就像商店申请许可，即使拿到许可，依然可以临时关门歇业。

在通常的编程中，设备FB实例都是独立的存在。这意味着：各种设备FB实例之间，是平行的并存关系，也就是所说的FB实例的平行调用。

但是当人们面对modbus的时候，总是一上来就先说轮询。却很少提及modbus设备实例的并存问题，似乎在这个问题上就出现了例外，就不应该往这儿想。

这时候如果有人强调：Modbus设备FB实例之间，也应该和其它设备实例一样，也是平行调用关系。这样的看法似乎成了突兀的存在，似乎和轮询的观念是矛盾的。

为什么会有这样的普遍观念现状存在呢？这和每个人学习的起源与路径习惯有关系。

每个程序员，最初学习modbus，都是从常见的官方实例或其它人的现成案例开始的。都是直接或间接的继承沿袭了前人的做法。

师傅教徒弟，徒弟又成了师傅，又有了自己的徒弟，如此往复延续。一波又一波人的技术沿袭，和约定俗成的官方模版或成熟案例，演化成了难以撼动的技术路线观念。

其实稍微换个角度，把通信作为IO来理解，就会明白：modbus的轮询问题，只不过是IO的竞争性使用问题。

通常的IO通道，DI、DO、AI、AO，都是独占性使用。都只用于恒定的单一应用，不和其它物理控制途径发生争夺。也就是这些IO，都独占性的被特定的某个FB实例拥有。这样的情况下，似乎这些设备实例的平行调用，就是顺利成章的不言而喻。

如果你能一视同仁的平等接受：modbus设备实例，和其它设备实例没有本质差别，也应该被平行调用的话。

那么就会意识到：所谓轮询，也就是同一个IO资源，在不同任务，不同设备之间的竞争问题，都是可以通过在设备FB内部，增加相应的竞争环境下的调度策略来解决的。从而保证了所有的设备实例，都是一如既往的，被平行调用的结构模式。

只不过是因为绝大多数PLC设备都是独占IO的，所以人们对于竞争策略不熟悉，很少用。

其实，从社会与企业管理，到操作系统和复杂软件的底层策略，到处都是竞争性的身影。

为什么会有竞争？就是因为资源稀缺。资源有限，不够均分，不够独占，只能是分时分事来均衡的轮流使用。

继承与创新，两者间即相互关联，又相互制约和矛盾。

人们往往认为自己是自由的。那么当自己的想法总是习惯性的、自觉性的长期跟随别人的观念，自己真的是自由的吗？

现在网上，关于西方的技术领先与垄断和封锁，国人的自主与创新，是个热门话题。作为一个程序员，在每天的行为模式和细节中，这个问题的深刻性和普遍性是无所不在的。

所以，如果一个PLC程序员，想要面对更大更复杂的场景，学会在一个设备FB内部构造竞争性策略规则，是非常必要和有价值的。

这就像大多数人都习惯使用已有的成熟通信协议，却很少尝试建造通信协议。而IT程序员进大厂，这几乎是必考问题。