纳尼？点亮指示灯也能作为话题，也值得你老万拿来做话题写一篇所谓技术文章？
嗯呐，今天就要从最基本的问题入手，写一篇标准化编程的文章，让大家看看我们一直推行的标准化编程是如何处理这种简单问题的。也让各位检测下自己，平常对最简单的编程问题的理解是否到位。
指示灯么，最简单的应用是指示电机的运行。最开始在继电器逻辑的时候，通常是直接从电机的相线中抽一路出来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模块。
