星爷的大话西游是一部大家耳熟能详的影片,不仅好看而且富有很多哲理,让人看完受益匪浅。比如其中紫霞仙子的“我猜的中开头,却猜不中结尾”,就道出了世间之事,即使是神仙也未必能够都预料的到,所以对于我们这些活跃在热线上的普通人要适应这种“新常态”,以“平常心”待之。闲话少叙,下面说一个热线的故事吧。
热线上的客户编写了一个很简单的逻辑程序,程序包括两个块。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类型的接口参数,在调用执行时首先将实参读入,然后进行逻辑运算,最后再将逻辑运算的结果传递给实参进行输出。可见相对于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功能块的使用我们要特别注意参数传递的规则。这些规则很隐蔽,一般不易引起我们的重视。并且在出现问题时,如果不了解这些规则那就真的是“猜的中开头,猜不中结尾”,出错成为新常态了。