我在做模擬量處理模塊時(shí)，留了一個(gè)未解決的難題，一個(gè)小尾巴。即因?yàn)槌绦驂K中使用的TEMP變量資源已經(jīng)耗盡，所以被逼無奈使用了一個(gè)全局變量MD20，做了數(shù)據(jù)的傳遞功能。

然后做好了之后，我就去做PID模塊的移植了。

對(duì)那里面留下的缺憾，其實(shí)我并不怎么著急。 模塊化的設(shè)計(jì)工作就是這樣，有遺憾不可怕。 可怕的是遺憾太多，牽扯到整個(gè)系統(tǒng)架構(gòu)， 牽一發(fā)而動(dòng)全身，導(dǎo)致不敢動(dòng)。

而我留下的這種遺憾則無所謂，我只要心中隨時(shí)留個(gè)念想， 一旦有找到好的思路后，回來打個(gè)補(bǔ)丁，修復(fù)一下也就完美了。 而即便沒有打補(bǔ)丁之前，也不影響正常的使用。 這種問題，終究不是大問題，連bug都算不上。 只是完美主義者心中的一個(gè)結(jié)而已。

然后，我在做PID模塊的時(shí)候，很快就遇到了相似的問題。 原本，按照西門子LBP的數(shù)據(jù)結(jié)構(gòu)，我原本是可以輕松解決的，資源完全夠用。 因而這段時(shí)間都在做這部分的調(diào)試了。

但當(dāng)調(diào)試結(jié)束，發(fā)現(xiàn)了一個(gè)問題，長(zhǎng)久以來西門子以及眾多同行都忽視的問題。

即，PID的輸出值的量綱的問題。

通常，很多模塊都直接以%為單位，或者沒有單位，就0-1的一個(gè)小數(shù)數(shù)值了。

這在閥門開度等工況時(shí)是沒問題的，然而很多的PID的輸出回路會(huì)是變頻器，變頻器的運(yùn)行開度，100%對(duì)應(yīng)的是50Hz，那么，如果你在窗口上顯示PID回路的輸出時(shí)，如果仍然以0-100來顯示，操作人員使用中就會(huì)有些不方便。總要做數(shù)值的換算。 一不小心還容易遺忘，算錯(cuò)。

所以，我決定要增加這部分的數(shù)值輸入。 然而就同樣遇到了變量使用超標(biāo)了。

想到了這部分的數(shù)據(jù)在內(nèi)部程序塊中只使用一次，并不總是參與數(shù)值計(jì)算。同時(shí)，模塊在調(diào)用時(shí)，輸入的是常量，在運(yùn)行中也不會(huì)變動(dòng)。 所以，可以考慮用字符串的形式輸入。

即， 把原本的UNIT的管腳，改名為RANG_UNIT， 包含了上下限和量綱：

0;10;Bar;0;50;Hz

字符串中使用分號(hào);將所有數(shù)據(jù)分割。

S7-200中的字符串，在定義到子程序的管腳時(shí)，長(zhǎng)度只有4byte，所以它本質(zhì)上只是個(gè)指針。 而作為常量的字符串輸入時(shí)，則不占用任何寄存器資源。

所以，編制了一個(gè)對(duì)字符串分割的函數(shù)Split

每次調(diào)用， 只讀取指定的位置的數(shù)據(jù)。 我也順便做了轉(zhuǎn)換，即可以讀取到字符串放到S1指定的指針，也可以順便轉(zhuǎn)換為浮點(diǎn)數(shù)輸出到寄存器中使用。

由此，用一個(gè)字符串指針4BYTE替代了原本的多個(gè)浮點(diǎn)數(shù)，程序塊的資源終于省出來了。

我在幾個(gè)周之前， 還分享過一個(gè)做BCC校驗(yàn)的程序塊，使用場(chǎng)合我沒講。 其實(shí)，也是出自同樣的原因。

在LBP原程序架構(gòu)中，需要多次校驗(yàn)HMI上數(shù)據(jù)序列的修改，在數(shù)據(jù)滿足變化或者不變化條件時(shí)做出邏輯處理。 在PORTAL中的方法是直接對(duì)UDT進(jìn)行相等比較。 所以在數(shù)據(jù)區(qū)中建立了大量的數(shù)據(jù)備份。

而對(duì)于SMART這樣的小身板，自然是沒那么多資源來存放所有數(shù)據(jù)的備份的。 所以就想到了使用BCC校驗(yàn)來做。數(shù)據(jù)序列中任何一個(gè)數(shù)值如果修改，都會(huì)導(dǎo)致BCC校驗(yàn)碼不通過，縱然理論上會(huì)有某種巧合導(dǎo)致BCC相同，但幾率又是小到火星撞地球，而且又是與人機(jī)界面人工操作相關(guān)，并不關(guān)乎安全，可靠性要求也不高。 所以可以以此節(jié)省規(guī)模不菲的變量資源。

算是對(duì)數(shù)據(jù)校驗(yàn)的另一種另類應(yīng)用。 關(guān)于相撞的幾率，我還沒算過。與浮點(diǎn)數(shù)的表達(dá)規(guī)則有關(guān)，可以單獨(dú)再研究。 不過未來即便有更嚴(yán)謹(jǐn)?shù)膽?yīng)用場(chǎng)合，我們還可以多個(gè)校驗(yàn)算法，比如BCC和CRC校驗(yàn)同時(shí)上陣，估計(jì)就想撞也撞不到了。

我探討了通常意義的線性變換，PID，飛剪，卷曲等算法對(duì)我們做PLC編程的重要性并沒多高，甚至都可以認(rèn)為不是我們這個(gè)行業(yè)的必備的算法技能。

然而如果非要找一些算法功能的話，這里提到的拆分和校驗(yàn)，以及所實(shí)現(xiàn)的數(shù)據(jù)處理交換方式，某種程度上可以算做是了。

而且還會(huì)通用，多種模塊類型中都會(huì)遇到。

審核編輯：劉清