#工作心得 設備最怕的不是壞掉，是不知道從哪一層開始查
現場最常接到的電話，其實都長這樣：
「欸，機台卡住了」
「剛剛還好好的，現在不動了」
但最麻煩的從來不是壞掉，而是你根本不知道
要從哪一層開始查
做設備做一段時間之後會發現一件事：
讓設備動，不難。
真正難的是：
出事的時候，你能不能快速定位問題。
現在的設備架構其實都差不多：
PLC 負責控制
IPC 負責畫面 / 資料
中間再串各種通訊
這種分層大家都知道
但問題從來不是【有沒有分層】
而是這個分層在出問題的時候，有沒有用。
很多系統看起來有分層，
但實際一出事，就會變成這樣：
●IPC 畫面卡住
●PLC 還在跑
●通訊偶爾 timeout
每一層看起來都「好像沒問題」
最後只能 一層一層猜。
________________________________________________________________________
後來我慢慢會用一個比較實際的標準去看一個系統，
不是看它多複雜，
而是看它出事時好不好查。
1.每一層能不能單獨驗證
例如：
PLC 可以直接強制 I/O 測動作
IPC 可以在沒有 PLC 的情況下測畫面或邏輯
通訊可以單獨確認有沒有在傳資料
如果你的系統一定要整套一起跑
才知道對不對
出事基本上一定很難查
2.異常有沒有被留下來
很多現場問題會卡，是因為：
●訊號一閃就過
●當下沒看到就消失
●沒有任何記錄可以回推
比較好 debug 的系統，通常會做到：
●關鍵步驟有狀態記錄
●異常發生時會停在某個 step
●可以回頭看「上一個動作是什麼」
至少不是靠記憶在猜。
3.通訊問題能不能被切出來
最常見的地獄是：
PLC、IPC、通訊全部綁在一起
一卡住全部一起怪。
比較好的設計會讓你可以：
先確認 PLC 邏輯本身是正常的
IPC 顯示的是「最後一次有效資料」
timeout 有明確標示是哪一段
這樣至少可以先排除一層，而不是全猜。
4.現場的人看不看得懂現在在幹嘛
應該遇過這種狀況：
一個 bit ON，不知道哪裡來的?
邏輯分散在不同地方，
要整個程式翻一次才知道現在在做什麼
比較好的系統會做到：
有明確的流程或 step
狀態是集中管理的
看一個區塊就能知道設備目前在哪一步
這種系統，換人接手也不會直接崩潰
________________________________________________________________________
後來我對「系統切得好不好」的理解其實變得很簡單：
不是架構圖畫得多漂亮
是出問題的時候，你能不能少猜幾次
設備最怕的不是壞掉
而是壞掉的時候
沒有人知道要從哪裡開始查。
想問問大家：
你們在現場遇到問題時
是有一套固定判斷方式
還是也是 先猜 PLC，再猜 IPC，最後懷疑通訊？
只不過遇到問題的當下，真的都是先通靈才開始查修:))
