星爷的大话西游是一部大家耳熟能详的影片，不仅好看而且富有很多哲理，让人看完受益匪浅。比如其中紫霞仙子的“我猜的中开头，却猜不中结尾”，就道出了世间之事，即使是神仙也未必能够都预料的到，所以对于我们这些活跃在热线上的普通人要适应这种“新常态”，以“平常心”待之。闲话少叙，下面说一个热线的故事吧。
热线上的客户编写了一个很简单的逻辑程序，程序包括两个块。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，即我们上面实际测试时的结果。
