星爷的大话西游是一部大家耳熟能详的影片，不仅好看而且富有很多哲理，让人看完受益匪浅。比如其中紫霞仙子的“我猜的中开头，却猜不中结尾”，就道出了世间之事，即使是神仙也未必能够都预料的到，所以对于我们这些活跃在热线上的普通人要适应这种“新常态”，以“平常心”待之。闲话少叙，下面说一个热线的故事吧。
热线上的客户编写了一个很简单的逻辑程序，程序包括两个块。OB1主循环程序和FB1功能块程序，FB1在OB1中调用。OB1中对RS_result（M100.2）进行置位操作，在FB1中通过操作OUT参数oRS_result来对RS_result（M100.2）进行复位操作。详细的程序如图1、图2所示。
图1 OB1程序
图2 FB1程序
通过上面程序，我们期望实际的运行结果是，如果Set_trig（M100.0）为true则对RS_result（M100.2）进行置位操作，如果Rset_tri（M100.1）为true则对RS_result（M100.2）进行复位操作。程序简单吧，结构也很清晰，清楚的我们一眼就能预知结果。
可结果真的是这样吗？实际测试后发现，当Set_trig（M100.0）为true时，RS_result（M100.2）的输出结果却不为1，即无法实现对RS_result（M100.2）的置位操作，如图3所示。
图3
显然，这与我们实际想要实现的功能不符。根据逻辑分析来看，程序本身似乎没有问题，那么问题出在哪里呢？
让我们发动一下我们的小宇宙来分析一下吧！对于NETWORK1这个简单的不能再简单的语句而言，不可能有错啊，那问题是不是出在FB块的调用部分呢？我们来设想一下：当Set_trig（M100.0）为true时，程序会对RS_result（M100.2）进行了置位操作，但结果却是该变量被复位了。也就是说在执行FB1块时又将RS_result（M100.2）复位了，可是在FB1中的复位条件Rset_tri（M100.1）并不满足啊，为什么在执行FB1块后会将RS_result（M100.2）复位了呢？难道是PLC有问题？非也非也，这可是德国产品啊，质量没得说。那问题出在哪里呢？
要理解清楚这个问题，我们先要从FB功能块内部参数的传递机制说起。从很多场合我们都可以了解到：FB块区别于FC块主要在于每个FB块都需要一个指定的背景数据块，这个指定的背景数据块用来存放FB块的实际参数。其工作原理是，对于FB块定义的IN类型接口参数，在FB块被调用执行时，将实参传递给背景数据块中形参的对应地址，并用于FB内部的逻辑运算；对于FB块定义的OUT类型接口参数，在FB块被调用执行时将FB内部的逻辑运算结果给出到背景数据块中形参的对应地址，然后再将背景数据块中形参的对应地址的值传递给实参，得到实际的输出结果。
根据FB功能块接口参数传递的机制，我们可以看到，在FB块执行过程中，输出RS_result（M100.2）的值取决于其对应的形参在背景数据块中的地址DB1.DBX2.0，如图4，而实际的DB1.DBX2.0在执行FB块时一直为false，所以每次执行完FB块后，DB1.DBX2.0将false赋值给RS_result（M100.2），所以只要调用了FB1，那么实际得到的RS_result（M100.2）的结果就被修改为false，即我们上面实际测试时的结果。
图4
我们可以验证这个结论，即通过修改DB1.DBX2.0的值，可以直接改变输出参数RS_result（M100.2），而不论OB1中是否对RS_result（M100.2）进行了置位操作，如图5所示。
图5
既然我们已经分析出问题出现在FB块上，那么这个问题如何解决呢？
我们知道对于FB功能块，除了IN、OUT类型接口参数，还有一个IN_OUT类型接口参数。对于IN_OUT类型的接口参数，在调用执行时首先将实参读入，然后进行逻辑运算，Zui后再将逻辑运算的结果传递给实参进行输出。可见相对于OUT类型接口参数而言，IN_OUT类型接口参数是要先读入实际参数的值，这样就可以保持上面的逻辑运算结果不会因为FB块的调用执行而被修改。
所以我们可以将FB1作如下修改，如图6所示。
图6 FB1
图7 修改后在OB1中调用FB1
修改程序后进行测试，结果与预想的一致，即可以通过Set_trig（M100.0）、Rset_tri（M100.1）对RS_result（M100.2）进行置位、复位操作，如图8所示
图8
现在我们简单总结一下：FB功能块在调用时，外部实际参数通过输入、输出和输入/输出接口传递给其背景数据块对应的地址。在FB内部，程序直接操作背景数据块地址进行逻辑运算。对于FB功能块的使用我们要特别注意参数传递的规则。这些规则很隐蔽，一般不易引起我们的重视。并且在出现问题时，如果不了解这些规则那就真的是“猜的中开头，猜不中结尾”，出错成为新常态了。
