1200PLC用Modbus RTU通讯

可以是可以，但是这包含了很多约束。实际意义不大。

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

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

• Master和slave功能的切换，依赖几个标识变量的数值变化。所以这些标识变量数据，都是来自别的站点，它们的即时性和可靠性就至关重要。

• 为此，Master功能的通信任务UDT中，需要增加一个标识位，它能够表明本次轮询中，当前这个读或写任务是成功还是失败。以此确认数据的可靠性。在此通信数据可靠的基础上，双方的沟通确认机制才能成立。

• 每个希望成为临时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建立连接一样，也需要三次握手。请求、同意、完成通知。三次握手的意义在于需要两次确认。任何需要考虑特定对方的通信方式，都要有三次握手。

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

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

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

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

• 最差的状况也就是：在故障情形下，每个站点都把自己切换至slave状态，在几秒钟之间，没有主站，让全网恢复寂静，之后再启动某个主站。这需要完善的站点淘汰和召回机制做为基础。

• 这种相互通知机制，其它通信有很好的方式，比如UDP。

这种实现，要求modbus通信的模块化和通用化、淘汰和优先级机制，完善的调度机制、过程和错误记录和显示，重启通信等功能，都比较成熟了，可以玩一玩。否则更多是折腾自己。没啥必要，不如用TCP了。

可以是可以，但是这包含了很多约束。实际意义不大。

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

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

• Master和slave功能的切换，依赖几个标识变量的数值变化。所以这些标识变量数据，都是来自别的站点，它们的即时性和可靠性就至关重要。

• 为此，Master功能的通信任务UDT中，需要增加一个标识位，它能够表明本次轮询中，当前这个读或写任务是成功还是失败。以此确认数据的可靠性。在此通信数据可靠的基础上，双方的沟通确认机制才能成立。

• 每个希望成为临时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建立连接一样，也需要三次握手。请求、同意、完成通知。三次握手的意义在于需要两次确认。任何需要考虑特定对方的通信方式，都要有三次握手。

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

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

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

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

• 最差的状况也就是：在故障情形下，每个站点都把自己切换至slave状态，在几秒钟之间，没有主站，让全网恢复寂静，之后再启动某个主站。这需要完善的站点淘汰和召回机制做为基础。

• 这种相互通知机制，其它通信有很好的方式，比如UDP。

这种实现，要求modbus通信的模块化和通用化、淘汰和优先级机制，完善的调度机制、过程和错误记录和显示，重启通信等功能，都比较成熟了，可以玩一玩。否则更多是折腾自己。没啥必要，不如用TCP了。

我现在项目中有一块ET200SP串口模块读仪表数据，是做主站还是从站？？