#工作心得 為什麼通訊問題，常常比 PLC 邏輯還難查？
｜工程師日記 #2
我原本以為做 PLC 最難的是控制邏輯。
像是流程怎麼跑、Interlock 怎麼切、Alarm 怎麼判斷、異常後要怎麼復歸。
但做設備一段時間之後，我發現真正讓人頭痛的，很多時候不是 PLC 邏輯本身，
而是跟其他控制器通訊。
尤其是那種 RS232、Modbus、MC Protocol，或是各種廠商自己包一層的通訊格式。
PLC 邏輯錯，至少還有跡可循。
你可以看接點。
可以看 Step。
可以看 Timer。
可以看 Alarm。
可以看哪一個條件沒有成立。
就算程式很大，慢慢追通常還是追得到。
但通訊問題不是這樣。
它常常只丟給你一個很簡單的結果：
Timeout。
No response。
Communication error。
然後就沒了。
這時候你要開始懷疑很多東西。
線是不是接錯？
接頭是不是有問題？
站號是不是錯？
Baud rate、Parity、Stop bit 有沒有對？
Byte order 是不是相反？
Word address 是不是算錯？
手冊寫的 address 到底是 0 base 還是 1 base？
對方設備到底有沒有真的回資料？
還是其實資料有回，只是格式跟你想的不一樣？
更麻煩的是，有些設備錯了也不一定會給你明確的錯誤反應。
它不會跟你說：
「你這個 Start Address 算錯了。」
「你這個 Command 格式少一個 Byte。」
「你這個 Register 長度跟我手冊寫的不一樣。」
它只會安靜。
很安靜。
安靜到你開始懷疑人生。
有時候 PLC 這邊看起來是正常送出，對方也有亮燈，網路也 Ping 得到，Port 也開了，
但資料就是不進來。
或是資料進來了，但是內容不對。
然後你就會開始懷疑：
是不是線？
是不是設定？
是不是手冊？
是不是對方設備？
是不是自己眼殘？
是不是今天不適合上班？
PLC 邏輯錯，比較像是在找哪個條件沒成立。
通訊問題比較像是在找到底哪一層在裝死。
尤其是現場遇到那種舊設備、舊協定、舊手冊，或是文件寫得很有自信，
但實際做起來完全不是那樣的東西，真的會讓人很躁。
後來我覺得，通訊問題最難的地方，不一定是協定本身有多複雜。
而是它很常不告訴你真正錯在哪裡。
PLC 邏輯錯，至少還能追接點。
通訊錯，很多時候是先追到自己開始懷疑人生。
不知道大家現場最怕遇到哪一種通訊？
RS232、Modbus、MC Protocol，還是那種手冊寫得很完整，但實際完全不照手冊走的設備？
