納尼？點亮指示燈也能作為話題，也值得你老萬拿來做話題寫一篇所謂技術文章？

嗯吶，今天就要從最基本的問題入手，寫一篇標準化編程的文章，讓大家看看我們一直推行的標準化編程是如何處理這種簡單問題的。也讓各位檢測下自己，平常對最簡單的編程問題的理解是否到位。

指示燈么，最簡單的應用是指示電機的運行。最開始在繼電器邏輯的時候，通常是直接從電機的相線中抽一路出來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里簡單處理了。而其實即便如果有重疊的可能，也可以通過計數等方法來實現更精確的邏輯。