最難還是模擬量

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然而因?yàn)镾MART 200的資源限制，我已經(jīng)窮困到程序塊中接收這個(gè)地址的TEMP變量都沒有了。

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

我實(shí)在是太難了！

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

有人會(huì)替我擔(dān)憂我在子程序塊中使用了M變量，是否會(huì)帶來錯(cuò)誤，會(huì)導(dǎo)致程序塊不能被重復(fù)調(diào)用。 這完全不必?fù)?dān)心。 因?yàn)樵俣嗟膶?duì)象實(shí)例， 使用的同一個(gè)變量，用過就丟了，無所謂。

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

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

即，打一個(gè)補(bǔ)丁處理一下。

審核編輯：劉清