Portabee GO が来てから使えるようになるまで

2014年4月22日、待ちに待った3Dプリンタ「Portabee GO」がやっときた。
さっそくプリントアウトするぞ!と思うも、うまくいかない。
いくつか問題にあたったので、そのトラブルシュートを順に書いていく。
なお、自分の場合はうまくいったということではあるが、同じことをやって大事な3Dプリンタが壊れたとしても当方では責任を負えないので、
自己責任でお願いします。あくまで、試行錯誤した事例ということでお願いします。

オートキャリブレーションがうまくいかない

まずプリントベッドの0点補正がうまくいかない。構造をよく見ていくと、XとYはエンドストップらしきタクトスイッチがあるのにZにはない。エンドストップがZにはない?
仮説として、おそらくベッドとノズルの導通をスイッチにしているのではないか?

また、Twitterで製造元に問い合わせたところ、Autocaribrationがうまくいってないようなので、提供しているテストデータ使えということ

  • テストデータのタコをダウンロードした。
  • 3点あるプリントベッドの円形に削ってあるところの、ヘッドが接していなかった部分のアルマイト加工のところを削って、導通する面積を増やした
  • ノズルの掃除をこまめにした。とくに、出力開始時に、念入りに金属部分が露出するように掃除する

結果:オートキャリブレーションがうまくいった

PronterfaceでConnectしてもつながらない

時々うまくいくが、大半うまくいかない。Curaならほぼ確実につながる。後述のCuraの問題があったので、PronterfaceGitHub - kliment/Printrun: Pronterface, Pronsole, and Printcore - Pure Python 3d printing host softwareとCuraGitHub - daid/Cura: 3D printer / slicing GUI built on top of the Uranium frameworkソースコードまで見てにらめっこしたが、結局、Curaの方がうまくいったのであきらめた。やるなら、シリアル通信の初期化部分の比較。

Curaでヘッドの温度があがらない、フィードしない

Curaだと、ヘッドの温度があがらない。StartのGコードと設定を調整することでうまくいった。つまり、ヘッドの温度あげるGコードコマンドを書いた。一回フィラメントを少しフィードするコマンドもコメントアウトした。
Gコードは、G-code - RepRapで確認した。

ラフトがはがれる

説明書には薄めたPVAをカプトンテープの上から塗れと書いてある。つまり「のり」を塗れということか!ということで、TOMBOのシワなしPiTGを使ったが、ばっちり。コツとしては毎回、ウェットティッシュでふいて塗りなおすのがよさげ。

テスト出力

  • タコの出力
  • 単純な立体を123DDesignで作成して、出力

Curaの設定

モデラーで作ったモデルで、内部に別のポリゴンがあった場合XOR的に中抜きされることがあった。CuraのExpertConfigでFix HorribleのCombine everythingにチェックを入れるとうまくいった。LayerViewで、ちゃんとできてるか確認したほうがいい。

BLAME!BLAME!BLAME!

Kindle版が目についたからという理由で、BLAME!を久しぶりに一気に読んだ。
いいね、BLAME!

それでふと考えた。もし、太陽のエネルギーのみでコンピューティングをするなら、
太陽系のコンピューティングポテンシャルはどれくらいだろう。

日本のスパコン「京」の計算能力/消費電力は、
8.162PFLOPS/12.65MW

太陽から降り注ぐエネルギーは、地球軌道上では1KW/1㎡

地球軌道は太陽から1億五千万キロ=1.5×10の8乗(はてブには上付がないのか・・・)

まず表面積の計算
地球軌道で球体を作るとすると・・・完全にダイソン・スフィアです・・・
4・π・1.5・10の8乗≒ざっくり概算で10倍になるので1.5・10の9乗平方km

一平方メートルに単位変換すると、10の6乗かけられるので、
1.5・10の15乗㎡

そんなもんか、せいぜい1.5P㎡・・・コンピュータやってる人間ってどんどん数字の大きさの感覚が人間離れしてくよね、天文屋ほどじゃないと思うけど

で、1KW/1㎡なので、地球軌道の大きさのダイソン・スフィア一面に太陽エネルギーを取り込むシステムを作れば、
1.5・10の15乗KW

ほほう、とりあえず効率は無視

そうすると、
1.5・10の15乗KW ・ 8.162PFLOPS / 12.65MW ≒(やっぱり超概算で)1.0・10の27乗FLOPS

10の24乗がYottaなので、1000YFLOPSくらい

もちろん、ネットワークとか、ストレージとか、アムダールの法則とか、色々な問題があるし、
ぶっちゃけ太陽系レベルの大きさのコンピュータって信号遅延とかどうなるんやねんという突っ込みもあるし、
そもそも今のパラダイムでそんな大きなコンピュータ作ってもきっと役に立たない
とはいえ、太陽のエネルギーだけでコンピューティングしようとするとそんな感じになるようだ。

さぁ、何を計算しよう・・・・

gitでディレクトリツリーの比較・一貫性チェック

久しぶりの記事。

gitでディレクトリツリー同士の一貫性チェックをしてみます。
2つのディレクトリツリーが同じものかどうかを調べます。

よく使われるのは、diffとか、findとmd5を使ったりするやり方だと思います。
が、今回使ってみたのはgit。

やってみたことは、

git init
git add .
git write-tree

これだけ。
これで、そのディレクトリツリーを表すハッシュ値が手に入る。
あとは、これを比較するだけ。
比較とか一貫性チェックって言ってるけど、単純に違うか同じかを確認するだけです。
あと、.gitがあるところではやらないほうがいいと思います。
全ファイルをステージングすることになるので、あとから面倒かと。
比較した後は、

rm -rf .git

とかで、gitのディレクトリを消しといたほうがいいと思います。

見慣れないgit write-treeコマンドについては、
Git - Gitオブジェクト
あたりを参考にしました。

メリットは、速い、確実、簡単、というところでしょうか。
もともと、異なるサーバーのディレクトリツリーを比較したいという用途だったので、
ハッシュ値の比較だけでできるのは便利です。

gitのバージョン管理じゃない使い方でした。

PS:なんか間違ってる気もするので、もうちょっと検証してみます。

新VAIO Z (VPCZ21AJ) で、ImaginationTechnologiesのPowerVR用OpenGLES SDKをむりやり動かす方法

すごくニッチな話題だけど、書いておく。

VAIO Zでは、グラフィックスがCPU内蔵IntelHD3000と外付けのAMD Radeonとのハイブリッドになっている。
そして、SONYカスタムのグラフィックドライバが入ってるっぽい。

ImaginationTechnologiesのPowerVR SDKで、ソフトウェア開発をしたかったのだけど、
そのままだと、サンプルでついてきたデモプログラムがエラーで動かない。

PVR : VFrame attempted to use one of these functions:
PVR: wglChoosePixelFormatARB
PVR : But these are not available on your machine
Ignore?

こんなエラーメッセージをダイアログに吐いて終了する。

で、グラフィックドライバのせいかと思って、なんとかIntel純正の最新版ドライバを入れてみた。


ちなみに、普通にドライバーをインストーラでインストールしようとすると、

ご使用のコンピューターにはコンピューターの製造元がカスタマイズしたドライバーがインストールされています。インテル・ドライバー・アップデート・ユーティリティーは、このドライバーをアップデートできません。製造元がカスタマイズしたドライバーの代わりにインテルの汎用ドライバーをインストールすると、技術的な問題が発生する可能性があります。コンピューターの製造元に問い合わせて、お使いのコンピューターの最新ドライバーを入手してください。

こんなメッセージが出てきてインストール出来ない。


そこで、ZIP圧縮形式のIntelドライバーをIntelから落としてきて、インストールした。

方法

まずは、IntelからZIP圧縮形式のHD3000のドライバーをダウンロードして解凍。

おもむろに、デバイスマネージャーからディスプレイアダプタを選び、プロパティ→ドライバー→削除

セーフモードで再起動
(通常起動すると、SONYドライバーがインストールされる)

バイスマネージャーのディスプレイアダプタプロパティから、ドライバーの更新で、
解凍したフォルダのGraphicsフォルダを選択して、OKボタン

これで、Intel純正HD3000ドライバが入ったので、通常モードでWindows再起動

SDKのサンプルが動いたー!!

もちろん、メーカーが保証しない使い方なので、自己責任でお願いします。