Grbl の現在のバージョン(v0.9)にはジョギング(手動で軸を送れる機能)がない。GUI にあったりするが、基本的には偽物である。

理想的な(というか普通の)ジョギングは、スイッチを押している間だけ設定したフィードレートで動くという機能なのだが、Grbl はGコード単位でしか駆動信号が出せないため、このような挙動ができない。

オフィシャルな解決方法

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秒間そのままでいるとステップから計算した可変フィードレートで上記インターバル方式のジョギングを行なう

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

  1. トップ
  2. tech
  3. Grbl でのジョギング
▲ この日のエントリ