コメを噛め

コメを噛め

rerofumi の電子工作メモ

Archive for the ‘programming’ Category


hatena bookmark


ようやくCNCフライスでプリント基板を作ることができた。

プリント基板を CAD で設計したり、その結果であるガーバーデータを P板.com 等の基板試作屋さんに出して製作をしたことのある人なら理解していると思うんだけれども、プリント基板を作るにはいくつものレイヤーを扱う。
そのレイヤー毎のガーバーデータを製造会社に渡してようやく1枚のプリント基板ができあがる。

今回 CNCフライスで作るのは片面一層なので必要なレイヤーは以下の3つとなる。

  • プリント基板外形
  • ソルダー面パターン
  • ドリル穴データ

基板試作屋さんに出しているときはコレに加えて、ソルダーマスクのデータ、シルク面のデータとか、二層のときは部品面パターンのデータとかが増えるわけだ。
ドリル穴データはガーバーでも GCODE でもないんだけれども、まあその辺は置いておいて、これら 3つのガーバーデータをそれぞれ 3つの GCODE にコンバートして CNCフライスでその GCODE を都合三回処理する。

ガーバーから GCODE へ変換するコンバーターは cam.py を始めいくつかあるんだけれども、パターンのパスを作るだけの物が多かった。しかも、出力の空間座標が元のガーバーのそれとは異なっているので外形やドリルが合わせられなくて困るのである。
cam.py はドリルとパターンを一緒に処理してくれる機能があるけれども、ドリルのデータ形式が不明でうまく読み込めなかった。ガーバーも EAGLE のを期待していて K2CAD の奴は読めなかったりと色々不満が残る。(GCODEのパラメーター省略に対応していないのが多い)
結局外形とパターンを合わせられるツールがなかったので、ソフトを自作することにした次第。EAGLE 使っていれば全部解決していた気もするけれども、まあそこはそれ。


先ほど書いた様に 3つのレイヤーをへて 1枚の基板を作るのでフライスのツールも 3種類用いる。左から、ドリル、パターン彫刻の半月カッター、外形を切り出す1mmエンドミル。
XYテーブルはひとつのゼロ座標で固定しながら、ツールを手作業で取り替えてそれぞれの対応 GCODE で切り出していく。
パターン彫刻カッターはキデッジショップさんから購入した物。ドリルやエンドミルはIHCモノタロウとかで適当に。

そんな感じの作業をへてついにプリント基板が完成。
丸い形状とか CNC じゃなきゃやってられんよ。

テスターでショートチェックをしていると、クズが溝に残ってショートしてたりすることはある。あとバリがあってショートとか。色々試したけれども、細かいのはクリームクレンザーとスポンジで磨くのが効果的だった。指紋とか酸化膜とかも落ちるしね。
それでもショートしている場合(バリの場合が多い)、カッターで切るしかないけれども。

さて、そんなこんなで作っていた CNCフライス用の GCODE コンバーターというか、パターン外周抽出ツールだけれども、これが遅い。5cm程度の基板パターンで 5時間ぐらいかかる。
それは流石にどうだろうということでちょこっと高速化したら、8分にまで縮まった。まあ、これくらいなら。
今のところ書き捨てのクラスとテストスクリプトがあるだけで公開できるようなものではないのだけれども、どうしよう。気が向いたらもうちょっとまとめてソース置いておこうか。


hatena bookmark


ちょいと前のお話になるけれども、小型のCNCフライスキットを購入したのです。


これでアクリル板にキャラ絵を彫って遊ぶとか、フィギュアのパーツを削り出すとか、そういったことも楽しいのだけれども一番の目的はプリント基板の作成。
銅箔版をフライスでけがいてプリント基板を作成するという奴ですな。

プリント基板はポジ感光基板とエッチングで自作できるものの、廃液処理が面倒だとか、感光作業が面倒なわりに綺麗にできないとか、ランニングコストがかかるだとか、これらを乗り越えるために職人技がいるだとかでじわじわとおっくうになってきたのです。それに基板カットが面倒だとか、穴開けが手作業で死ねる上に綺麗にできないとか。
それらを CNCフライスでより簡便にできるんじゃないかと夢ふくらみ始めたわけですよ。

まあ、ここまでちまちまとパターン絵を描くプログラムを作っているあたりを見て気がついていた人もいるかもしれないけれども。


基板パターン周辺を刃サイズ分外側を拾いながらパスを取ることが、前回のコードまででできていたので、後はCNCフライスにかけられるよう GCODE を出力すればよいだけの話。
そのあたりを書いてようやくカットできるようになったものがこちら。

ちなみに CAD に EAGLE を使っている場合は、EAGLE から直接 GCODE をはき出すスクリプトがいくつも公開されているのでそれを使うのが吉。
私は K2CAD を使っているので、そこから garber 経由でフライスに持ってくるのがうまくいかず変換ソフトウェアを自作し始めたってだけなのです。おかげでわりかし自在に扱えるようになった、と思う。


hatena bookmark


前回あった、重なっているはずなのに線が残ってしまう問題が解決した。
トレードオフとしてかなり処理が遅くなってしまったけれども、時間がかかっても確実にできることを目標に今のところはあきらめていく方向で。
ようやく、ここまでできた。

これでまた前に進める。


綺麗綺麗。

source:
g2g-20101113a.zip


hatena bookmark


ざっくりとガーバーファイルの読み込みを作って、ずいぶんとそれらしい表示ができるようになってきた。
単純にガーバーを読んで表示するだけならさほどでもないけど、外周合成に時間がかかって300オブジェクトで20分とか。rubyインタプリタでやっているとか、計算が適当で無駄が多いとかあるんだけれども、自分用の使い捨てコンバーターだからそれでも別に良いかという感じ。


フィルの部分とか内部に外周奇跡が残ってしまっている。
cam.py でも同じ目にあって自作する最大の動機(理由は他にもある)だったのだけれども、自分でも同じ轍を踏んでしまうとは。
他にもゴミが残っているし、この部分がクリアできるまで成果物とは言えないよなあ。

一応ソースコードのSNAPSHOT
Download: g2g-20101107a.zip


hatena bookmark


ちと脇道にそれたり、やり方を変えていたりして間が空いた。
前回まで「三角形を合成して細かい三角形の塊で持つ」というのをやっていたのだけれども、やっぱりどっかでうまくいってなくて完全な結果が得られなかった。
なのである程度の塊(ライン単位)にしておいて、目的であるアウトラインだけをがんばって合成するという手順にしてなんとか進行。これまでの作業も有効利用できているし無難な落としどころなんじゃないかな。


hatena bookmark

tri_03-1
一応の連載になっていたので、その後の報告をば。

地道に状況デバッグを重ねていって三角形を小さな三角形で表現しながら合成していくという目標はなんとか達成することができた感じ。
2枚はOKでも3枚で破綻する、なんてのもあったけれども今は問題なく処理できている。ただ、たまーにアウトラインモードで内部にゴミラインが出る事があって、何らかで線が重なった瞬間じゃないかと考えている。でも出る頻度が低いのと、ここまで来れば前に進めるのとで、とりあえず置いておこうかと。

tri_03_2
こんな風に穴あきになるような重なりでもちゃんとアウトラインがとれているよ。

Source code: ironruby_gl_fw_03.zip


hatena bookmark

うまくいかなくて悩んでいるけれども途中で掲載。

otk_base_ss02
前回の「IronRuby で OpenGL」の続き。といっても、表示して確認しながら作りたかったプログラムの方。
何かというと2つの三角形が重なっているとき、それを合成した図形を計算したいというもの。シンプルながらやってみるとなかなかに難しくて。久々にベクターや外積などと取っ組み合い。

なんでもいいから合成後の形状が得られれば良いというわけでなく、2つの要求が存在している。

1) 合成後は細かい三角形の集合として得られること
2) 分割後の三角形は接するもの同士頂点を共有し同じ辺の長さであること

1) はとりあえずこれを満たせば後は繰り返しでどんな形でも作業することが可能になるので。

otk_base_ss03
2) が地味にやっかいなのだけれども、これは最終的に欲しいのが合成した形状の外周だから。
三角形の集合にしておけば、線分に分割して見たとき「共有されていない辺が外周」であると後で抽出できるため。

otk_base_ss04
ここ一週間ぐらい取り組んでいて大分形になってきたけれども、まだまだ不完全。
三角形二つがくるくると回りながら移動し交わったら合成処理を施すようなデモを作って確認しているところ。くるくる回りながらということで、任意の状態を幾重にも作りだすことと等価。全ての場面でうまくいくことを見たいのだけれども、まだうまいこといかないパターンがあって割としょっちゅう破綻している。
ある程度のテストパターンは作って作成していったのだけれども、その範囲内でうまくいっても任意形状ではダメというのはありがちなれど辛いのう。

今の段階でのソースコード。くるくる回るデモを含んでいるので IronRuby で OpenGL のテストコードその2 としてもどうぞ。

Download: ironruby_gl_fw_02.zip (11kb)

その道の偉い人からみたらもっとスマートな手順があるんだろうなあ。
というか、力業なコードになりつつあるのが切ない。


hatena bookmark

otk_base_ss1
ちと ruby で計算した結果をグラフィカルに確認したくなったので、.NET の OpenGL バインドである OpenTKIronRuby からまともに使ってみることにした。
ライブラリを使うだけなのでさくっと画面が表示成功。あとは OpenGL ベースで好き勝手できるようになったところで成果をお裾分け。

IronRuby を用意するという特殊性はあるものの、上の画面の様な三角形が簡単に表示できるのです。今実験しているのが平面の図形計算だからテストは平面な三角形だけれども、3DCG で表示されていて、マウスドラッグでくるくる回せる様になっている。

Download: ironruby_gl_fw_01.zip (5kb)

IronRuby と OpenTK は .NET 環境で動くので、MONO を使って MacOSX 上で動作させることも可能。
otk_macosx_shot
Linux は試していない。

IronRuby上で OpenTK を使う手順として codepad に置いてあった「OpenTKのサンプルをIronRubyに移植してみた」を参考にさせてもらった。ここに情報がないので作者が不明なのだけれども、あれくまさんが作ったということでいいのかな?
あと OpenTK のサンプル(C#)とドキュメントを見てた。
IronRuby + OpenTK というか OpenTK 自体情報が少ないのでこんなソースでも何かの役に立つんじゃないかと思う。

ここ最近、なにかアプリケーションが作りたいとき何で構築するのが最善かなあと考えていた。マルチプラットフォームでOpenGLも使えてというと Java が一番近いのだけれども、Linux も考えると簡単かなあと疑問に思ったり、そもそもで Java はなんか最近離れてしまったのでやりたくなかったり。
できれば ruby で楽しく作ってお気軽にマルチプラットフォームできると良いのだけれども、ruby は GUI フレームワークが弱すぎるという難点が。
色々考えているうちに MONO がかなり良くなってきているので、.NET framework で作ればマルチプラットフォーム化が容易だというあたりに落ち着いてきた。Windows forms で作っておけばたくさんの環境でだいたい動作させる事ができる。
調べてみるとシリアルポートも含まれているので、環境毎にドライバーを用意しなくても同一コードでシリアルにアクセスもできる。マイコン工作系にとってかなり心強いところ。
.NET framework で OpenGL を扱えるバインディングには OpenTK が登場してなかなか評判も良い。
でそんな GUI 周りをそのまま利用できる ruby 環境として IronRuby があるわけだ。(Python派には IronPython)
試してみたら MONO で IronRuby を使うのもそんなに難しくなかった。特にこだわりがあるので無い限り、スタンダードな ruby そのままな形でプログラミングできるし GUI も作成することが可能だ。

そんなこんなで個人的な好みにマッチングしている IronRuby + OpenTK で、ちょこっとしたアプリを作成できるのではないかという結論に至ったのである。
今回のソースはその第一歩。