我们都知道，FB/FC的外部接口类型中有IN, OUT和INOUT三种。

其中的IN和OUT都很简单直接， 分别对应了输入和输出。

而对INOUT接口类型， 其实一直以来了解并不清楚。 以前给人上课的时候，有学员问起， 也就简单说是IN和OUT功能的组合，既能输入，又能输出，搪塞过去了。

而自己内心其实并不明白有什么用处。 所以在设计FB块的时候， 对INOUT数据接口是从来不用的。

后来学会了PCS7，看到它的库函数的控制字， OP_DWCMD通常都使用INOUT数据类型，便也有样学样，在自己做的FB函数的时候， 也把和WINCC通讯的接口数据放在INOUT。反正对于FB来说，可以不在管脚上接入实参。翘空使用倒也方便。

对于PCS7来说，使用CFC编程， 语法限制，是不允许往INOUT接口上接线的。 倒也正好印证了WINCC的功能。WINCC读写的是管脚对应的背景数据块的数据，如果和IN数据一样接线了，数据被强制写入了， 就无法在WINCC上面更改了。

而其实， 如果把WINCC接口数据安排在IN数据接口，只要调用时不要接入实参， 效果是一样的。 子程序中对IN变量的复位等write操作，结果也会正确体现在WINCC变量中。

或者STAT静态变量， 也同样可以。

但最近，在与朋友聊天的过程中， 突然意识到，自己以往对INOUT数据类型的认识， 肤浅了。

从头做一个实验，FB内简单功能：

然后调用2次，并监控：

发现，FB在两次调用中对MW10数据读取后均进行了修改。 影响到了MW10原本的值。 而且有趣的是， 监控程序设计的对输入时的值和调用完成后的返回值均显示了。 第一段输入时为0， 返回值1；第二段输入时值为1， 而返回值则为101 。

在这里INOUT的功能， 分明相当于高级语言里面的传地址， 对应VB里的ByRef。而IN接口其实是ByVal。

既然传的是地址， 那本质上只是一个指针，而数据的类型就可以无限复杂，可以通过这一个指针的地址， 把一个复杂的对象引入到函数中。

复杂到可以是Struct，可以是UDT，Pointer乃至Any。

但是很遗憾， STEP7 V5.5对FB类型却不能支持。 而FB才是名副其实的对象---Object

而事实上， 非但STEP7 V5.5不支持FB对象，即便到TIA PORTAL环境， V13 SP1, V14也一概不支持。

但好消息是， 到V15，支持了！就是在刚刚我要寻找这个功能的时候， 西门子发布的最新版本， 支持真正的面向对象了！

FB的INOUT管脚，数据类型可以选择已有的FB函数，这意味着什么呢？

意味着可以把一个设备当作一个完整的实参，送给一个大FB了。

比如一个反应釜的大设备， 包含了进口阀，出口阀，搅拌电机， 温度测量等对象， 那么在设计反应釜对象的逻辑时，可以直接使用已有的底层的设备对象，直接把相应的设备的实例的名字输入到反应釜FB中。 程序逻辑中不管是要发出启动指令， 还是读取运行状态， 都可以直接访问相应的值， 一个管脚接口搞定。

而至于电机和阀设备，使用的外部输入输出点是多少， 这里就完全不需要关心了。

FB块这个样子：

调用则这样子：

越来越有IT范了！

而美中不足总有的。 比如我一套反应设备，所服务的对象不是固定的， 而是根据调度指令要切换的。这在柔性制造中很常见。 比如示例图中的NM-4131， 还要切换到NM-4231,NM-4331, NM-4431,貌似就没有办法实现了。 比如我想建立一个数组NM[4]，接口处替换以NM[i]，在目前的版本的portal软件中， 我找不到解决的办法。

上个月， 曾经出过一道题目，<【求助】PORTAL编程题，可能与指针和间接寻址有关> 相信大多数人一头雾水,不知道我真正目的是什么？

现在该知道我说的是什么了吧？

文章中提到的接口为FB这个应用，其实类似pcs7里的sfc type中块触点功能，但凡面向一个unit级的对象写程序的时候都需要这种功能如文章中的反应釜，unit的下一级就是controlmodule也就是我们讲的电机阀门单体。sfc type块触点比粗鲁的把接口直接设计成FB要高效的多..

variant数据类型 是用于接口。

你真得用用。因为它正是你“宣扬”的那种模块“通用”！“乱七八糟”的数据类型都能进一种功能的函数，然后处理再输出。

最大的好处是：不容易出错。

我试验用的IN接口是FC，不带背景数据，实参能读写。

好了，看明白了，就是说博途FB的IN_OUT接口可以支持FB数据类型了。题目本来是讲FB的IN_OUT，但文中开头也把FC包括了，让我产生了误解。

对于FB来说，因为带有背景数据，一般是不需要填写实参，但特殊用途下，把接口分为IN、IN_OUT、OUT似乎也是有必要的；那么，对于FC来说，一个接口类型“IN”在STL编程环境下既可以读也可以写操作，够了！为什么又要分成几个接口类型呢？

确定 对于FC来说，一个接口类型“IN”在STL编程环境下既可以读也可以写操作，够了  ???

这真是颠覆了我十几年的认知啊！ 

IN ：在调用开始时， 从实参复制到形参

OUT : 在调用结束时， 从形参复制到实参

IN_OUT : 在调用开始时， 从实参复制到形参；在调用结束时， 从形参复制到实参

难道不是这个规律么？

而对于IN，假设实参为指针， 那么调用开始的时候传递的是指针， 在块内对指针指向的寄存器进行了操作。 这样即使在块结束后没有形参到实参的输出，但是指针指向的寄存器已经操作了。这就有点类似"IN_OUT"的效果了... ...

我做的试验如下：

1，新建FC8，FC8新建IN接口“IN0 INT”

 2，在OB1中调用FC8，赋实参“MW70”——》#IN0，

 MW70可读写！

但同样的程序在FB中，MW70是不能写的，这必须由背景数据块再赋值给保留的接口，这引发一个问题：有必要在FB接口再填写实际参数吗？

你这是什么版本？ 这完全不科学啊！ 我无论在FC还是FB， IN实参是不可能得到回传值的啊。

你的这个现象，应该是软件BUG，造成的显示问题。

因为这里面存在一个悖论： 假设你的结论成立，即IN实参在每次调用FC后会得到回传值。 按照你FC8里的程序，每个扫描周期，IN实参都会累加1。 也就是MW70会持续增大.... ...  事实上并没有！

你仔细想想，对不对？

是的，会持续增大。

但是，我在调用FC8之后，加了两个指令：当MW70 > 99时，复位MW70

我用的是step7 v5.5，或者明天我上传测试程序

严格意义来说

 FB的  IN参数在FB块内就是只读Read Only的，在块外是可读写的

           OUT参数在FB块外是只写Write Only的，在块内是（Step7 允许读写，Portal报警但还能用）

           IN-OUT参数应指在无论FB块内/外都是既读又写的，所以参数实例就只能在IN-OUT接口定义

Interfac.rar

我的测试程序见上面附件，说明如下：

 OB35 100ms定时调用FC1，FC1可重用

FB为什么不可以？FB的接口根本不需要再填写参数，直接对背景数据读写就可以了。FB的IN_OUT接口可以支持FB、FC和DB，但你用FB的IN接口一样可以支持FB、FC和DB，但因为FB已经有背景数据，不要再重复赋实参了。

终于明白了在说什么。 

原来说的是FC

而我文章只关注了FB。 

FC作为一个更简化的模块形式， 系统没有做足够多的资源来严格区分导致的。 

但其实也做了某种形式的保护， 在LAD中对IN写操作就报错。 

无非是stl没有做详尽的语法检查，挡住你犯错误。 

然后你分明是故意钻漏洞给自己难堪，还非要不依不饶的问， 为什么为什么为什么？

就好比超市有专门的入口通道， 也有专门的出口通道。 你趁着保安喝口水的功夫，没注意到你，从入口通道退出来了， 然后立马就翻脸，问明明入口，怎么可以出！！