最難還是模擬量

說句實話，一開始，和大家一樣，我對模擬量是不太當(dāng)回事的。

我現(xiàn)在正在做的把LBP的架構(gòu)從S7-1500移植到S7-1200，然后再到SMART 200 +KTP觸摸屏。做了其它的塊，但對模擬量是不在乎的。心里想，自己都有80模擬量的標(biāo)準(zhǔn)答案例程在手了， 就沒必要在這方面多花心思了。 需要的時候隨時可以拿出來把例程的程序用上快速的很。

所以，就越過了模擬量， 想動手搞PID塊的移植。

但卻感覺無從下手。 那些參數(shù)值設(shè)定值和運行值的處理，完全沒有感覺。不知道對LBP的PID塊該如何解耦，哪些部分改掉換成SMART自己的控制， 哪些部分借用。

所以決定， 還是先把模擬量部分完善了吧！

然而一旦動手開始搞了，才發(fā)現(xiàn)這里面的問題反而是最多的。

當(dāng)然，這里講到的問題并不是說原本我做的80模擬量的例子錯了，或者不夠完善，不夠標(biāo)準(zhǔn)答案。

那里展示的只是調(diào)用的過程。

而我現(xiàn)在在做的就是FB塊的處理。 例子里面用到的那個模擬量處理的程序塊，功能還是太簡單了。

反對把物理單位作為一個參數(shù)，還要在觸摸屏上運行中或者設(shè)計模式進行修改。 然而即便去掉了單位， 對一個模擬量的處理，也還是有許多參數(shù)的。

在對LBP的程序塊進行簡化以后，它需要的參數(shù)分別有：

其中前兩者用于標(biāo)定量程范圍， 3-6用于判斷觸發(fā)報警，7-8用于對報警的遲滯處理。

有人或許會覺得啰嗦，就簡單標(biāo)定下量程的事， 搞這么復(fù)雜有意義嗎？

是的， 如果你還只是剛?cè)腴T階段實現(xiàn)控制任務(wù)就萬事大吉， 有人提出整改意見的時候再專心整改，那確實沒啥。

但如果你希望有一個一勞永逸的標(biāo)準(zhǔn)化的設(shè)計，但凡客戶有可能提出的刁難問題，都提前想到，都事先做在里面，就有必要提前做些準(zhǔn)備了。 多做比不做強，做了不用比用到的時候發(fā)現(xiàn)沒有相應(yīng)的功能而需要臨時打補丁，要強。

比如量程，如果設(shè)備運行期間有需要進行校準(zhǔn)，那么就會有需求要你給做成參數(shù)。 而如果系統(tǒng)中有模擬量不僅僅用于顯示，還要參與邏輯判斷， 那么多數(shù)情況下需要比較限定值后做出邏輯處理，那么就有了限定值參數(shù)和遲滯參數(shù)的需求。 哪怕系統(tǒng)中只有個別模擬量有需要，也應(yīng)該盡量全部都做到，即為標(biāo)準(zhǔn)化。

而這些參數(shù)值，一方面需要運行中修改設(shè)定，另一方面又不可能全部指望下載程序后在運行畫面中輸入?yún)?shù)。 最理想的方式是，參數(shù)需要有一個初始值。 這個初始值未必準(zhǔn)確，未必符合最終設(shè)備運行需要的參數(shù)，但它至少有個八九不離十，大致可用。 總比一開機全部都是0， 全部都是報警提示要好得多。

有過軟件開發(fā)的程序員都應(yīng)該了解這樣一個常識，所有軟件安裝后都要有一個初始配置。 比如微信軟件安裝后，會有基本的字體和配色，然而可以個性化修改設(shè)定。

對應(yīng)到工業(yè)系統(tǒng)工業(yè)設(shè)備，也存在一樣的需求。

然而，凡是對PLC編程有一定了解的人，都會知道，這個事情沒那么容易。 比如FB的IN管腳上一個參數(shù)值，你如果調(diào)用時給賦值了實參作為初始值，那么運行中就不再可以修改。 除非修改程序源代碼完全重新下載程序。

而如果不給設(shè)置實參， 那么它就會以統(tǒng)一的初始值，大部分為0。而且FB的多個實例之間還都是同一套初始值配置。

所以，要兼具上述兩種功能的話，上述的參數(shù)值其實需要2套，分別對應(yīng)上述的功能。 那么在程序初次運行時，先采用初始值，而后運行中這個值才可以修改。

對于模擬量信號，后面的3-8條重要程度低一些，甚至可以統(tǒng)一設(shè)置，比如限制值都分別設(shè)置為90%, 80%, 20%, 10%，總差不多。

然而量程的上下限，則只能分成2套了。

由此，我在SMART 200中規(guī)劃的模擬量函數(shù)庫的變量接口表：

這是已經(jīng)做到了極致的簡化，已經(jīng)沒有再簡化的余地了。

然而看到，最后一個變量的地址是LD55, 即用到了LB58，已經(jīng)接近了SMART子程序的上限。后面只剩下 LB59一個BYTE了。

即地址空間已經(jīng)用光了，再無空間可用了。

問題就出現(xiàn)在了這里。

我按照LBP的架構(gòu)功能實現(xiàn)的邏輯，其中有LOG15功能記錄了設(shè)備的運行記錄，最終觸摸屏顯示這個記錄時， 需要這個記錄的地址指針。 應(yīng)該是一個DWORD， 原本是在L1層中生成的，需要輸出到其OUT管腳， 外層使用這個管腳獲得地址。

然而因為SMART 200的資源限制，我已經(jīng)窮困到程序塊中接收這個地址的TEMP變量都沒有了。

所以迫不得已，我只好暫時先用了一個MD20的變量做了傳遞。

我實在是太難了！

因為這一段的功能，是LBP也尚未考慮到的，所以多出來的邏輯還是自己再想辦法實現(xiàn)的。

有人會替我擔(dān)憂我在子程序塊中使用了M變量，是否會帶來錯誤，會導(dǎo)致程序塊不能被重復(fù)調(diào)用。 這完全不必擔(dān)心。 因為再多的對象實例， 使用的同一個變量，用過就丟了，無所謂。

也會有人指責(zé)我違背了自己承諾的PLC編程不使用全局變量的規(guī)則。 沒錯，我這兒也難受著呢！

如果不較真，整個程序中僅次一處使用M量，也不傷大雅。 如果較真，以后可以再看看想辦法做個場景保存和恢復(fù)的功能。

即，打一個補丁處理一下。

審核編輯：劉清