當我被詢問是否想去海邊去檢查一輛懷疑CAN通訊有問題的裝載機時，我期待可以花一些時間來欣賞北海感受海風。可憐的是，我知道我遙遠地去海邊是去一個許多海鷗在飛來飛去的回收場周圍。

我在這里要檢查的機器已經遭遇了數周的間歇性故障并且沒有明確的方式來使故障發生。操作員告訴我它有時可以工作幾個小時，但其他時候一開始運作就會出現故障。與往常一樣，確保你可以從客戶那邊獲得盡可能的信息，因為它可以說明你開始思考可能的故障。更重要的是，你應該嘗試重現故障來確認問題。不要去修沒壞的東西。而間歇性故障就在于它是間歇性的。由于沒有特定的方式來重現故障，我們最好先對機器的DTC進行掃描。

幸運地，我們有了一些儲存故障代碼，所有的故障點都指向CAN的問題。

有趣的是，機器的儀表還閃爍了警告燈表示發動機CAN訊號逾時以及DEF/AdBlue的警告燈表示噴射故障與扭力受限。隨著DTC的紀錄看一些進一步的方向，我們清除了故障代碼希望他能再重現。我們連接示波器以便我們可以在故障發生時捕獲一些信息。設置好示波器來監測在機器運作的期間的CAN網絡，考慮到儲存的故障碼，這似乎是最好的行動方案。這款裝載機的網絡并不復雜，因為在BUS上的ECM相對較少。然而這是一臺2015年的機器，運作的時間已經超過13000小時，并且對于要接近發動機艙較困難。

幸運的是，發動機的ECU相當容易接近，使連接上更直接方便。不過我沒有考慮到人為錯誤。下面是在我啟動機器后就捕獲到的數據，我立刻得出了結論。

如你所見，與信道A相比，信道B極度失真，這就是A-B數學信道具有失真物理層的原理。在我注意到明顯的問題之前我甚至認為我遇到了故障。在PicoScope7中，通道區為你提供設置的一些詳細信息，例如探頭、量程、耦合與濾波。是的，我忘了關閉20kHz的硬件過濾器。之前設置它是為了演示4*25 and 4*25A示波器的可用功能。帶寬限制是為了去除示波器中高于20kHz的頻率，因此與軟件中的DSP濾波器不同，沒有辦法取得這些資料。這個過濾器對于電流鉗相當有用，并且在察看可能有高頻干擾影響的訊號時(例如MAF傳感器與含氧傳感器)，但對于CAN訊號則不太有幫助。

在花了一些時間查看后我認為是接線問題，很明顯問題只出現在那個通道，最后才恍然大悟，如果我使用的是PicoScope6，我認為需要更長的時間才能意識到，因為你必須實際打開信道選項來查看帶寬限制是否處于開啟狀態。

在恢復了通道B之后，我們開始嘗試捕獲故障并利用新的J1939譯碼器來說明更好地了解故障發生時那些ECU與于開啟或關閉狀態。

我們很確定的一件事是對于這類的非道路機械而言，要獲得詳細的線路圖是很困難的一件事。

在我到達現場之前，我試圖去找到一張線路圖結果發現那張線路圖與此機械完全不同。幸運的是，我們似乎有一張與機器互相匹配的線路圖。我重新繪制了CAN連接部分如下圖：

我只想解釋一些，并沒有把所有在駕駛室的ECU都列出來。其他還有儀表板，遠程通信與其他單元，但那些與此故障無關。我仍然懷疑這張圖不是正確的，因為我認為NOx傳感器不會單獨出現在上面。然而，這就是我們所要做的。最有趣的部分是從診斷接頭到ECM的K線，它說明我們必須使用串型工具(CAN (J1939), J1587 or K-Line)來進行通訊的選項。

經過一段時間的駕駛和運作機器后故障終于出現在儀表板上。有趣的是，當我們試圖使用J1939協議來讀取故障碼時，我們無法進入ECM，儀表板出現故障。相反地，我們發現與ECM通訊的唯一方式是使用K線，然后我們又試了一次J1939，突然就可以通訊了。我們連接示波器來看看我們是否能夠發現CAN網絡中發生的事情。我們連接了兩條CAN線，但使用示波器的浮動輸入，這代表我們只需要兩個通道就可以進行此捕獲。

浮動輸入僅適用于 4*25/4*25A 范圍的示波器。我們很幸運，故障變得越來越明顯，這代表捕獲它變得更容易了。

上面的捕獲不是立即發生的，這是一個捕獲30分鐘的過程，希望你能看到，在這張波型圖的中間，通道A的數據包減少了，而通道B在前后都保持一致。

藉由使用J1939譯碼器和鏈結文件把譯碼后的源地址ID轉換成可讀的信息，我們可以看到當時發生了什么。我們知道發動機ECM是在故障時無法使用串型工具來與它通訊，因此找尋這個是我們的首要事項。

我添加了一個額外的譯碼表來更好地顯示這個過程。我在底部的觀看窗口添加了一個過濾器，這樣我們就可以只看到源地址存在發動機#1的譯碼數據。我們試圖查看發動機#1在失去通訊期間是否有脫機，或是發生其他事情。正如我們在發動機ECU上量測的那樣，這種下降與接線問題無關。透過將鼠標停在圖表上的數據包上，我們大致了解波型的變化發生數據包約在500附近。

你可以看到在觀看窗口頂端的已譯碼信息，并在窗口底部看到發動機#1的過濾數據包。我在兩個窗口標記了發動機#1的數據包，約在500附近。如同你所看到的，發動機#1在485數據包之后沒有向網絡提供進一步的流量，但所有其他ECU很多且在線將數據發送到總在線。ECM丟失與我們看到的故障碼以及我們無法透過CAN總線通訊(只能透過K線)讓我們更加確定這個問題。

為了確保我們了解所有可能性，下一步是在ECM在開啟和關閉時檢查電源和接地的供應。我們想要確保當ECM關閉時不會失去電源。由于ECU的電源數量很多，因此最好使用8通道的示波器來捕獲所有的內容。當然，你仍然可以使用4通道是波器來檢查且拆分為多次捕獲。

當ECM在線，我們可以看到在一個緩沖區2秒的時間內，我們有來自發動機#1的1110個數據包，還記錄了27.9V的電壓。當你認為此捕獲是在發動機工作進行時，這與預期的一樣。我們還可以看到接地電壓值極低，為33.5mV。

相比之下，當發動機#1在關閉時，我們只有兩個數據包，電源跟接地電壓穩定。有了這些信息后，我們決定告知客戶至少需要檢查發動機的ECU。與許多工作機械一樣，讓它停止運作比單換零件成本更高。因此透過CASE訂購了一個ECU，且請求他們來安裝并程序設計ECU。有趣的是，負責這樣工作的技術人員表示，它懷疑是否這樣能解決問題，因為它從未看過這故障。然而，證據很清楚，我們沒有看到其他可能導致的問題。透過PicoScope記錄所有內容，我們可以回顧每個步驟，來確保我們仍確定進行更換。六個月后，機器仍按預期工作。

我希望這會有所幫助，這表示新的J1939譯碼器可以與串型工具一起使用來幫助診斷。在此感謝Darren Savage有機會加入它的冒險旅程。