MicroSlice V2.5では公式で紹介されている方法として、Inkscape等のソフトから出力したGcode情報を読み込んで出力する方法と、PicLaserから出力したGcode情報を読み込んで出力する方法がある。
図形や文字等を焼く場合はInkscapeから、濃淡のある画像を焼く場合はPicLaserからデータを作成し焼く。
Inkscapeから出力する場合、まずInkscapeで図形を描く。テキストはパス化しておく。作業サイズはmm単位で、公式では100×100のサイズにしているが、筆者のMicroSliceでは85mmx85mm程度が限界であったため、85×85にしている。
図形作成後、エクステンションのLaserengraverからLaser…を選択する(説明書の手順に沿ってプラグインのファイルを入れ替えておく事)。
Laser engraving speedはレーザーの速度を設定する。この速度はレーザーの出力や対象素材によって調整する。
ファイルに出力したら、Grbl Controllerを起動し出力したファイルを読み込む。出力したnc形式のファイルはテキスト形式なので、Gcodeが分かればメモ帳で手直しも可能だ。
後はMicroSliceのスイッチをVに合わせた後、「$H」「$L1」コマンドでホームポジションに戻しレーザー出力に設定後Beginボタンを押下すれば出力が始まる。
画像を出力する場合、画像をBMP形式にしておき、PicLaserソフトで画像を開く。
設定変更で調整を行う。Feed Rateはレーザーヘッドの移動速度、Pixel Resolutionで密度で読み込む画像の大きさによって調整し、出力サイズを調整する。MaxとMinは最大・最小のレーザー出力値で、Minには素材を焼かない最小限の出力を設定しておく。これらのパラメーターの調整により、対象素材にどの程度の濃さで画像を焼き付けるかを調整する。
出力したファイルをGrbl Controllerに読み込ませる。
PicLaserが出力するデータは左下から右上にくまなくレーザーヘッドを動かし、画像の濃淡部分でレーザーの出力を調整するだけなので上記の様にヘッドの動きは画像エリアの四角全体となる。MicroSliceのスイッチをRに合わせた後、「$H」「$L1」コマンド入力後にBeginボタン押下で出力が始まる。
MicroSliceに限らずArduinoのGrblのライブラリを使用している殆どのハードに共通していると考えられるが、ステッピングモーターやサーボモーターにはバックラッシュと呼ばれる厄介な性質がある。
モーター自体やギヤ等に遊びがあり、モーターが逆回転した際にこの遊びの分のズレが生じる。ヘッドが右移動している時のA地点と、ヘッドが左移動している時のA地点でこの遊び分ズレが発生してしまうため、ハード的かソフト的に位置の修正が必要となる。しかし、残念な事にArduinoのGrblライブラリでは2014年12月時点このバックラッシュの調整機能(英語ではBacklash compensationと呼ばれるらしい)はArduino Unoには入っておらず将来的にも対応の予定はなさそうだ。
このバックラッシュの何が問題かと言うと、Inkscapeから出力したデータを実行した際、ヘッドの往路と復路で位置ずれが発生してしまう為データ上では揃っているラインがずれて出力されてしまう。例として、十字を出力すると右と下のラインが左と上のラインとずれてしまう。
文字の場合顕著に出るのが「T」等の文字だ。Tの左側と右側で下のラインの高さが異なって出力されてしまっている。
良く見ると、「C」もデータ上では綺麗なCの形をしているのだが、微妙に潰れてしまっているのが分かる。他の文字に関しても歪んで見えるのはこのためだ。ただ、このズレは1mmもない為物理的なサイズが大きい図形データを出力する分にはさほど気にならない。
だが、PicLaserから出力する画像データを出力すると困った事になる。
PicLaserが出力するデータは45度出力の場合右下から左上に走査出力し、左上から右下に走査出力とヘッドが往復しながら出力するのだが、往路と復路でヘッドがずれるため出力結果を見ると画像が二重にずれてしまう事になる。サンプルのデータだと「T」の文字の周辺が縞模様として表れている。
購入前にMicroSliceのデモ動画や画像を見ていた際文字出力が一部汚く見え、精度が悪いのかと不安に思っていたのだが、このバックラッシュの為図形が歪んでいたせいであった。MicroSlice自体の精度はかなり高い。同じデータを出力すれば、高精度で歪みも含め毎回同じ出力を同じ位置に繰り返す。このズレが補正されればかなり良いツールになるのだが・・・。
画像データの場合、ヘッドの移動はワンパターンなのでデータを修正する事で改善は可能だ。
まず、PicLaserから出力するデータの場合、最小値を30とした場合、焼くデータが無い場所でも30の出力を続けるため無駄にレーザーの寿命を削り、時間もかかる。このデータを削除する事でヘッドの無駄な出力と動きを省略する事が出来る。そして、1ラインの幅が非常に小さい為復路のデータを省略しても十分綺麗な結果を得る事が出来る。
データから無駄なデータと復路のデータを省略して出力した結果、綺麗に出る様になった。
間引いているため良く見ると薄く間引いたラインが見える事があるが、肉眼で見た場合あまり分からないレベルである。
周囲で白色データが多い画像の場合、周囲の無駄な動きもデータファイルのサイズもかなり削減出来る。
削減前(コマさん)と後(トトロ)のヘッドの動きを比較した動画がこちら。
データとして45度形式にしか対応していないが、PicLaserから出力したデータから余分なデータと復路データを自動で削除してくれるWindows用ソフトを作成したので試してみたい方はご自由にどうぞ。毎回Grbl Controllerで$Xと$L1を打ち込むのも面倒なので、これらのコードも自動的にデータファイルに付加する様にしている。Visual Studio 2012のプロジェクト形式のソースも同梱している。特に再配布や二次利用等制限は付けないのでご利用はご自由に。ただし使用も自己責任にて。
起動後データファイルをドラッグ&ドロップし、trim reverseにチェックを付けOptimizeボタンを押下する事で最適化したデータファイルを生成する。
Reverse Adjustは復路の位置情報をずらす仕組みを入れてみたが、上手く行かなかったので放置している。
Inkscape出力も調整して改善して行きたい所だが、こちらは複雑なので来年の目標として取り組もうと考えている。
次回は様々な素材での利用を紹介する。
バックラッシですが、当方では太線イラストばかりを彫っていたため許容範囲でした。
未実装の同一モーターでもギヤ軸にグラつきがあります。ギヤボックス内の軸受けは薄く柔らかい素材で、プーリーをベルトで強く引っ張ると穴が拡がるため、X軸の右側同様に上下を固定したくなります。
ダイヤルゲージの固定具を用意しておらず、1mm幅の白抜きT字を左上から時計回りに一筆書きして目測調整してみました。数値は追い込んでいませんが、当方ではY座標は0.13、X座標は0.1を進行方向オフセット加算する事で見た目綺麗で手採寸で正しいT字が描けました。
原点でのバックラッシ方向を明確にした上でソフトでのGコード座標補正でも良い気がします。
そういえばベクタモードでは円弧補間のG02/G03があるので、GRBL側で補正の必要がありそうです。
ここ数日時間が無くてコード見れていませんが、0.8lasermodeのソースでも色々不足している様ですね。まだF値の初期化がどこなのか、R/Vの切り替えスイッチ実装をどうすれば良いのかが未調査です。もし参考になる様なサイトとかあれば教えて頂けると助かります。
Arduinoもステッピング/サーボモーターもここ一ヶ月で触り始めたばかりですが、色々と自作出来そうで面白そうです。アクリルやMDFをカット出来る機械が欲しくなります。
>Reverse Adjustは復路の位置情報をずらす仕組みを入れてみたが
先ず各軸共に+方向にバックラッシ補正値以上進んでから原点復帰を行うと、各軸の+方向にバックラッシ補正が必要な状態ができますよね。
前回より+方向:バックラッシ補正値
前回より-方向:0
移動しない軸:現状維持(バックラッシ補正値か0)
で適宜補正値を更新し、毎回各軸座標に補正値を加算すると正常動作するようです。
>まだF値の初期化がどこなのか
Grbl Controller起動直後のF値は安全面考慮等で意図的にF200などと入力する事でAlarm解除としている様ですね。
GRBL本体側では「feed_rate」で出てくる幾つかの代入箇所でやっていそうです。
>R/Vの切り替えスイッチ実装
Laser mode GRBLではR側は「OCR2A = g_laser_setting」で0-255の出力をしています。
Vのモードを追加する場合、せっかくの出力可変なのでモード+出力値指定で、スピンドルのON/OFFに合わせてOCR2Aへの出力を0か出力値に切り換えれば良い訳です。
>アクリルやMDFをカット出来る機械
まさにCNCの出番ですね。各素材や加工方法で回転数や深さやF値を変える必要があります。
慣れるまで千円overのエンドミルをポキポキ折るのが通例です!
素材や精度や加工速度が限定されますが、ダイソーで売っているミニルーター位の重量であれば、Micro Sliceをプチ改造して軽工作用CNCが出来るかも知れません。
ようやくGBRL 0.9gのソースでVectorモードが動くようになりました。軸が逆転したり治ったと思ったらGbrl Controllerの座標表示がマイナス方向だったりなかなか泥沼化していました(^-^;;
とりあえずVectorモードが動くようになったので、移動処理の所に反転時差分調整を入れてみて、なかなかいい感じになりました。下がオリジナルのGbrl 0.8、上が調整を入れた0.9gで焼いたものです。
http://nefastudio.net/soft/temp/gbrl_modified.jpg
私の場合逆回転時X軸0.2mm、Y軸0.4mm調整を入れる事で大体綺麗に出る様になりました。
Rasterモードがちゃんと動くようになったらソース含め公開する予定です。今は$L1した後Z10とかやると良く分からんエラーが出ます・・・。
おお、かなり良くなりましたね!
モーターと対の側を外側に引っ張る微加工が効いているせいか、上記数値では逆にズレていきました。
GRBL Controller は、諸々対応されている3.6.1-T4を利用しています。
念のためMinGW 64bit環境でコンパイルしてみましたが、32bit表記は消えたものの予想通りメモリ制約は解消しませんでした。
ソースとにらめっこして大分理解出来てきたので、RasterスイッチのままVector形式のデータを焼いたり$Z#コマンドでVector時のレーザー出力調整したり$50と$51にバックラッシのX/Y調整値を設定したりと言うところまで出来る様になりましたが、まだRasterモード時の出力ではまってます(^-^;;;
Arduinoはステップでデバッグしたり変数のWatchをしたり出来ないのが厳しいですね・・・。後一週間もあればちゃんと動くように出来ると思うのですが。
CNCも興味が出てきて http://carbide3d.com/ あたり使い勝手よさそうですが、価格が1/3くらいになってくれないと・・・。
とりあえずまだしばらくはGrblソースとにらめっこです。
>Arduinoはステップでデバッグしたり変数のWatchをしたり
IDEで慣れてしまうとそうなりますね。私は使用マシンが重くなるにつれ次第にテキストエディタのみでコーディングする様になりました。
GRBLは特に0.8系は少し手を加えればArduino IDEでもビルド自体は出来ますが、インストールフォルダ2箇所にパスを通してコマンドプロンプトでmakeし、デバッグはReport表示ですね。
>CNCも興味が出てきて
手作業で加工可能なMDFと台形ネジやその他金属部品の組み合わせでもCNCが作れます。
GRBLの動きが分かった所で、Z軸を有効にして1台組み立ててみてはどうでしょう。
一応Rasterも出力は出来る様になったのですが・・・なんか汚い。0.9gの移動処理変更が影響している気もするのですが。
http://nefastudio.net/soft/temp/gbrl9g_komasan.jpg
$L1時のみ0.8方式に切り替えれないか調査中・・・。
参考までに、現時点のソースです。
http://nefastudio.net/soft/temp/grbl-9g_mod.zip
とりあえず手を入れた箇所に//nefaのコメントを入れている程度です。
$50と$51でバックラッシ調整、$Z###でVector時のレーザー出力調整にしています。
コマンド体系が少し違うだけで、概ね同じような処理になったと思います。
隙間が空いているのはデータ通りなのでしょうね。
色の濃い箇所は減速でしょうか。
私の方は、端の折り返しが濃い縁取られるのを未調整な状態です。
メール頂けましたら、こちらで今までお試しで彫った画像等添付します(^-^)
ADAPTIVE_MULTI_AXIS_STEP_SMOOTHINGを無効にして$L1時はAccelerationを上げる事で綺麗に出る様になりました。
http://nefastudio.net/soft/temp/gbrl9g_mod_komasan.jpg
往復出力でズレも出ていません。
最終的なソース。
http://nefastudio.net/soft/temp/grbl-9g_mod_nefa20150115.7z
週末あたり元気があれば記事に纏める予定です。
ようやくこれで年末からかかりっぱなしだったレーザーいじり一区切りしてたまっていた他の作業にかかれます(^-^;
改修完了おめでとうございます!
当方では0.9gでの設定define記述各値を高め速めに設定したせいなのか、
前画像のような明確なムラは出なかったため、この項目は完全放置していました。
レーザーでは速度で太さや濃さが変わるため、等速に近づける事が非常に有効ですね。