现在都是模块化编程，每个FB实例负责自己内部。而在扫描周期中，各个实例都是依次执行，有先有后。

在多个FB实例都使用同一个资源的时候，如果没有特殊处理，扫描在前的实例，就占有了资源使用上的潜在优先。

也就是：在同一个周期中，后面的实例已经产生了更高优先级的使用需求，而前面的实例不知道，依然按照自己的所知去使用IO，可能会耽误后面的，强迫后面的不得不等待。

我的方法是：加入公共环境变化的预判。让最前面的实例，也知道位于它身后尚未被扫描的实例，在本周期已经出现了比自己更优先的需求，那么自己就会在本轮放弃IO使用，代码提前Return，让扫描快速滑过，直达身后的特定实例。扫描中每个沿途的实例都会这么做。

下图Trace中的每个FB实例的各个任务，都存在于L1-L4四种优先级中。当某个实例正在执行这四种优先级中的一种的时候，其它的实例代码会提前Return，对应状态数值会显示从-1到-4的基准变化。

提前return的结构如下

前面Trace中的变量，都是Surveilance的结果。