1205 【万泉河】 FB与FC在实际使用中除了背景数据块之外没有任何区别……是这样的吗？

经常见到一些科普性网文，在探讨比较PLC中FB与FC的异同。 比如各自的变量数据类型的比较，不同之处等等。 这当然很好，可以给与刚入门的新手一些知识普及。 这部分工作是我无暇顾及的。

但也经常见到一些言辞凿凿貌似客观的结论，如：

FB与FC在实际使用中除了背景数据块之外没有任何区别

我先来带大家识别谬误的方法。 有一句常识叫做：证有易，证无难。

一件事，你只要有证据证明它存在， 那就很容易就证明了。 但反过来却不是对称的。 要证明没有的时候，千难万难。

比如你要证明家里面有蟑螂，只要抓住它，或者拍到证据， 那就证明了确实有。但如果你仅仅因为自己没看到，而断定没有，则很难作为证据。 想要证明家里面没有蟑螂，恐怕穷尽所有可能，也证明不出结果。顶多是推断出一个猜测。 所以正确的表达应该是，我尚未发现家里面有蟑螂，或者蚊子、老鼠。

对于上述的技术观点，稳妥的表达也应该是：

FB与FC中除了背景数据块之外我没有发现任何区别。

因为很有可能， 你没有发现但别人有发现。 你平常不注意的细节，别人发现了。而且别人不仅发现了，而且认为很重要。生死攸关的那种重要。

那么我（你）没有发现，而别人有能力发现了区别，这部分就是能力差距所在。

如果你是一个爱好学习和思考的人，如果以前也恰好有上面相同的认知，那么恭喜你， 学习提高的机会来了。又发现了自己认知的盲区，又有了可以提高的机会。

我发现的FB和FC的区别在哪里呢？而且是我认为的非常重要的？

在于FB的管脚允许翘空。即IN, OUT, IN/OUT都可以翘空。

允许翘空之后，在调用的逻辑中，就带来了相当大的自由度。

比如我有FB1和FB2的分别一个实例调用（当然，同一个FB也一样）

比如FB1的输出结果会作为FB2的输入条件，类似于启动条件，或者故障报警等等，那么在FB实现的方式可以有三种：

即

1，FB1的值挂到FB2的输入管脚上

2，FB2的值挂到FB1的输出管脚上。

3，在FB1和FB2的调用管脚均翘空的情况下，用单独的梯形图或SCL语句来实现逻辑。

如果是SCL实现，则为：

"块_2_DB".IN1:= "块_1_DB".OUT1

而如果FC的方式呢，则只有一种了，两个FC的调用均挂实参，而且还需要规划一个全局变量M或者DB用于挂到实参上。 这大概也是我说PLC编程可以不用M而很多人觉得抹不开的原因。

所以FB方法相比FC的方式，自由度提高了3倍，你可以在实际使用中，根据各种优先原则，随意选择其中最合理的方式。

我们再重复一下这个事实：

FB的管脚允许翘空。即IN, OUT, IN/OUT都可以翘空。

讲没有区别不是事实，是因为你没发现区别，而我讲可以翘空，则是毫无疑问的事实。

有人会反驳， FB的管脚如果是UDT或者STRUCT等复杂数据类型的时候也会有不允许翘空的情况。而且针对IN和OUT和INOUT情况还各有不同，不同品牌平台的情况也各有不同。

总的来说，任何一个品牌平台，如果允许复杂数据类型翘空，我都非常欢喜，如果不允许翘空，我就非常懊恼。这也是我好多年来一直提倡不用UDT的主要原因。 有记忆力的读者可以去翻看我写过的关于不用UDT的系列文章。

也所以，我给所有PLC平台的建议是，你环境所提供的FB的功能的时候， 要尽可能的允许管脚翘空，而不要为了所谓的帮我核查遗漏项，而逼迫我必须在管脚上挂实参。 挂实参未必带来便利，反而会带来很多不便。

我在年初的时候写过一篇文章：《0220 【万泉河】FB的管脚能空着就尽量翘空着吧！》，链接也附在本文尾部了。看来写这篇文章， 又有些超前了，我以为本文的阐述的事实早就被全行业成熟高手们共知， 没想到还远远不是。 所以，读者应该先读完本文，再去了解前文，理解起来可能会更顺畅些。