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 でのジョギング

シェーダープログラムはGPU内で動く。性質上並列(parallel)に実行される。

vertex shader

頂点ごとの処理内容。線分だったら始点と終点。頂点の最終的な位置を決定する。ついでに頂点ごとの属性 (attribute) から fragment shader に渡すものをどうするか決めたりする。

最終的に gl_Position にスクリーン座標を代入する。

fragment shader

ある断片ごとの処理内容。線分だったら始点から終点までの各要素を分割した1要素 (線分をレンダリングしてピクセル単位にしたときのピクセル単位)

最終的に gl_FragColor に vec4 型で色情報を代入する。

varying として vertex shader から渡された値は、各断片ごとに値が変更されて渡ってくる。

gl_FragCoord という変数があり、これには実際に処理しようとしているピクセル座標が入ってくる (スクリーン座標系)

gl_FragCoord から元の世界座標系を計算するのは面倒なので、fragment shader で世界座標系が欲しい場合 varying で座標を渡すのがてっとりばやい。


varying variables

varying は vertex shader と fragment shader とを繋ぐものだが、vertex shader でセットした値がそのまま fragment shader に渡るわけではない。fragment shader に渡るときに該当する fragment について計算された値が渡ってくる。

https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/varying.php

  1. トップ
  2. tech
  3. GLSL の覚え書き

ちょっと前に掘った


SketchUp と、歯車描画プラグインで書いて SkechUCam で gcode にしたけど、ぴったりサイズにしたらハメるのが硬すぎて厳しかった。細かい凹部はエンドミルでは削れないというのもありそう。

歯車描画プラグインは、ものによって SketchUCam と相性が悪くて使えなかったりする…… 機能がすくなそうなやつのほうがうまくいくっぽい。

  1. トップ
  2. tech
  3. CNC フライスで遊星歯車装置を掘った

複数シャンク径を使いわけたい場合、都度コレットを交換する必要がある。ググってみてもいまいち正しいやりかたが出てこなくて歯痒いが、以下のようにすると交換できる。

コレットナットを軸からはずす

普通に緩めて外すだけ

ナットからコレットを外す

コレットをちょっと押してみると、ナットの位置によって傾むくほうと傾かないがあることがわかる。

傾むくほうを下にして、そのまま下に少し強めに押すと外れる

傾かない状態

傾いた状態

ナットにコレットをつける

ナットの内側をよくみると、コレットの溝にはまるようにリングがついていることがわかる。そしてそのリングが一方が深く、一方が浅いようになっている (偏心している)

なので、深いほうを先に入れ、浅いほうに向けてコレットを押しこむとつけられる。

ナットを軸につける

普通に締めるだけ

いちいちナットにコレット脱着するのが面倒だ!!

ナットだけ追加で買って、1コレット1ナットをセットにしてしまうのが早い。これなら、緩めて別のナットをつけるだけですむ。

  1. トップ
  2. tech
  3. ER11 コレットの交換方法

CNC フライスで基板をつくる | tech - 氾濫原 の続き

穴開け用の φ0.5mm刃長1mmのエンドミルを入手したので、0.8mm 厚の基板で試した。

条件

配線パス切削:Vカッター (前回と同じもの)

  • S10000 F200 (前回と同じ)
  • 両面テープ固定 (前回はクランプ)

なぜかバリも全くでずに綺麗にできた。やはり両面テープのほうがZ軸が安定する。両面テープは切削対象部分にはできるだけ全部貼ったほうがいい(ビビらないように)

穴開け・外形切削:φ0.5mm 刃長1mm

  • S10000 F80
  • 0.9mm 厚まで切削

で綺麗にいった。

メモ

これとは別にもう一枚切削したが、そちらはちょっとZが安定しなかった。おそらく両面テープ不足。また、バリがかなり出てしまった。ビビったせいかもしれない。とにかく、固定はしっかりしたほうがいいっぽい?

φ0.5mm のエンドミルはかなり扱いが怖い。φ0.8のミルも注文したけどまだ届いてない。

0.8mm厚だと切削したパスが表面から透けて見えるので、部品の配置がやりやすい。1.6mm よりいいかも?

  1. トップ
  2. tech
  3. CNC フライスで基板をつくる 2