电子说
纳尼?点亮指示灯也能作为话题,也值得你老万拿来做话题写一篇所谓技术文章?
嗯呐,今天就要从最基本的问题入手,写一篇标准化编程的文章,让大家看看我们一直推行的标准化编程是如何处理这种简单问题的。也让各位检测下自己,平常对最简单的编程问题的理解是否到位。
指示灯么,最简单的应用是指示电机的运行。最开始在继电器逻辑的时候,通常是直接从电机的相线中抽一路出来AC 220V 的电源,点亮220V的指示灯。后来为了安全,指示灯不使用220V了,换用24V直流指示灯,那就使用接触器的一付辅助触点,达到了同样的目的。
后来,发现,指示灯的灯泡是有寿命的,会坏,而如果一旦灯泡坏了,就无法正确指示设备的运行状态了。所以需要一个单独的灯检查的按钮,在按下LAMP_TEST按钮的时候,盘面的所有的指示灯都亮起, 这样检修人员就能发现哪个指示灯灯泡坏掉了。如果是PLC系统,这时就无法借用接触器的触点,必须使用一个单独的DO通道。
有了单独的指示灯的DO之后,还可以增加一个功能,即设备运行时灯亮,停止时灭,而如果发生故障的情况下,可以让指示灯闪烁。甚至,可以给不同的报警等级,设计不同的闪烁频率。通常为1Hz,在S7-200中是SM0.5 。
一段标准的指示灯的梯形图逻辑如下:
这样的逻辑,看过或者自己写过,不下几千回了。原理很简单,但每次都绕不过,想简化也没从简化,只能一次次无聊的重复。
在做标准化示范项目的时候,我对指示灯也没多想,想着无非在FB模块中多一个OUT管脚,用来安放指示灯,而在FB内部,把上述的梯形图重复一下即可。
还好,现在因为有上位机,设备的运行和故障界面大都从WINCC画面上都可以表示了。设备类的运行状态基本不需要在盘面安装指示灯了。所以示范项目做了很久也没做指示灯逻辑。
但后来有重要的工艺段,终于还是遇到指示灯了。而且是声光报警的那种:
我在FB中给简简单单加了个输出的管脚HA,然后就等着把报警灯的Q点绑在这里就万事大吉了。
可到FB调用第二次的时候,就发现,工艺设计的,两次工艺调用的指示灯是同一个!其实我就是从那个时候开始被梯形图恶心到的。关注我文章的人可以找到以前的文章《【万泉河】成败梯形图》仔细研读。
恶在哪儿呢? FB的OUT对输出是完全彻底的独占的!不仅仅管脚为1时Q要为1,而且输出0时,Q必须为0。必须从一而终,不许一女二嫁。即不许双输出,双线圈。
像我这里两次工艺用1个指示灯,如果简单直接绑定,那最后指示灯的状态只能跟随最后一次FB调用的逻辑状态。前面的绑定失效了。
所以,我被逼无奈,硬生生在逻辑之外又搭了个OR的逻辑:
你如果对标准化编程的理念有所理解,就会知道这个后补的补丁对我来说,有多不爽了。可以说,如鲠在喉,许久不能释然。
这完全违背了模块化标准化项目的原则,即逻辑和对象分开,剧本和演员表完全分开的规则。
好好的标准化示范项目,仅此一项,就不够示范了。但我在分享项目程序的时候,也特意留给了学员们,作为一个经验教训,留到今天来批判我自己的。
我承认,我过去对指示灯不够重视,没有把它当作一个设备类型,是错误的。新项目来了,我首先拿指示灯开刀,编制了专门的指示灯的FB模块。
其中2个INOUT管脚,分别用于控制输出闪烁和常亮。
然后还另外编制了用于简单同步链接的FB LINK。用于输出的LINK1和LINK2均为INOUT类型。
输入信号的上升沿时置位输出,下降沿时复位输出。效果上看起来是输出会等于输入信号。但本质上输入信号对输出不霸占。其它输入信号也可以用于控制同一个输出。
在程序逻辑内部的调用则为:
HA.HA_ON也是作为INOUT类型传入到实参来的。
我这里两套工艺是绝对不可能同时运行的,所以不会发生对指示灯的ON要求时间重叠,而导致不能正确点亮或熄灭。所以FB里简单处理了。而其实即便如果有重叠的可能,也可以通过计数等方法来实现更精确的逻辑。
全部0条评论
快来发表一下你的评论吧 !