过程中的故障异常，还是要靠PLC代码筛查捕获，并呈现到HMI上。

而具备良好这种能力的程序，并非一日而成，或者说一上来就设计出来的，是实践出来的。而Trace恰恰是加速这个代码优化过程的最佳迭代工具。这才是符合规律、顺其自然的Trace用法。现在的Trace还不适合做大海捞针的筛查。

Trace需要与程序内部自带诊断性质的数据结构，相互配合，才能更好发挥作用。

调试的方法本质上只有一种，那就是排除法。 排除法，越是在良好解耦的架构中，排除的效率越高。把问题局限化，收敛溯源的速度越快。

打断点和下一步的手段，其实在这个讲求解耦和面向对象的时代，有点过时了，那还是基于面向过程思维的产物，虽然它也有用。

这个时代的方法，应该是讲求在诸多模块和局部元素的层面，可以直觉化的迅速剥离排除无关性的。

比如下面这个Trace，我可以直觉性的看出：这几个相互竞争的设备FB实例中，它们各自的代码，在每个扫描周期中都具体干了什么。

这包括：在一个扫描周期中，从前到后的代码执行，哪个代码段被执行了，哪个代码段没被执行。在一个代码段中有好几条逻辑路径，它们各自在不同情况下，走的究竟是哪一条路径。在各个连续的扫描周期中，它们各自是如何随着外部情况变化，在不同的元素和路径中，来回动态切换的。从哪个代码段进入某个功能场景，又是在哪个代码段退出该场景的。等等

Trace是一种语言。平时编程用的各种语言都是静态的，Trace是实时动态的，可以讲故事。程序员就相当于导演或编剧，要设计分场大纲和剧本。

比如，在上图Trace中：

所有向下的凹槽缝隙，都代表着一个正在执行中的异步任务，当然了每个凹槽的任务都不同。凹槽底部放大后，可以看到并不平坦，都在讲述故事细节。

每一根向上树立突起的“杆子”，都代表着不同异步任务之间切换的一个间隔扫描周期。

而杆子的不同高矮，则代表了：在这个间隔的扫描周期中，它们各自因为不同的事件，动态的选择通过不同的功能元素和逻辑路径，切换到下一个异步任务。

这样就能清晰看到故事的进展。哪个模块被哪个模块，在哪个时刻，被背后捅刀了，等等故事细节。

我喜欢用单Byte变量。因为数值最大255，变化范围比较小，眼睛容易看。多byte变量，纵轴数值范围太大，直观上的阅读效果不好。

上图Trace中这些，都是单Byte效果的。可以把变量名字隐去，让画面清爽，即使不放大画面细节，从左到右一眼扫过，故事尽收，和看电影差不多效果。效率很高。

如果有任何元素，在某个特殊场景下，做出了违背设计初衷的细微举动，一眼就可以看出来。

如果Trace能同时支持的变量数量，从现在的16个上限，增加到64或128个，那么故事细节就可以更丰富更清晰了。而我就不用多弄几个Trace，来回反复拍电影分场了。

当然，现在的16个变量上限，却也带来了另外的好处，那就是：程序员必须精炼变量设计，以更内聚的方式，高效表达解耦的局部场景。这其实就是面向对象思维的精髓，而不仅仅是封装继承多态这些外形说辞。

变量的监视Code，可以根据喜好随意改变，调整可读性，看习惯。