メモですが、一助になればと公開しました。

BBBでMachinekitを動かしている。

＋＋＋　joint following error　＋＋＋

解決。
QtQuickVcpファイル　run.py内にある launcher.set_debug_level(5)を1に変更。
それだけでした。

参考にしたサイトhttps://github.com/machinekit/Cetus/issues/21
そこに書かれているように、たしかにGCodeファイルが大きいと発生しやすかった。
デバッグレベルを5にしたのは多分自分…。
QtQuickVcpのインストールで参考にしようとやって気がする。

QtQuickVcpがbase_threadに影響するとは考えにくいので
デバッグログ出力の過多でservo_threadが遅延したのだと思う。
AXISがフィードバックをチェックして、許容範囲であるFERRORまたはMIN_FERRORにおさまらなかった
ということのようだ。

以下はそれ以前にもがいた跡。

Following errorに関するlinuxcncのページには３つの原因が書かれている。

要点だけ書くと、
1.小さすぎるferrorまたはmin_ferror
2. RTパルスが必要な速度に追いつくことができません。 BASE_PERIODが正しく設定されていないか、（このBASE_PERIODでは要求されたステップレートが不可能である）
2.b. 最高速度が高すぎる 最大加速度が高すぎる

私はそれ以外にもfollowing error が発生する原因はあると思う。

例えば、パルスを出力するハンドホイールを手動用に使っているが、
ホイールから入力したencoderのパルスをAXISのjog-countsに直接出力していると
すばやくハンドホイールを回転させた時に発生した。
このときの各AXISの最大速度設定は相当に低く、前述の原因には当てはまらない。

パルス指示をAXISにしたいのだけど、
AXIS側が最大速度で制限されすぎていて動作が実現できない状態。
なんだと思う。（ソースコードは読んでいない。たぶん私には読めない。）

GCode等の要求に対し、
パルス計算能力が足りない時、AXISの出力能力が足りない時、のどちらもfollowing errorが出る。
だから、AXISの速度設定は速すぎても遅すぎてもいけない？

パルス計算能力が足りなくなるのは普通はG０の時だ。
G０だと出せるだけの速度を出そうとするからだ。
machinekitではG０でも各軸のtrajection? kinematics?が行われているようだ。
私の構成ではZ軸だけモータも違えば、駆動方法も違うのでSCALE[pls/rev]が他の軸より高め。
それでZ軸が絡むG０でエラーが多い気がする。
そこでZ軸だけG０を使わないという選択肢が出てくる。
fusion360のCAMだと、径方向早送り保持というのがあるので
X,YはG０を使い、ZだけG０の代わりにG１を使うことができた。

それから、TRAJにあるMAX_LINEAR_VELOCITYは手動でしか機能していない様子。実験済み。

しばらく調子がよかったが、最近また発生した。
fusion360で送り最適化をいれたら治った。
エラー発生はG０での動作時だが、エラーはその少し先のコードでが理由で出ているような気もする。

あと
サーボスレッドの実行周期のばらつきが関係していないるんでは？と疑っている。
Beagle Bone Blackには処理が重いのかもしれない。

+++ can’t add linear … error -7  +++
これもfollowing errorの対処とともに出なくなったと思う。

以下はもがいた痕跡。

fusion360だと、円滑化、送り最適化を使えばこのエラーは出にくくなった。
円滑化は細かい直線移動を可能な範囲で円弧にする。
送り最適化はカーブでの速度を落とす。結果としてパルス出力に余裕が生まれる
どちらも、パルス計算能力の低いハードには優しい。

＋＋＋　バックラッシュ補正の確認　＋＋＋
なぜか、手動ではこれまでと逆の方向に動かした時に、指定より多く動いてから戻すという動きになっていて
バックラッシュの効きがよくわからない。
GCodeでの移動では単純にバックラッシュ分がプラスされて動くので、とりあえずそれで確認した。
もちろん普通の座標値の上には現れて来ない。