#工作心得 同事查了好幾天的設備卡住問題，我最後是這樣抓到的
之前現場遇過一個問題。
設備不是完全不能跑，也不是每次都會出錯，
而是只有在特定條件下，才會突然卡住。
這種問題其實最麻煩。
因為它不像 Sensor 壞掉，也不像 Robot 本體異常，
那種通常比較容易從 I/O 或 Alarm 去追。
這次的狀況大概是：
兩個 Load Port 同時跑。
LoadPort1 只下 2 片 Wafer。
LoadPort2 只下 1 片 Wafer。
結果會發生一個很奇怪的現象。
當 LoadPort1 跑到最後一片之後，
接著要跑下一個 Load Port 的第一片時，
設備會卡在搬送流程，最後跳 Flow Timeout。
畫面上看起來就是 Timeout。
但做設備的人應該都知道，
Timeout 很多時候只是結果，
不一定是真正原因。
如果只盯著 Timeout 發生的那一步看，
很容易越查越偏。
一開始這個問題同事也查了一段時間，
但因為它不是每次都發生，
而且條件又有點特定，
所以很容易被帶到其他方向。
可能會懷疑 Load Port。
可能會懷疑搬送動作。
也可能會懷疑是不是某個完成訊號沒有回來。
但我當下的想法是：
如果設備是「有時候可以跑，有時候不行」，
而且又跟片數、順序、兩邊 Flow 同時跑有關，
那它很可能不是單點硬體問題。
比較像是 Flow 條件在某個時機沒有對齊。
所以我沒有一開始就去猜是哪個 Sensor，
也沒有直接懷疑 Load Port 本體。
我先把搬送 Flow 跟 PM Auto Flow 用Data Trace工具抓下來。
這邊重點不是只看卡住那一刻，而是往前看。
卡住之前，是哪一個 Step 先跑掉？
因為 PLC 的 Flow 問題很多時候不是「卡住那一步」出錯，
而是前面某個條件太早成立，
導致 Step 先往前走了。
後來把搬送 Flow 跟 PM Auto Flow 一段一段對起來之後，
問題就慢慢浮出來了。
真正的原因不是 Load Port。
也不是 Robot 本體。
而是搬送 Flow 那邊，
PM1 / PM2 兩邊的 condition complete 沒有正確卡在「要搬往 PM1」的 Flow 上。
結果就變成：
PM 端的條件還沒真正對齊，
但搬送 Flow 的 Step 已經先超前了。
Step 一超前，
後面的動作自然等不到正確條件。
最後畫面上看到的，
就只會是一個 Flow Timeout。
但 Timeout 只是最後爆出來的地方，
不是最一開始出問題的地方。
這個問題後來沒有花太久時間就抓到方向。
我知道這種問題通常不能只看 Alarm 發生點，
而是要往前追：
是哪一個條件先放行？
是哪一個 Step 先走掉？
是哪一邊 Flow 沒有等另一邊完成？
是哪個 complete 訊號沒有卡在正確位置？
這也是我後來 Debug PLC 很常用的一個觀念。
不要只看 Timeout 發生在哪一步。
要看 Timeout 之前，是誰讓 Step 走到那裡。
很多設備問題表面上看起來是硬體卡住，
但實際上常常是 Flow 條件沒卡好。
尤其是多 Load Port、多 PM、多 Flow 同時跑的設備，
只要某一邊 condition complete 沒有對齊，
就很容易出現這種狀況：
單獨跑沒事，
一起跑才出事。
這種問題最麻煩的地方是，它不是每次都會發生。
它可能只有在特定片數、特定順序、特定 Flow 組合下才會爆。
所以有時候你在現場看到的 Alarm，
其實已經是最後結果了。
真正的原因，可能早就發生在前面幾個 Step。
做 PLC 一段時間後，我越來越覺得，
設備 Debug 最重要的不只是會看 Ladder。
而是要看得懂整個 Flow 的節奏。
哪個 Step 應該等誰？
哪個 Condition 是完成條件？
哪個訊號只是結果？
哪個 Timeout 只是最後被拖出來背鍋？
這些如果沒有對整體流程有概念，
只看當下 Alarm，真的很容易卡很久。
後來我對 Flow Timeout 的看法也有點改變。
Timeout 不一定是問題發生的地方。
它比較像是屍體被發現的地點。
真正的兇手，通常早就跑到前面去了。
