工廠鬼話｜設定裝置時，照說明書卻一直失敗，資深工程師會這樣處理
本文整理自實際案場經驗；為保護客戶，已省略場域名稱與可辨識資訊。
這台 VOC 裝置是Modbus裝置，
而設定最麻煩的地方，不是完全沒有回應。
完全沒回應，反而比較好查。線路、站號、Function Code、Register，一項一項往下找就好。
偏偏它每次都有回應，但兩個 Byte 組成的 VOC 數值，怎麼解都不對。
裝置自己的儀表板明明有數字；Gateway 也確實收到資料。站號、讀取位置、資料長度與 Byte 順序，全都照原廠說明書設定，結果仍然一直解碼失敗。
該檢查的看起來都檢查了。接下來，你會懷疑哪裡？
■ 最難查的，不是沒回應，而是每一步看起來都對
有時候不是沒有說明書最麻煩，而是有說明書但照著設定還是失敗，
這次麻煩的是，每一項都可以在說明書上找到答案。照著設定，封包也真的有回應，卻只有最後的數值對不起來。
但這台裝置是確定可以讀取數值的，因為之前維護廠商的軟體是有正常讀取的，
這情況下反而我們的產品很理所當然的會受到質疑，甚至我們自己的人員也會開始懷疑線路、Gateway 和其他原本正常的程式。
■ 照說明書都不成功，資深韌體工程師會開始大膽猜
這時候，資深韌體工程師常會做一件看起來很不工程的事：大膽猜。
不是毫無根據地亂改參數，而是當正常路徑都驗證過後，開始懷疑那個原本最不該懷疑的前提：
如果不是程式寫錯，而是說明書寫錯了呢？
說明書標示 LSB，我們就反過來改成 MSB。
結果數值出來了，而且和裝置自己的儀表板對上。
最後確認，不是線路壞掉、不是 Gateway 沒收到，也不是 Register 讀錯。
是說明書把兩個 Byte 的順序寫反了：上面寫 LSB，實際上要用 MSB 才能正確解析。
■ 設定資訊沒有交接，客戶就很難換人維護
這次會需要重新猜 LSB、MSB，不只是因為說明書寫錯，也因為原廠商實際使用的設定值並沒有開放給客戶查看。若接手時看得到原本的設定，我們直接對照就好，根本不需要重新猜一次。
1. 之前廠商或許知道說明書有這問題，但這就是資訊斷層，因為客戶或許不需要知道這問題，所以原廠商也覺得不需要說，反正有問題也是原廠商處理。
2. 原廠商的設定值，接手的廠商無法看到，不公開設定值也不是原廠商的錯，這也算是商業行為之一，這樣客戶就被綁定此廠商。
以上兩點也都是讓客戶的依賴性加重，這也是間接造成物聯網碎片化跟無法持久使用的原因之一，
若客戶被廠商綁定，那廠商若是不想負責，客戶則被動受氣。
客戶若想換廠商，又必須整套換掉，一來成本過高，二來下一個廠商也不一定比較好。
在雙方都越來越沒信任感的商業模式下，很容易就不繼續使用跟維護了。
■ Gateway 改 Modbus 參數，伺服器不用跟著改
這個案場使用的是我們自己開發的本地端 IoT 伺服器 LocalNest。
LocalNest 有一套獨特、也容易理解的裝置定義方式，讓 Gateway 與 LocalNest 的設定簡單而且彼此獨立，不必在 Gateway 改一次參數，又到 LocalNest 裡再改一次。
縮短測試時間是其中一個優點。工程師可以改完 Gateway 設定、重啟程式，再直接和裝置儀表板對值，少掉 LocalNest同步修改與確認的步驟。
■ 韌體很多怪問題，都是開發時累積下來的經驗
韌體工程師在開發時，常會遇到一些規格書無法直接解釋的怪問題。
有些是原生硬體問題。明明照規格書設計，實際執行時卻可能遇到斷點不會停、記憶體亂跑，或 GPIO 怎麼設定都不會動。
有些則是人為問題。腳位標示、接線定義或文件內容和實際狀況對不起來，甚至也遇過 UART 要 RX 接 RX 才會通。
這些問題不一定每次都能找到一個漂亮的解釋。
資深韌體工程師的除錯靈感，通常就是從這些開發經驗累積出來的。
當正常檢查都做過，還是找不到答案時，才會知道原本相信的規格、標示或前提也可能有問題。
■ 韌體有人帶著學，會快很多
這次真正需要資深工程經驗的，不是把 LSB 改成 MSB 這個操作，而是在照說明書仍然失敗後，想到說明書本身也可能有問題，接著再用裝置儀表板驗證這個猜測。
自己學韌體不是學不會，真正花時間的通常是卡住時不知道下一個假設該往哪裡走。有人帶著學，可以直接看到資深工程師怎麼確認現象、怎麼排除、怎麼猜，又怎麼證明自己不是亂猜。
所以韌體有人帶著學，真的會快很多。學到的不只是一組 LSB／MSB 設定，而是下一次再遇到說不通的問題時，知道該怎麼繼續往下查。