我在做模擬量處理模塊時，留了一個未解決的難題，一個小尾巴。即因為程序塊中使用的TEMP變量資源已經耗盡，所以被逼無奈使用了一個全局變量MD20，做了數據的傳遞功能。

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

對那里面留下的缺憾，其實我并不怎么著急。 模塊化的設計工作就是這樣，有遺憾不可怕。 可怕的是遺憾太多，牽扯到整個系統架構， 牽一發而動全身，導致不敢動。

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

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

但當調試結束，發現了一個問題，長久以來西門子以及眾多同行都忽視的問題。

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

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

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

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

想到了這部分的數據在內部程序塊中只使用一次，并不總是參與數值計算。同時，模塊在調用時，輸入的是常量，在運行中也不會變動。 所以，可以考慮用字符串的形式輸入。

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

0;10;Bar;0;50;Hz

字符串中使用分號;將所有數據分割。

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

所以，編制了一個對字符串分割的函數Split

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

由此，用一個字符串指針4BYTE替代了原本的多個浮點數，程序塊的資源終于省出來了。

我在幾個周之前， 還分享過一個做BCC校驗的程序塊，使用場合我沒講。 其實，也是出自同樣的原因。

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

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

算是對數據校驗的另一種另類應用。 關于相撞的幾率，我還沒算過。與浮點數的表達規則有關，可以單獨再研究。 不過未來即便有更嚴謹的應用場合，我們還可以多個校驗算法，比如BCC和CRC校驗同時上陣，估計就想撞也撞不到了。

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

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

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

審核編輯：劉清