如果多个站点之间，需要的时候可以互相写入，实现对称的事件通知。这样的机制需要站点可以动态更换Master身份。

诸多站点当中，首先应该设置某个站点惯常做为默认Master。其它临时Master完成事件写入任务后，要切换回Slave身份。

这需要每个站点都同时具有两个功能模块，一个是负责Master，一个负责slave功能。

Master和slave功能的切换，依赖几个标识变量的数值变化。所以这些标识变量数据，都是来自别的站点，它们的即时性和可靠性就至关重要。为此需要一个标识位，它能够表明本次轮询中，当前这个读或写任务是成功还是失败。以此确认数据的可靠性。在此通信数据可靠的基础上，双方的沟通确认机制才能成立。

每个希望成为临时Master的Slave，需要向默认Master发出请求（就是把自身的请求标识变量设置成特定数值，等待主站读取）。并等待默认Master的同意。

默认Master需要在调度每个站点通信完毕后，检查一次当前Slave的请求标识变量。这样可以回避多个从站都想成为临时主站的冲突问题，默认Master只对当前轮询到的站点应答这种需求。其余的请求阻塞。

如果确认是某个Slave的请求，且当前用户操作策略允许这样做，则通知该Slave同意（向该slave写入数值到特定的同意标识位，这需要在调度模块中加入一个优先级判断的调度等级）。同意写入成功后，停止站点调度，Master功能的调度现状被悬挂中止。并把485端口初始化为Slave模式，站点切换到Slave功能模式运行，等待临时Master的完成通知的写入到自己的特定标识变量中。

此时的485网络中没有Master。

在确认默认Master的同意后（这个确认的过程最好要稍加等待），这个Slave切换至Master模式并发送写入。写入成功后，给默认Master发出完成通知，并把自己切换回slave功能。

此时的485网络中也没有Master。

默认Master收到完成通知后（这个确认的过程最好也要稍加等待），把自己从Slave切换回Master模式，并在之前的停止悬挂位置开始继续站点轮询调度。

这和TCP建立连接一样，也需要三次握手。请求、同意、完成通知。三次握手的意义在于需要两次确认。任何需要考虑特定对方的通信方式，都要有三次握手。UDP没有这个问题就不需要。

超时情况，默认slave会自复位为slave身份，默认Master会自复位为Master身份。

很重要的是，modbus通信过程的细节，每一次读写成败记录和计数，都要呈现在HMI画面上，让操作员在现场就可以知道底层发生了什么。有助于现场诊断和修复。

通信的切换可能会产生冲突和反射。只要传输和确认机制可靠，站点的身份转换可以很快完成，冲突状况持续很短。有错误没问题，逐渐减少，直至消除就可以了。

默认主站和临时主站，都可以在切换操作的3秒钟之后，强制恢复之前的身份。不管标识位变化正确与否。

最差的状况也就是：在故障情形下，每个站点都把自己切换至slave状态，在几秒钟之间，没有主站，让全网恢复寂静，之后再启动某个主站。这需要完善的站点淘汰机制做为基础，本帖的实例中就已经具备了这个功能。

其实，这个需求的modbusRTU实现，并不具备多大现实价值，只是做为玩法讨论和编程策略推演。其它通信有很好的方式，比如UDP。

上述这套机制的本质就是：在Modbus协议报文的纯粹数据部分中，封装另一个通信协议。这和以太网的协议嵌套的做法一样。