簡單說，全局變量、局部變量是變量自身的身份。身份的不同是靠出生地決定的。而能否被全能局訪問，能被多大范圍空間訪問，即首篇文章中講到的作用域，是完全不同的概念。不能混而等同之。

然而，如果大家對寫程序并沒有什么原則目標， 只以完成設計任務為目的，以設備最終能跑起來為目的，這些概念不清楚也無所謂。尤其只在西門子平臺內談，沒有橫向的對比，就得不出更深刻的經驗。

所以，這個話題就放下了。估計當年的讀者們也都放下了，沒幾個人放在心上。

我自己最近在編寫《三菱PLC標準化煙臺方法》的書，在寫書的過程中，在做一些小例子來驗證功能。其中把西門子的程序移植到了GX WORKS2，寫完了GX2的章節。然后現在又把程序移植到GX WORKS3，為GX3的章節整理素材。就發現了問題。

簡單描述，就是原本在西門子程序中，有外部對FB塊內的靜態變量訪問，到GX2，也仍然這么做的。但移植到GX3時，發現了問題，編譯報錯。

經咨詢三菱標準化的學員，得到提醒， 說新的GX3平臺，靜態變量VAR多出來一個VAR_PUBLIC的類型，可以支持外部訪問。照著修改之后，果然沒問題了。

（很多人以為我做啥品牌的標準化方法，就一定要在掌握這個品牌全部的高精端的知識基礎上，其實恰恰相反， 我只是對標準化架構熟悉，而對這些具體品牌和軟件的使用，我反而時刻在跟學員們學習請教。）

我現在回過頭看我當年提出的問題，就很清楚了。靜態變量能被全局訪問，被很多人誤以為就是等同于全局變量，那是因為只在西門子的井底。當視界擴大到所有PLC品牌和平臺之后，就不一樣了。甚至GX2和GX3都不一樣。

GX2中VAR可以被全局訪問，而GX3中則不可以。

你總不能認為GX2中的VAR是全局變量，而GX3中的 VAR就不是全局變量了吧？

發現這個問題的起源的程序塊來自西門子官方庫BST，先后移植到GX2和GX3。而根源又是其設計的部分靜態變量要被WINCC訪問，即勾選了HMI/OPC可見的選項。

在PORTAL中，不管是否勾選，影響的只是WINCC訪問的權限，而在程序中FB外的訪問都是暢通無阻的。

我在上帝一篇中建議過加個開關，關掉被塊外部訪問的權限，現在看，GX3果然做到了。

而最近幾天，也有學員在開發自己的庫函數，跟我溝通相似的問題。問我與WINCC通訊相關的變量放在OUTPUT還是STATIC更合適的問題。

我給與的回答是，原則上來講，應該放到INOUT或者OUTPUT。而放到VAR STATIC是不合適的，不符合封裝的原則。比如我這次的移植，就出現了問題。

不能因為看到有西門子官方的例子程序這么做過，就理所當然的認為就是正確無誤的。他們的作者也是普通的工控工程師，也未必事事都嚴格規范。

而我很容易就從西門子官方出的《設計規范指南》中找到了理論依據。

其中的DA005規則：只通過形參交換數據

DA006規則：僅從塊內訪問靜態變量

有人會杠， 如果不讓從塊外訪問靜態變量， 那系統為啥要設計為可以訪問？

就如同我一直在推廣PLC中編程不要使用M全局變量的理論，有人杠我系統設計了就該允許使用一個邏輯。

答案是系統提供的功能是給非規范的程序準備的。未必所有程序，比如測試學習程序也需要完全遵守規范。

而倒過來說，如果系統提供的功能即符合規范規則，只要規范規則之外的用法系統即不允許。如我在GX3遇到的這樣。那么，連編程規范都不需要存在。西門子也不需要整理一個設計規范了。

你做的不對， 編譯都不通過，保存都亮紅燈的事，還需要寫在規范里面嗎？

規范里的所有違反規范的相反的做法，都是可以用的，無非是不規范而已。

所以，我們在GX3遇到的問題， 那些導致編譯錯誤的變量， 正確規范的數據類型應該是INOUT和OUTPUT。

有一些剛入門的工程師， 甚至連FB都不會用，從未用過的工程師，會看不懂我的這些文章，會質疑這些文章傳播的知識什么用，我不懂你這些道理，我甚至不需要用FB，不也照樣做出功能正常運行的設備嗎？

我借用某Z常說的一句話：“基礎不牢，地動山搖”。其實我不完全認同這個道理的。基礎不牢，不會導致你地動山搖，你在入門級別的工作并不受影響。而恰恰反過來，如果基礎牢了， 會有更高的起飛的空間。

就好比，田徑運動員基礎的動作姿勢如果不標準，在校級運動會可能沒什么大的影響，照樣有可能獲得校運會冠軍。然而當到了更大的天地間，就會發現姿勢標準的重要性了。而等到了奧運會選手的級別，所有的運動員動作一定都是最標準的了。因為那是基礎的基本功。

審核編輯：劉清