#工作心得 有些 Alarm 看起來有跳，其實跟沒講一樣
以前剛開始碰設備的時候，我以為 Alarm 很單純。條件成立、跳訊息、機台停住，現場看到 Alarm 之後照著處理，聽起來應該很合理。
後來做久才發現，Alarm 寫出來只是第一步，真正麻煩的是這個 Alarm 到底有沒有幫助現場判斷問題。
有些 Alarm 看起來很完整，設備也確實有停下來，畫面也有跳訊息，但內容只寫 Transfer Error、Process Error、step Timeout Error、Communication Error 這種很籠統的東西。
現場看到之後，通常還是不知道要查哪裡。最後還是要翻 log、看 PLC step、看 sensor、看 robot 狀態、看 GUI 顯示、看 Host 有沒有送錯命令。
這種 Alarm 其實很尷尬，因為它只是告訴你「出事了」，但沒有告訴你「哪一層出事」。
同樣都是 Timeout，差異其實很大。
如果只寫 Step Timeout，現場大概只知道機台卡住了，然後開始找人來看。但如果 Alarm 能寫清楚是等待 Door Close Timeout、等待 Vacuum ON Timeout、等待 Robot Complete Timeout、等待 Host Reply Timeout，那查修方向就完全不一樣。
以前會覺得 Alarm 越多越完整，後來才知道不是。Alarm 不是越多越好，而是要能把問題範圍切出來。
不然 Alarm 寫一堆，現場還是只能叫人來看。然後每一邊都說自己正常，PLC 說條件沒到，Robot 說我沒收到，Host 說我有送，GUI 說我只是顯示。
所以現在我在建立 Alarm時，不會只看它有沒有跳。
我會看它有沒有做到幾件事：有沒有寫清楚停在哪個流程，有沒有指出正在等哪個條件，有沒有讓現場知道下一步要先查哪裡。
如果沒有，那其實跟默停沒有差別。
