0103 【万泉河】PLC程序块INOUT管脚的倒置用法

我们主张PLC程序要模块化，而后才能实现标准化。

那么程序模块内部，就不得使用全局的M或者DB变量。 尤其是，当一个DB数据在整个程序块内多个地方使用的时候，如果要更改DB变量，还需要满程序逻辑里面查找，替换，既增大了工作量，也给程序逻辑的稳定性带来了风险，通常，经过这样修改的程序块是不敢直接上线跑的，必须再经过一次重新调试的过程。

有的人脑子里的模块化，非常简单朴素。 不让在FB块里面用全局DB数据？那就是都给放到输入输出管脚上呗！简单说就是如果这个数据是既需要读也需要存，那就是INOUT。

然后随即就自我否定：不行，不行，那整个FB块岂不是成了插满了糖葫芦的稻草人了。 这样的FB块我自己做了都不喜欢用， 管脚太多，乱七八糟的，还不如我程序逻辑里面改起来直观呢！

是的。 这种直觉是对的。 不管FB的管脚有没有限制，限制数量是多少，在此之外，它更消耗的是使用者的耐心。 所以，使用者能承受的数量，才是其真正的上限。所以不可以滥用。

即一个完整功能的功能块，其外接管脚必须高效且用户友好的。 因为这是与用户（使用者）的交接界面。 与用户不相关的要尽量少。而与用户友好相关的，则可以酌情尽量多。 如我上篇文章讲到的阀门的开关状态一样。 虽然没用且多余，但因为用户友好，就很有必要。

而与用户无关的，比如SMART 200中随即分配的存储区地址，就要尽可能的用其它的方法实现，而不要简单依赖INOUT。 我在2024年出版的《西门子S7-200 SMART PLC编程技巧精粹—给SMART插上FB翅膀》中有详尽描述实现方法。

与本文有一定的关系，但不是本文所要展示的重点。

比如，一个程序块中，需要有一个或者一批参数，是整个系统公用的，即会是这个FB多次调用，但参数值相同，甚至还会有其它的FB，也共享使用了这个数值。 而为了便于上位机中统一设定参数，就使用了全局数据区中的数据。这个数据块可能名字就叫做“全局参数”。

这个问题是所有PLC编程中共性的问题，那么，以SMART 200来举例的话，就会是一个定义好的数据，比如VD100 。

再具体一点， 比如一批压力变送器，因为是同一型号参数的，其上限值会都是100.0，那么我们希望LIMIT_HI(VD100)=100.0， 程序块中直接重复使用LIMIT_HI(VD100)即可。 而不喜欢每个FB的调用管脚都要挂上100.0的数值。如我以前80模拟量程序做的那样。

那么，我们也可以有方法来减少这种用户友好性差的管脚。

解决方法是：

另外做一个FC/FB，把变量挂到这个FC的INOUT管脚上，被原本的程序块调用。

这样：

肯定会有人一眼就看出来错误了，胡闹！这个SBR公用参数的INOUT管脚实参是喂给程序块内部的，主程序块中如果要对这个值修改，方向反了，就存不进了。

对的。 这就是我本文题目称为倒置用法的原因。 我们就是要倒置使用FC块的INOUT，获得与本体INOUT相同的数据效果。

具体的实现方法是，增加一个DIR的管脚，其内部的程序逻辑是：

调用时：

经过2次调用，实现了减少INOUT管脚的功能。

同一个周期内2次调用，又是相当于前处理和后处理的方法。

实现方法原来如此简单。

更进一步，比如项目中模拟量变送器的类型有5种，分别不同的上下限值，然而整个项目的模拟量通道80个，如何自动辨别类型并获取参数，如何触摸屏中可以建立起公共的参数区，便于修改设定？

读者肯定可以自己动手实现。

而我这个冬天正在做的工作，正在编写的新书《西门子PLC标准化编程烟台方法—基于LBP基本过程库》，其中对其每一个库函数的调用，如：

每一个设备实例调用时，都还要在panels管脚上绑定固定的来自panels数据块的数据区，就非常令人不爽，就完全符合本文的标准，分明是程序逻辑本身的需求，对于程序调用者，对此毫无兴趣，原本可以对此不予理会。然而还不得不每次都面对。搞错了还会导致功能失灵。也不符合高内聚低耦合的需求。

所以就打算进行下改造，把这个管脚去掉（隐藏）。

经过了些实验，已经可以完成，下一步会写在书中。

而提前把这个办法写成小作文。分享给大家。

当然， 书中面对的是一个复杂数据类型的数组，实现起来更麻烦些。