Trace是PLC中程序执行的某个局部场景的底层细节的真实记录，一小段时间内的每个扫描周期的变量数值都明确记录下来。

通常的Modbus程序不需要Trace。但如果通信调度变复杂了，就需要通过底层执行细节来纠错和改进。通信数据变化太快，在线监视根本不管用，用Trace就能帮上忙。下面的Trace截图，是检测当前正在通信的从站号，和获得了优先权的从站号。可以看出执行过程是否按照调度设计的完好执行了。

多个从站根据自己的临时写任务的出现，来平行请求优先权。只有一个站点会获得优先执行权，其它站点排队等候。先执行的站点会把自己全部的写任务一个接一个完成后，才会释放优先权。释放优先权之后，如果有其它排队等候的优先请求站点存在，就会切换到下一个优先站点。如果没有，就会继续执行当前站点常规的非优先的读任务。

Y轴的iJob是任务队列数组中每个任务的角标序号。数组长度是0～22。Write_PRI [iJob] 是某个写任务优先申请的标志位，提出申请的时候置1，一旦被成功执行就置0。

从站的常规任务执行后，关于下一个常规任务是否执行，会进行判断。第2张截图表明，当上一个任务执行后，如果后面存在多个不执行任务的时候，会出现单扫描周期内任务序号自加2的现象。这是因为调度中有重复环节，经过调整如下。

但这种任务轮询的判断和执行方式，依赖于扫描周期的循环，有点慢。可以进行优化，把任务执行的判断放在自建循环里在单扫描周期内执行完。优化效果如下，站点执行时间缩短到40%，多站轮询显著加快。

之所以采用序号化的循环方式，是因为任务调度是基于一个给定的任务数组。而任务数组的预设存在，是因为模块化编程对于特定的设备而言，其内部的最大功能集合是已经预设存在并且对于这个设备而言是永远不变的。这是基于设备的稳定性，导致的模块稳定性，是模块化编程的一个特点。对于非模块化编程的程序员而言，没有模块化的层层抽象分隔的约束，只是简单一个个通信任务的独立存在，不必采取这种数组化的任务轮询模式。

上面几个截图展示一下利用Trace调试改善高速变化的控制结构。没有Trace会非常费时费力。同时间接展示了模块化编程的优点，复杂问题通过分解隔离，程序可扩展性和调试效率明显提高，这在面向过程的传统程序结构中是很困难的。

到时候找机会试试，之前一直没有用过Trace图。

这个Trace图变量你选择的是那些？是通过模拟量输入通道来做的？

和外部的无关。就是程序内部的2个变量，一个是正在通信中的从站号，另一个是获得优先权的从站号。从这两个数据的变化能看出，调度是否按照设计完好运行了，以及暴露一些错误。

我开始理解有一点偏题了，我理解为通过监控通讯信号波形，来确认主、从之间的通讯信号幅值，判断通讯质量，来预防可能的通讯风险。

，原来你是利用这2个位信号，来判断指令被调用、执行的实际情况。

明白了，感谢。

这个图总结的很好

同一个485端口以不同波特率与不同从站通信。

1、2、3号站不在线。4号站波特率19200，5号站1200。

从Trace看轮询快慢细节

 测试中发现，这么做对模块电气特性还是有点压力。

自动检测每个Modbus从站的实际通信波特率，并把485端口设定到该值。可以在现场匹配不同的速度设定值，省了改程序。

下面例子，把5号站点的波特率从9600改为19200，因此正在进行的通信会失败断掉，该站点会被淘汰并退出轮询。

启动波特率检查，程序会自动搜索5号站的实际波特率。成功找到后，把485端口波特率设定为19200，并恢复正常通信。