Chinese Protocol Debugging Notes

疑難排解：擴充指令的除錯經過

擴充指令開發過程中踩過的坑，留著給以後加新指令、或回頭查證這幾個 結論時參考。

警報歷史讀不到

原本想比照 getpreg/getjpreg 這類「帶編號」的做法，讓 getalarm:nnn 指定讀第幾筆歷史警報（ERR_DATA 的第一個參數形式上是輸入序號），但 實機測試推翻了這個做法：解析序號本身沒有問題（除錯時直接回顯過， 1、2、5、8、9 都精準對上送出去的值），但不管序號給多少，ERR_DATA 回傳的都是同一筆。拿 TP 的警報履歷畫面對照，第 5、8、9 筆分別是 「重置」、SRVO-003、SYST-039，跟我們讀回來的 PROG-048 完全對不上， 用這幾組值測試下來，ERR_DATA 這個參數看起來不是拿來選歷史筆數的， 具體是做什麼還不清楚。TP 能翻歷史警報顯然是走別的機制，這個 driver 目前沒有找到等效的存取方式，不排除是還沒找到正確用法，不是斷定這條路 一定走不通。目前這個做法已經拿掉，要繼續嘗試的話，這裡是已知會 卡關的地方。要看完整警報歷史，現階段直接去 TP 的 報警 → 履歷 畫面。

ERR_DATA 會改寫傳入的參數

過程中也踩到一個真的坑：ERR_DATA 的第一個參數雖然形式上是輸入序號， 呼叫之後卻會被它自己改寫（實測變成類似警報總數的內部計數，例如 1447）。一開始拿 FOR 迴圈變數直接當這個參數傳進去，呼叫一次後迴圈 變數就被汙染，導致只跑一次就結束、還冒出不該有的分號。修法是每次 疊代用另一個變數複製迴圈變數的值再傳給 ERR_DATA，讓它去改那個變數， 迴圈變數本身不受影響。

這個坑不只 ERR_DATA，任何 KAREL 內建函式的參數，只要沒查證過是純 輸入，都不該直接拿控制流程用的變數（迴圈計數器之類）去傳，這個教訓 即使後來發現 ERR_DATA 這條路目前沒找到能用的方式，依然成立，留著 給以後用到其他內建函式時參考。

getjpreg 第一版卡住

第一版實機測試時整個卡住（收不到回應）。跟已經驗證能動的 GET_CURJPOS（mappdk_cmd.kl）對照才找到原因：GET_CURJPOS 是用 通用 JOINTPOS 型別呼叫 CNV_JPOS_REL(jpos, joint_vals, status)， 第三個參數是狀態碼，不是軸數。第一版誤宣告成 JOINTPOS6，又把第三個 參數當成軸數用，兩個都錯。改成完全比照 GET_CURJPOS 的寫法 （JOINTPOS、status 語意、用 UNINIT() 判斷陣列裡哪些是真的軸）後， 實機驗證多組不同數值的位置暫存器都能正確讀寫、往返一致，沒有再卡住過。 setjpreg 用的是反方向轉換（CNV_REL_JPOS），寫法一開始就跟 MOVEJ/CHECK_JOINT 一致，沒出過問題。

---

最後更新：2026-08-31