作者：Ben Martins
當我被詢問是否想去海邊去檢查一輛懷疑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處於開啟或關閉狀態。關於J1939的更多資訊請參閱網站上的連結。
我已經包含了一個連結檔，其中包含轉換為可讀格式的源位址值。你可以在論壇上找到有關於連結檔的更多資訊。
我們很確定的一件事是對於這類的非道路機械而言，要獲得詳細的線路圖是很困難的一件事。
到達現場前，我試圖去找到一張線路圖，發現那張線路圖與此機械完全不同。幸運的是，我們似乎有一張與機器互相匹配的線路圖。
我重新繪製了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有機會加入它的冒險旅程。
