オフィシャルな解決方法

https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl にもFAQ的に書かれている。ここで書かれているのは、planner buffer queue size (設定すると status として出力できる) を見ながら、一定のキューサイズを保つ、という方法である。

しかしこの方法には以下のような問題がある

• planner buffer queue size を status に表示させるのが面倒
  • 毎回 $コマンド送るの？みたいな
• キューサイズを決めるのが難しい
  • 少なすぎるとスムーズに送れず、多すぎると止まるまで時間がかかる
• どっちにしろ入れたキューは消せないため、うまくやらないと止まるまで時間がかかる

Hold & Reset

次に思いつくのは Hold してから Reset するという方法である。Grbl は Hold など一部のコマンドはリアルタイムで処理されるため、キューサイズに影響されない。

つまり、動いているときに Hold させて即時停止させるということは可能。そしてその状態から Reset を行えばキューをクリアできるため、実質的にジョギング相当になる。

しかしこの方法には以下のような問題がある

• Hold -> Reset の遷移が安定しない
  • Reset during cycle エラーがでたりする (位置がずれてる可能性がありますよということ)
• Hold → 実際の Hold までディレイがある場合 (ネットワーク経由でHoldするとか) 停止までの時間が安定しない

ということで使えない。

インターバル方式

ということで別の方法を考えた。これは1つのGcodeあたりの実行時間を一定とし、一定時間ごとにキューイングする方式。

理想ジョギングはステップ単位で進むわけではなく、フィードレートのみに依存しているわけで、それに近い挙動をすることができる。

インターバルは Grbl へ送信してキューに入るまでの時間よりも長い時間をとる必要がある。ネットワーク経由だと少し大きめに設定する。

例えば 0.3sec インターバルでフィードレート800mm/minで送る場合、4mm ずつ送ることになる。

この方法のメリットは

• 一定時間(インターバル)以内に必ず動作が止まる
• 追加の設定が必要ない
• 実装が簡単

デメリットは

• インターバルよりもキューイングに時間がかかった場合スムーズに送れない

ぐらい。

実際のインターフェイス

実際はステップジョギングと可変フィードレートを併用できるのほうが嬉しいため、以下のような挙動にした。

• マウスダウン直後は1ステップ送る
• 終了後1秒間そのままでいるとステップから計算した可変フィードレートで上記インターバル方式のジョギングを行なう

かなり自然なジョギングができるようになって満足