ここ何回かRastering With a Laserに沿ってLinuxCNCによるラスター加工について書いてきました。今回のGrastarをインストールする事で任意の画像データを変換しレーザー加工機で出力するまでの流れが完結します
Grasterの動作
Grasterは画像データをLinuxCNCに喰わせる形に変換するプログラムで、Rubyで書かれています。 例えばKumamon.pngという画像ファイルをGrasterで処理すると、次の3つのファイルが生成されます。
- Kumamon.png.raster.ngc ラスター描画時にレーザーヘッドの移動を制御するNCコードです。
- Kumamon.png.raster.gmask ラスター描画時にレーザーのON/OFFを制御するデータです。上記NCコード実行時に読み込まれます。
- Kumamon.png.cut.ngc 外形カット用NCコードです。
まずはRuby関係のツールをインストール
Grasterを動作させる為、まずはRubyとその関連ファイルをインストールします。ほいほい堂のUbuntu上ではapt-getにより以下のツールをインストールしました。
sudo apt-get install ruby
sudo apt-get install imagemagick
sudo apt-get install librmagick-ruby1.8
sudo apt-get install rubygems1.8
前回の投稿でダウンロードしたGrasterファイル
Graster自体は前回の投稿に書いた通り、下記コマンドで入手します。 ※前回の投稿は当初リンク切れのアドレスを載せていたので後日修正しています。
https://github.com/jedediah/graster/archive/master.zip
Grasterの動作確認と修正
ダウンロードしたGrasterを解凍するとgraster-masterディレクトリ下にbin/grasterというファイルがあります。これが実行すべきコマンドファイルですが、私の環境では次のエラー出ました。
$ ./bin/graster
/usr/bin/env: ruby -rubygems: そのようなファイルやディレクトリはありません
どうやらbin/grasterファイルの先頭行「#!/usr/bin/env ruby -rubygems」で引っかかっている様です。 /usr/bin/envでrubyへのパスを指定した場合、引数があると環境によってはエラーになるそうです。そこで次の様にrubyへのパスを直接指定してエラー回避しました。
$ diff graster.ORG graster
1c1
< #!/usr/bin/env ruby -rubygems
---
> #!/usr/bin/ruby -rubygems
これでとりあえずはエラー無く変換ができる様になったのですが、実際に加工機で描画してみると正しい場所でレーザーが出力されません。またレーザーヘッドの動作範囲が妙に狭い様です。 原因は次の通りと思われます。
- Grasterはインチ単位の動作を前提に書かれている。 私の加工機はLinuxCNCの設定で、ミリ単位を基本にしています。本来インチで書かれたNCコードをミリと解釈しているためレーザーヘッドの動作範囲が狭くなっています。 また、xxx.raster.gmaskファイルにはX軸が所定の箇所に達したら次の動作(レーザーをON/OFFしたり)に移るという動作が書かれていますが、これもインチで書かれています。 これに対し加工機がhalに知らせるX軸のポジションがミリなので、ここも上手く行きません。
- xxx.raster.gmask中の記述が往復描画と片道描画が混乱している。 ラスタースキャンではレーザーヘッドが往復する際に右向きと左向き両方で描画する方法と、片方向のみ描画する方法があります。速度と精度のトレードオフなのですが、生成されたgmaskはこの両方の方式が混ざって記載されている様で正しく制御できていませんでした。
以上２点の対策として次の方針で変更しました。
- 単位はミリで出力する。 あまりややこしく考えず、座標を出力するデータ全てに25.4を掛けるという方法で修正しました。 よって出力はミリ単位になっていますがオプション入力での数値はインチのままです。
- 片方向描画に統一したgmaskファイルを生成する。 とにかく片方向描画が正しく出来るファイルを生成する様に変更します。
これらを変更したところ、それっぽく動作する様になったのですが、描画の最後の方だけレーザーが出ないという問題が発生しました。 動作の最後の方になるとなぜかstreamerからデータが出てこなくなります(LinuxCNCのバグではないかと思っています)。結局原因は判っていないのですが、streamerのバッファにデータがたっぷりあればこの現象が発生しない様なので、gmaskファイル生成時にデータを余分に出す事で逃げています(全フィールド0の行を400行ほど余分に出力しています)。 本来LinuxCNCの最新バージョンでどうなるかを試すべきですが・・・いずれやってみます。
Graster修正結果
最終的に変更したのは次の内容です(それと上に掲載したbin/grasterもです）。
$ diff lib/graster.rb.ORG lib/graster.rb
177c177,178
< @image.size[1].times {|y| @tiled_rows << tiled_row_spans(y, (forward = !forward)) }
---
> #@image.size[1].times {|y| @tiled_rows << tiled_row_spans(y, (forward = !forward)) }
> @image.size[1].times {|y| @tiled_rows << tiled_row_spans(y, (forward)) }
219a221
> gmask.epilogue
$ diff lib/graster/gmask_file.rb.ORG lib/graster/gmask_file.rb
13,15c13,15
< self << "0 0 0 %0.3f\n" % x1 if @begin_row
< self << "0 0 1 %0.3f\n" % x1
< self << "0 1 1 %0.3f\n" % x2
---
> self << "0 0 0 %0.3f\n" % (x1*25.4) if @begin_row
> self << "0 0 1 %0.3f\n" % (x1*25.4)
> self << "0 1 1 %0.3f\n" % (x2*25.4)
17,19c17,19
< self << "0 0 1 %0.3f\n" % x1 if @begin_row
< self << "0 0 0 %0.3f\n" % x1
< self << "0 1 0 %0.3f\n" % x2
---
> self << "0 0 1 %0.3f\n" % (x1*25.4) if @begin_row
> self << "0 0 0 %0.3f\n" % (x1*25.4)
> self << "0 1 0 %0.3f\n" % (x2*25.4)
22a23,29
>
> def epilogue
> (0..400).each do |x|
> self << "0 0 0 0\n"
> end
> end
>
$ diff lib/graster/gcode_file.rb.ORG lib/graster/gcode_file.rb
35c35
< "#{k.to_s.upcase}%0.3f" % v
---
> "#{k.to_s.upcase}%0.3f" % (v*25.4)
修正版一式
修正版一式をアップしておきます。
使用方法
次の様に使用します。 各種パラメーターはカレントディレクトリのgraster.ymlに書いておくとデフォルトとして使用されます。下の例では画像のドットを300dpiとして描画する様に指定しています。実行後、上に書いた３本のファイルが出来ています。
%graster –dpi 300,300 Kumamon.png
変換後のファイルもアップしておきます。
