1218 【万泉河】翘空之美--每一个PLC工程师都应该了解的真相

写了一篇文章《1205 【万泉河】 FB与FC在实际使用中除了背景数据块之外没有任何区别……是这样的吗？》，从反馈的情况看，发现效果并不好。

太多的读者仍然纠结于FB能实现的功能， 用FC+DB也能否实现，纠结于使用FB，实例化之后会衍生出一大堆IDB等等。

然后纷纷表态，我喜欢这样， 我喜欢那样。

这本身就是理解错误。我们是在谈论一个客观的事实，你只能表达我发现，我知道，我没发现，我不知道。而不要去谈什么我喜欢和不喜欢。

对客观世界的认知不完整的情况下，是没有资格表达我喜欢和不喜欢什么的。因为那种喜欢和不喜欢是不够全面不够客观公正的。

没有人对我前面文章中列举的3种编程方法感兴趣。我觉得，，，，嗯， 这挺好的。 也只有烟台方法的学员能看得懂。

谁都别怪谁。

有一个读者，看了我的书《PLC标准化编程原理与方法》中介绍的BST库，看不懂，嫌西门子做的太麻烦。来跟我抱怨，VLV模块的管脚太多了！

QCLOSE

QOPENING

QOPEN

QCLOSING

这几个管脚有啥用？怎么用？乱糟糟的，太讨厌了！

我说， 你要是懂翘空之美，恐怕就容易理解了！

这几个管脚，在展示阀门的正在运行的状态，关闭，打开中，已开和关闭中。 正常确实没啥用，尤其QOPENING和QCLOSING这两位，简直是画蛇添足，多此一举。

这在以FC主打天下的模式下确实是这样，多几个没用的管脚，做块逻辑的时候多出来一堆麻烦，调用的时候，更是麻烦，还要给他们挨个儿分配实参。多出来的都是烦恼。

然而，你要是站在只是一个使用者的角度，就不需要管那么多了。 对于FB， 不用的管脚你完全可以不理会它们的存在。 就放在那里好了。 如果实在不想看，LAD里面可以选择隐藏，或者SCL语言里调用的时候直接不提及。

而更多时候，其实你是需要这个状态的。 这是一个窗口，可以观察到FB的逻辑内部发生了什么，逻辑走到了哪一步。

所以，调试程序的时候，只需要观察这些管脚的状态就足够了。 而不需要再去打开块，去看块的内部的逻辑。甚至如果一个FC/FB被多次调用的情况下，动态的监控还会错乱，还需要再指定是哪一次的调用。（博途中FC的调用是否可以指定？我还忘了观察了）因为当学会了框架程序也可以用FB以后，FC都用的越来越少了。 只用到系统提供的库函数的时候如果是FC，才有用到。

由于块的使用者可以不打开块逻辑而应用，所以块可以放心大胆的封装，加密，甚至不提供密码。

也是基于这样的原因， 哪怕是在SMART里面， 哪怕我曲线救国的方式用SBR实现了FB的功能， 这当然是出于不得已。我在库函数的管脚上也都给加上了QCLOSE、QOPENING、QOPEN、QCLOSING这样的没用的变量，而且为了调用时满足语法需求，给它们都绑上了L0.0的实参，而数值类型的，则用了AC变量。

我2019年写过的文章《【万泉河】给你的PLC程序洗洗澡》里提过。也是在SMART中没有FB时的无奈之举。这篇文章后来收纳到了今年出版的新书《西门子S7-200 SMART PLC 编程技巧精粹—给SMART插上FB翅膀》里，然而因为出版规范的原因，被编辑修理到完全面目全非。我不知道改后读者是否更容易理解到要表达的精髓。感兴趣的读者可以去找了两边对照着看看。

现在的好消息是，据说到2025年春季，SMART会发布新的V3.0，就会支持FB和UDT了。 而我在听说了这个消息后，通过内部熟识的渠道，给研发部门传话表达了我的期望，FB的管脚要尽量多的允许各种数据类型的翘空，越多越好！最终的结果会咋样，让我们翘首以待。

所以，我们一定要相信，FB比FC一定有优势的，西门子专门组织开发团队研发支持FB的新版本，也一定是有道理的。

最后再给一个总结：

只有懂得翘空之美才能写出优雅的PLC程序。优雅的PLC程序一定是在充分利用了翘空之美原理之上写出来的。