軟體篇 PART1
前言
HMI 軟體技術含金量可說大不如前，看看強國 HMI 這價錢是要逼死誰：
不過這些廠商還算有良心，因為即使你買回來，編輯軟體會鎖簡體 Windows(不過可以用 VMware or VirtualBox 裝簡體 Windows)。再來現在電子零件普遍上漲，那你說賣你這麼便宜有賺頭嗎？筆者去對岸出差時，客人要求把我司 HMI 跟強國 HMI 外殼打開比較，這樣說好了，強國 HMI 很「乾淨」(沒幾個零件)。
重點是如果使用上有什麼問題，你要叫人來罰站也很難，也不像台廠好凹，還可以要求加一些有的沒的功能。所以設備廠(台廠)就筆者所知，還是寧可多花一點錢買台系或日系品牌，畢竟也沒缺那一點錢，但已對台廠構成很大的生存壓力。
再來是現在單獨做 HMI 的廠商很難生存，因為現在大部分 PLC 廠自己也生產 HMI(往往兩者一起買還有優惠價)。當然日系再怎麼優惠還是貴，這也是一些台廠還能生存的原因。加上最近中美貿易戰，台廠應該可以喘口氣。
最後是現在只要你願意花大約 10 萬 RMB 的代價，就可以買到完整的 HMI/SCADA source code。比請一個工程師一年的薪水還便宜，好像很划算吼？不過想想買回來也不是馬上就能換錢，這 50 萬行 code 難道你要自己維護嗎？話雖如此，這樣的資訊也造成 HMI 軟體工程師的生存壓力，恭喜各位老闆又多了一個砍薪水的好理由。
就像前篇講過的，技術有他的時效性，據說台灣首台 HMI 軟體是交大計算機工程系(資工系前身)第一屆某高手開發的，筆者之前有些年輕同事剛好也是該系畢業，筆者開玩笑說你們第一屆學長都賺飽移民了，你們還在搞這個會不會覺得很 #%$^%#$*(後來這些名校精英也都跑光了)......事已發展至此，難怪老工程師不但不被當成家有一老如有一寶，反而如同雞肋食之無味棄之可惜。
以技術趨勢來說，第三代 HMI/SCADA 肯定是往 Web、分散式計算發展。據說歐洲某品牌 PLC 直接內建 Web server，套上 browser 就是 HMI。不過以 Web 來說技術變化太快，還處於百家爭鳴的狀態，WebAssembly 2017 才剛推出，要與 WebGL 等整合還要一段十日，尤其是少了硬體加速應用場景會很受限。不過第三代筆者應該是沒機會參與這場遊戲了，就只好在這邊講古了。
編譯背後的理由與機制
幾乎所有的 HMI editor 在你上傳檔案到 HMI 前都會要求你「編譯」：
(取自台達 DOPSoft，再次強調筆者不是台達前員工)
陰謀論的說法是廠商怕檔案被破解，偷偷對原本的專案檔加密。這種說法其實只對了一小部份甚至全錯。
首先專案檔裡面存的是什麼？
所以算到最後，除非 HMI 用昂貴的 x86 當 CPU，不然只剩一條路就是在 PC 上先把這些 XML, JSON 轉換成二進制、HMI CPU 處理起來最順的格式，例如把 JSON object 全部轉成 struct 用指標串起來，記憶體對齊都先算好...然後再上傳！這就是編譯的真正目的，示意圖如下：
有些第二代 HMI (筆者稱 Linux based HMI 為第二代)剛推出時被客人嫌切換畫面太慢，就是沒有把這點弄清楚，而且因為 Linux 把什麼都視為檔案，結果把畫面資料也全當成檔案來存(手上拿著鎚子看見什麼都是釘子)，您說 access file system 有可能快過 pointer operation 嗎?在 Linux 這也不是沒有解，mmap(map or unmap files or devices into memory)就可以試試看，筆者當時提出這個想法時大概是人微言輕，沒有人理會，有興趣的朋友可以參考看看。
上圖中 Resource 裡面提到了 font
依照前面的解釋，相信您已經猜到，HMI editor 應該不會上傳真的字型(*.ttf)到 HMI。除了效能問題外主要是字型版權問題(不過真的有公司傳 .ttf，那家 HMI 貴死人就是了)，像是前陣子鬧的蠻大的"字體公司追殺YouTuber！"事件，一般 HMI 的作法是：
(取自台達 DOPSoft，再次強調筆者不是台達前員工)
陰謀論的說法是廠商怕檔案被破解，偷偷對原本的專案檔加密。這種說法其實只對了一小部份甚至全錯。
首先專案檔裡面存的是什麼？
憑印象畫的，不過所有的 HMI 都大同小異就是了。重點是「畫面資料」那一塊佔據最大的空間，按照新手工程師的想法，這一塊直覺上用 XML 還是 JSON 儲存比較恰當吧?因為 XML, JSON 很適合表現畫面元件階層、圖層的概念(例如網頁用的 SVG 也是 XML)，反正現在 PC 那麼快(事實上筆者接觸過的客人，很多都是用公司發的筆電，已經很舊了，如果拿這個跟他們扯，他們會嗆回你一句「那你說服我老闆買新筆電給我啊!」)...
既然專案檔裡面存的是 XML, JSON，那 HMI 上直接 parsing 就好了，幹麻還要搞什麼編譯，原廠一定在搞鬼!?
其實 Joel Spolsky (Stack Overflow, trello 創始人) 在他的文章 Back to Basics (中譯: 回歸原點) 已經講的很清楚了：「...每個編譯器作者都知道字彙和語法分析是編譯過程中最慢的部份。簡單的說，字彙分析和語法分析時牽涉到大量的字串處理(前面已經發現這是很慢的)和大量的記憶體(也是已知很慢的)，然後還要在記憶體中建立一個抽象文法樹。而且還要假設你擁有足夠的記憶體可以一次載入所有資料...」(來源: 回歸原點)
也許有人會想，那我在 HMI 開機時偷做不就好了?抱歉，雖然現在 Linux-based embedded System 記憶體通常不小(>= 64MB)，這又會踩到另外一條紅線，就是開機速度變慢，而且您不要以為客戶只會做幾頁畫面，上百頁都有可能(例如一堆說明頁)，而且畫面會弄到多複雜也很難預料，所以這招行不通，母湯喔~
所以算到最後，除非 HMI 用昂貴的 x86 當 CPU，不然只剩一條路就是在 PC 上先把這些 XML, JSON 轉換成二進制、HMI CPU 處理起來最順的格式，例如把 JSON object 全部轉成 struct 用指標串起來，記憶體對齊都先算好...然後再上傳！這就是編譯的真正目的，示意圖如下：
有些第二代 HMI (筆者稱 Linux based HMI 為第二代)剛推出時被客人嫌切換畫面太慢，就是沒有把這點弄清楚，而且因為 Linux 把什麼都視為檔案，結果把畫面資料也全當成檔案來存(手上拿著鎚子看見什麼都是釘子)，您說 access file system 有可能快過 pointer operation 嗎?在 Linux 這也不是沒有解，mmap(map or unmap files or devices into memory)就可以試試看，筆者當時提出這個想法時大概是人微言輕，沒有人理會，有興趣的朋友可以參考看看。
上圖中 Resource 裡面提到了 font
依照前面的解釋，相信您已經猜到，HMI editor 應該不會上傳真的字型(*.ttf)到 HMI。除了效能問題外主要是字型版權問題(不過真的有公司傳 .ttf，那家 HMI 貴死人就是了)，像是前陣子鬧的蠻大的"字體公司追殺YouTuber！"事件，一般 HMI 的作法是：
- 用無授權問題的點陣字
- 用抓圖的方式把字型存成 bitmap
第二種作法當然是用多少轉多少，不會全轉。不過嚴格來說還是有版權問題(威x數位要感謝筆者幫你們開闢新財源)，筆者 1x 年前就當面被老外質疑過這種作法是否有侵權疑慮(怪了，我怎麼聽得懂英文?)。
編譯做的事當然不只有上面這些，後面還會繼續談到。不過筆者想起之前還在搞 HMI 時，曾經問過另一位超資深工程師：「你有沒有跟這些剛入行的名校精英介紹一下以前的作法」？他說沒有，他覺得前代 HMI 的軟體架構 !@#$%^&*...先聲明一下，筆者並非貴古賤今的那種人，只是說如果客戶覺得第二代還不如畫面難看的第一代好用，那到底是客人 !@#$%^&* 還是我們這些工程師 !@#$%^&* ?? 也許過去還是有一些東西值得學習保留下來的?
"The farther backward you can look, the farther forward you are likely to see."
過去能看到多遠，未來你就能看到多遠
- 溫斯頓·倫納德·斯賓塞·邱吉爾爵士
"The farther backward you can look, the farther forward you are likely to see."
過去能看到多遠，未來你就能看到多遠
- 溫斯頓·倫納德·斯賓塞·邱吉爾爵士
前輩：威綸7吋這個價錢還是太貴，再者會用威綸的通常是很簡單的小設備，也不需找人來罰站的。老實說我最怕叫人來罰站，曾經某次為了台x牌變頻器，台南派了5-6個課長、副理過來上海道歉，然後設備還是有問題....
回覆刪除要便宜當然還有更便宜的,我只是上淘寶隨便抓個數字說明而已,聲明一下,我跟威倫也沒什麼淵源
刪除台x也不意外拉,筆者服務過的公司也被這樣批評過XDD