備考：ABS のプリントはヒートベッドがあっても難しい

とにかく反り対策が難しい。

特に冬は絶対やめたほうがいい。膨張率が高いおかげで反りが激しいので、設計時にすら気を使う必要がある。当然スライサでプリント方向も気をつけないといけない。

ある程度大きなパーツを作るのはとても難しい。小さなパーツでもベッドとの接着が甘いと剥れてくるし、層を重ねると反ってくる。設計通りに寸法を出すのは、設計段階から気をつけるレベルでないとかなり難しい。つまり構造的に反りにくいようなリブをつけたりする必要がでてくる。

ヒートベッドは万能ではなくて、下層の反りを軽減してベッドから剥離することは防止することはできても、高さがある造形物が途中から反っていくのにはあまり効果がない。これを抑えるには室温を上げる必要があるが、実際はなかなか難しい。冬でも箱があれば30℃程度まで室温を上げられるが、この程度では反り対策にはあまり効果を感じない。

そもそもヒートベッドを100℃前後まで過熱するのは80℃前後まで過熱するよりも、余計にかなり時間がかかる。プリント開始されずもどかしい。ここで時間がかかるとそもそも試行錯誤しにくいということも罠のひとつ。

備考：PLA はプリント後に微調整がしにくい

PLA はとても硬いのでやすりで微調整したり、ニッパーで強引にパーツの一部を切り取るとかがやりにくい。試行錯誤しようと思うとプリントしなおす前にプリント部品を修正してモデルに反映させてとやりたくなるけど、やりにくい。諦めてプリントしなおしたほうが精神的に楽に思えるぐらい。そうすると時間的にもフィラメント的にもコスト増である。

また耐候性がないので屋外で使えず、耐熱性が低いので高温になる場所 (高温といっても60℃ぐらい) では使えないので、用途が限られる。「プリントしやすい」以外は利点があまりないと感じる。けど肝心のプリントしやすさも、ノズルの詰まりやすさでスポイルされる部分がある (フィラメントに少量油を塗るオイラーが必要)。

10.8V スライド式バッテリーを汎用的に使う

当然メーカー推奨の方法ではないが、バッテリー端子を直接引き出しで独自に使う。

バッテリーに合致する端子を作って、任意の汎用コネクタに変えることを考える。とりあえずは手元の無線機 (KX3) 用に DC φ 2.5mm センタープラスコネクタとして引き出す。

導体を扱うので 3Dプリンタだけではどうにもならない。接点として、今回はt=1mmの SUS430 の板を使うことにしてみた。SUS430 はステンレスの中でフェライト系というもので、比較的加工性が良いらしい。けど真鍮とかのほうがもっと加工性良さそうだし導体抵抗的にもいいかもしれない。

SUS430 板は CNC ミリングで加工した。あまり複雑な形にせず、最悪手で加工しても作れるような形とした。

端子を保持してスライドしてバッテリーと接続する部分は3Dプリンタで作成した。何度か出力しなおしてうまくマッチするようにした。

パーツは2つに分かれていて、ショート防止のため金属の露出部分を減らしてある。

Thingverse に STL をあげた。https://www.thingiverse.com/thing:2841303

電圧

リチウムイオンバッテリー直結だと思うので、素子素性そのままだと思うが念のため。

リチウムイオンバッテリーは1セルあたり3.6V。10.8V は3本直列ということになる。

公称3.6Vで、満充電4.2V、放電ぎりぎりでは2.75V 付近まで下がる。3本直列なら 8.25V〜12.6V。実用的には下限を9Vぐらいにしたほうが安心。

• 充電直後 12.43V (セルあたり4.14V)
• 放電後 (マキタの掃除機でLEDが点滅するまで) 10.3V (セルあたり3.43V)

放電直前の電圧はそのうち追試

どれぐらい電流がとれるか

無線機に直結できるように配線してみたので、KX3 で実際に送信してみたところ、充電直後で 2A 程度は全く問題なくとれるようだった。

過電流保護がどこでかかるのか興味が湧いたので、電子負荷でさらに負荷をかけてみることとした。4.3Aまで出ることがわかった。

何が変わるか

MK2S -> MK2.5 で以下がアップグレードされる。

• フィラメントセンサー
• エクストルーダーまわりが大幅に変わった
  • フィラメントの引き込みがより滑らなくなった
  • ホットエンドファン径が大きくなり静音のファンに
• ヒートベッドが2重構造に
  • ベース+鉄のプレートで、磁石でくっつくシートが付くようになった
  • 特に大きな造型物を取り外しが楽に

MK2S でも割と十分なので、そんなにものすごく魅力的というほどではないが、フィラメントセンサーは便利で良さそう。

なお MK3 は MK2S から上記以外にも大幅に変わっていてもっと良さそうなんだけど、あいくにもう一台買うような余裕はない。

手順

Prusa Knowledge Base に従ってやった。

キット内に PETG のフィラメントが入っていて、オマケかな？と思ったら、Gcode は用意してあるので、必要な 3D プリントパーツをまず今のでプリントしてください、という感じだった。そういえば確かに、既に動くプリンタがあるなら部品供給じゃなくて材料供給のほうが効率良いが、予想外だったのでちょっとびっくりした。

X軸はE軸と結合するパーツが全置き換え。E軸は完全に置き換え。地味に大変。

PINDA プローブやキャリブレーションがやりなおしなのも地味に大変だが、勘所は覚えてたので割とすぐ終わったっぽい。まだあまりプリントしてないのでこれからかな。

ファームが新しくなってウィザード形式で初回テストを行ったけど、ちょっとつまづくところがあった。

• ファンが回ってるのに Selftest failed で終わる
  • Selftest 開始直後にキー入力してしまうと、プリントファンがまわったあとの「プリントファンがまわってますか？(意訳)」というデフォルトで「いいえ」が選択されている質問を一瞬で飛ばして Selftest failed になる
  • 余計なキー入力をしなければ問題なかった
• Motor - X, Endstop Z エラー
  • X軸とZ軸のエンドストップが入れ替わっているという旨のエラー
  • Z軸のエンドストップって何かというとPINDAプローブだが、X軸を動かしている最中にPINDA プローブが反応する位置にきてしまうと、配線が正しくてもこのエラーが出てしまう
  • Y軸をちょっと動かしてやれば解決
• First Layer Calibration
  • PLA でやることになっているが、手元に PLA がなくて焦った
  • 余った (巻かれてない) PLAを発見したので手差しで供給して行った
• プリントファンのファンノズルが割れた
  • この部品はABSでプリントされたものが付属するが、ネジ止めするところを割ってしまった。
  • プリントレイヤー間で割れたので接着剤でつけた。ここはネジを締めること自体にトルクが必要なので、いまいちどこまでやれば止まっているのかわかりにくい

コード

ロータリーエンコーダを処理するコードがあるのでちょっと長く見えるが main は短い。mbed の USBMIDI ライブラリのおかげ。

LPC11U35 で動かすことを前提として、ロータリーエンコーダのA相・B相を、それぞれ P0_11, P0_12 に繋ぐコードになっている。時計周りのときB相が先行するコードなので、逆のロータリーエンコーダの場合は逆にする。(ロータリーエンコーダの位相方向って決まってないっぽい？)

ロータリーエンコーダのチャタリング対策も入れてる。ググってみるとあんまりやってるコードを見ないけど必要ないのかな？

#include "mbed.h"
#include "config.h"
#include "USBMIDI.h"

class QEI {
	static const int8_t INVALID = 2;
	static uint8_t decode(const uint8_t prev, const uint8_t curr) {
		/**
		 * 4bit decode table
		 *       bit3      bit2      bit1     bit0
		 * [ prev A ][ prev B ][ curr A ][ curr B]
		 *
		 */
		switch ( (prev << 2) | curr) {
			case 0b0000: return  0;
			case 0b0001: return  1;
			case 0b0010: return -1;
			case 0b0011: return  INVALID;
			case 0b0100: return -1;
			case 0b0101: return  0;
			case 0b0110: return  INVALID;
			case 0b0111: return  1;
			case 0b1000: return  1;
			case 0b1001: return  INVALID;
			case 0b1010: return  0;
			case 0b1011: return -1;
			case 0b1100: return  INVALID;
			case 0b1101: return -1;
			case 0b1110: return  1;
			case 0b1111: return  0;
		}
		return INVALID;
	}

	volatile uint8_t prev;
	Timeout timeout;

	void interruptSample() {
		uint8_t ok = sample();
		if (!ok) error = 1;
	}
	
	void interruptDelay() {
		// avoid chattering
		timeout.attach(callback(this, &QEI::interruptSample), delay);
	}
public:
	volatile int position;
	volatile uint8_t error;
	InterruptIn phaseA;
	InterruptIn phaseB;
	float delay;

	QEI(PinName _a, PinName _b, float _delay = 0.005) :
		prev(0),
		position(0),
		error(0),
		phaseA(_a),
		phaseB(_b),
		delay(_delay)
	{
		phaseA.mode(PullUp);
		phaseB.mode(PullUp);
	}

	void enableInterrupt() {
		phaseA.rise(callback(this, &QEI::interruptDelay));
		phaseA.fall(callback(this, &QEI::interruptDelay));
		phaseB.rise(callback(this, &QEI::interruptDelay));
		phaseB.fall(callback(this, &QEI::interruptDelay));
	}

	/**
	 * sample digital input and return ok
	 */
	uint8_t sample() {
		uint8_t curr = phaseA.read() << 1 | phaseB.read();
		int8_t incr = decode(prev, curr);
		prev = curr;

		if (incr == INVALID) {
			return 0;
		}

		position += incr;

		return 1;
	}
};

void show_message(MIDIMessage msg) {
	switch (msg.type()) {
		case MIDIMessage::NoteOnType:
			printf("NoteOn key:%d, velocity: %d, channel: %d\r\n", msg.key(), msg.velocity(), msg.channel());
			break;
		case MIDIMessage::NoteOffType:
			printf("NoteOff key:%d, velocity: %d, channel: %d\r\n", msg.key(), msg.velocity(), msg.channel());
			break;
		case MIDIMessage::ControlChangeType:
			printf("ControlChange controller: %d, data: %d\r\n", msg.controller(), msg.value());
			break;
		case MIDIMessage::PitchWheelType:
			printf("PitchWheel channel: %d, pitch: %d\r\n", msg.channel(), msg.pitch());
			break;
		default:
			printf("Another message\r\n");
	}
}


USBMIDI midi;
QEI encoder1(P0_11, P0_12);

int main() {
	printf("init\r\n");
	encoder1.enableInterrupt();

	midi.attach(show_message);
	while (1) {
		if (encoder1.position) {
			int8_t val = encoder1.position;
			printf("send CC 1 %d 0\r\n", val);
			midi.write(MIDIMessage::ControlChange(1, val, 0));
			encoder1.position = 0;
		}
	}
}

MIDI2LR の設定

MIDI2LR の設定画面を開いた状態でロータリーエンコーダを動かすと、以下のように表示されるので、ここでは Exposure (露出) に割り当てている。

さらにこのボタンの部分を右クリックして、Adject CC dialog を出し、CC Message Type を Two's complement に設定する。

備考

これですんなり動く。ロータリーエンコーダのA相・B相の仕様を確認しないと回転方向が逆になったりするのだけ注意が必要 (ソフトウェア側でなんとでもなるけど)

この調子でエンコーダーを増やしていけば実装上は良いことになる。しかしロータリーエンコーダ1つあたり2ピンのIOを使うので、実際は GPIO 拡張が必要になる気がする。

mbed official の USBDevice

mbed official に存在するライブラリの USBDevice の中に USBKeyboard というのがある。USBHID を継承していて、レポートデスクリプタとかを予め設定してくれる便利クラスとなっている。これは LPC11U35 でもちゃんと動くので基本的にハマるようなところはない。

標準で便利なメソッドがいくつか定義されているが、実際にキーボードを作る場合はこれらは使わない。USBKeyboard に定義されているメソッドはデモ用と考えていいと思う。

普通に使う場合は、レポートデスクリプタ定義はそのまま使いつつ (特に変更する必要がないので)、USBHID#send() を直接呼んで HID_REPORT を自分で構成して送ることになる。

基本的なコード

#include "mbed.h"
#include "USBKeyboard.h"

#include "mcp23017.h"

#define REPORT_ID_KEYBOARD 1
#define REPORT_ID_VOLUME   3

USBKeyboard keyboard;
DigitalOut led(LED1);
DigitalIn key1(P0_4, PullUp);

int main() {
    HID_REPORT report;
    
    uint8_t modifier = 0;
    uint8_t usage = 0;

    report.data[0] = REPORT_ID_KEYBOARD;
    report.data[1] = modifier;
    report.data[2] = 0;
    report.data[3] = usage;
    report.data[4] = 0;
    report.data[5] = 0;
    report.data[6] = 0;
    report.data[7] = 0;
    report.data[8] = 0;
    report.length = 9;
   
    
    while(1) {
        bool isKey1Pressed = key1.read() == 0;
        if (isKey1Pressed) {
            if (report.data[3] != 0x04) {
                report.data[3] = 0x04 /* a */  ;
                keyboard.send(&report);
            }
        } else {
            if (report.data[3] != 0x00) {
                report.data[3] = 0x00;
                keyboard.send(&report);
            }
        }
        wait_ms(10);
    }
}

基本的にはこういう形です。USBKeyboard のメソッドではキーの「押しっぱなし」ができない実装なので、ちゃんとしたキーボードにするにはレポートを自分で管理する必要があります。実用的にはリポート内のキーの状態を管理するクラスが必要になるでしょう。

といっても、USBKeyboard をほとんど使わないようなら直接 USBHID を継承して MyUSBKeyboard を作ったほうがいい気がするので (レポート定義もいじれるようになるし)、実際はそうしています。

ハマりポイント

接続

キーボード左右+USBコントローラという構成になった。USBコントローラとキーボードの左右はLANケーブルで接続する。BLE 版だとコントローラー基板はキーボードの左に付属していて、左右のキーボード同士をLANケーブルで接続していたが、実際はこのように配線を変えても動くような構成にしていたので、回路自体はすんなり変更できた。

電池がなくなったり、コントローラ基板を別にしたことで、キーボード全体の座高を低く、かつフラットにすることができた。今まで地味にキー位置が高くて、キーボード前にクッションが必要だったんだけど、その必要がなくなった。

筐体の作りなおし

3Dプリンタを得たのでより剛性の高い筐体になった。

USB HID での NKRO

そうすると妥協した次点として以下のような仕様を NKRO とするほかありません。

• 6キーまでは同時押しがコンピュータから認識される
• 7キー目を押すと、最初に押したキーが離されたと認識される

完全な同時押しは6キーまでですが、入力をとりこぼすということはありません。USB HID で NKRO と呼ばれているものはおそらくこの挙動をすると思います。

まぁ実際のユースケースとして、そもそも7キー以上の同時押しは極めて稀です。ということでさらに妥協して以下のような実装も考えられます

• 6キーまでは同時押しがコンピュータから認識される
• 7キー目を押しても無視される

これはこれでほとんど問題ないでしょう。単純に 6KRO になります。押した順番という状態を持つ必要が減るのでファームウェアの実装は簡単になります (バグを少なくできます)。一方で、キーを離さないクセを持つ人がものすごい高速タイピングをした場合にはキーをとりこぼすかもしれません。

PS-2 キーボードではどうなのか？

PS-2 キーボードのプロトコルは単純で、シリアル通信で

• キーを押すと Make 信号を発生させる
• キーを離すと Break 信号を発生させる

というものです。つまり NKRO になるかはOS側の実装次第です。

ゲーマー向けのマザーボードには PS-2 端子がついていることが多いですが、これは

• NKRO 対応のため
• レイテンシ削減のため

であると思われます。USB はホストからのポーリングで成りたっているため、キーを押した瞬間にコンピュータにデータが送られてくるわけではなく、コンピュータ側からのポーリングを待つ必要があります。ポーリング間隔はデバイス側から通知され、最小で1msまで設定可能ですが、OS 側に最終決定権があり、例えば Windows では最小で 8ms (Low Speed) , 1ms (Full Speed), 0.125ms (High Speed) です。つまりこの時点で最大で0.125msの遅延が発生します。

PS-2 の場合、キーが押された瞬間に Make 信号を送るため、理論的にはこちらのほうが早いことになります。

Fit API 全体の概念

単純にグローバルな「体重」に対して値を追加するみたいになっているわけではない。

各アプリケーション(サードパーティ含む)は自分用の「データソース」を作る。これはセンサーに対応する。例えば「体重計 HOGE-001」みたいなデータソース。このとき「体重 (com.google.weight)」とかデータの種類と「浮動小数点」とかデータ型の定義をしておく。

データソースの定義に従って、データソースにデータポイントを追加してく。例えば「体重は 69.95kg」みたいな。

こうしていくと、複数のデータソースから「体重」データがいくつもできることになる。

実は Google Fit の画面から体重を入力すると user_input というデフォルトで存在するデータソースにそのデータは蓄積される。一方で、自分で独自の「体重」のデータソースを作って追記することもできる。これによって、データソースごとに自分のデータにだけ責任を持つという形にすることができる。

これらの「体重」のデータは最終的に derived:com.google.weight:com.google.android.gms:merge_weight というデータソースに集計されて、Fit で表示されている。

あとアクティビティ(ランニング)に対応するセッションとかがあるけど、今回は使ってないので調べてない。

「体重」を記録する場合

なんらかの方法で体重情報を取得できるとして、それを Google Fit に保存したい場合を想定する。

全体の流れは以下の通り

• Fitness API が有効な OAuth の設定をする
  • Developer Console で 「Fitness API」を有効にしたプロジェクトをつくり、「OAuth 2.0 クライアント ID」を作成しておく。
• 対応するデータソースを作る (体重計を1つのセンサーとみなして)
• データソースへ値を追記する

Perl での例をしめす。CLI アプリケーションとしての実装。oob でキーを入力するため初回のみインタラクティブな インターフェイスになっている。

use v5.12;
use LWP::Authen::OAuth2;
use Path::Class;
use JSON;
use HTTP::Request::Common qw(GET HEAD POST DELETE PATCH);
use DateTime;

use constant {
	CLIENT_ID => '',
	CLIENT_SECRET => '',
};


my $token_file = file('.token_file');
my $token_string = eval { $token_file->slurp } || '';

my $google =  LWP::Authen::OAuth2->new(
	client_id => CLIENT_ID(),
	client_secret => CLIENT_SECRET,
	service_provider => "Google",
	redirect_uri => "urn:ietf:wg:oauth:2.0:oob",

	save_tokens => sub {
		my ($token_string) = @_;
		my $fh = $token_file->openw;
		print $fh $token_string;
		close $fh;
	},
	save_tokens_args => [],
	token_string => $token_string,
);

unless ($google->token_string) {
	# 新規 OAuth 認証
	my $uri = $google->authorization_url(scope => join(' ',
		'https://www.googleapis.com/auth/fitness.body.read',
		'https://www.googleapis.com/auth/fitness.body.write',
	));
	printf "Access to authorization: %s\n", $uri;
	printf "Input authorization code: ";
	my $code = <>;
	chomp $code;
	$google->request_tokens(code => $code);
}

# データソース作成
# 既にある場合は 409 になる
my $res = $google->request(POST "https://www.googleapis.com/fitness/v1/users/me/dataSources", 
	Content_Type => "application/json;encoding=utf-8",
	Content => encode_json({
		"application" => {
			"name" => "foobar baz",
			"detailsUrl" => "http://example.com",
			"version" => "1",
		},
		"dataType" => {
			"name" => "com.google.weight",
			"field" => [
				{
					"name" => "weight",
					"format" => "floatPoint"
				}
			]
		},
		"dataStreamName" => "foobar",
		"type" => "raw",
		"device" => {
			"manufacturer" => "my",
			"model" => "foobar",
			"type" => "scale",
			"uid" => "1000001",
			"version" => "1.0"
		}
	})
);

# 409 の場合エラーメッセージをパースしてデータソースIDを取得している
my $datasourceid = undef;
if ($res->code == 409) {
	my $json = decode_json($res->decoded_content);
	($datasourceid) = ($json->{error}->{message} =~ /Data Source: ([^ ]+) already exists/);
} elsif ($res->code == 200) {
	my $json = decode_json($res->decoded_content);
	$datasourceid = $json->{dataStreamId};
} else {
	die "failed to request creating data source";
}

unless ($datasourceid) {
	die "cannnot retrieve or create datasource";
}


# 送信するデータポイント
my $data_points = [
	{ epoch => ..., weight => 69.4 },
	{ epoch => ..., weight => 69.4 },
	{ epoch => ..., weight => 69.4 },
];

my $minstarttime = min map { $_->{epoch} } @$data_points;
my $maxendtime = max map { $_->{epoch} } @$data_points;

# 追加するリクエストは PATCH
# https://developers.google.com/fit/rest/v1/reference/users/dataSources/datasets/patch
my $datasetid = sprintf("%s-%s", $minstarttime, $maxendtime);
my $res = $google->request(PATCH sprintf("https://www.googleapis.com/fitness/v1/users/me/dataSources/%s/datasets/%s", $datasourceid, $datasetid),
	Content_Type => 'application/json;encoding=utf-8',
	Content => encode_json({
		"dataSourceId" => $datasourceid,
		"minStartTimeNs" => $minstarttime * 1000 * 1000 * 1000,
		"maxEndTimeNs" => $maxendtime * 1000 * 1000 * 1000,
		"point" => [
			map {
				{
					"dataTypeName" => "com.google.weight",
					"originDataSourceId" => "",
					"startTimeNanos" => $_->{epoch} * 1000 * 1000 * 1000,
					"endTimeNanos" => $_->{epoch} * 1000 * 1000 * 1000,
					"value" => [
						{
							"fpVal" => $_->{weight},
						}
					]
				}
			} @$data_points
		]
	})
);
say $res->as_string;

データソースを削除するには

既存のデータポイントが残っていると削除できないため、以下の手順を踏む

• GET dataPointChanges で全てのデータポイントを洗って、startTimeNanos の最小値、endTimeNanos の最大値をもとめる
• DELETE datasets で 求めた startime-endtime を datasetid とする (既存データポイントを削除)
• DELETE dataSources を行う

ただ、データポイントを削除しても deletedDataPoint に入るだけで、完全に消えるわけではない。データソースも、削除は通っても、再度作成を行うと、deletedDataPoint が含まれた古いデータが復活する。ここらへんの挙動はよくわからない。

コード例は以下の通り

my $page_token = "";
my $minstarttime = "inf";
my $maxendtime = 0;

# データポイントを走査してデータ範囲を確定させる
while (1) {
	infof("GET dataPointChanges with token %s", $page_token);
	my $res = $google->request(GET sprintf("https://www.googleapis.com/fitness/v1/users/me/dataSources/%s/dataPointChanges?%s", $datasourceid, $page_token));
	$res->code == 200 or die "failed to get dataPointChanges";
	my $json = decode_json($res->decoded_content);
	use Data::Dumper;
	warn Dumper $json ;
	@{ $json->{insertedDataPoint} } or last;
	
	$minstarttime = min $minstarttime, map {
		$_->{startTimeNanos}
	} @{ $json->{insertedDataPoint} };
	$maxendtime = max $maxendtime, map {
		$_->{endTimeNanos}
	} @{ $json->{insertedDataPoint} };

	$page_token = "pageToken=" . $json->{nextPageToken};
}

# 全範囲のデータポイントを削除する
if ($maxendtime) {
	my $datasetid = sprintf("%s-%s", $minstarttime, $maxendtime);
	infof("Deleting existing data points for this data source %s", $datasetid);
	my $res = $google->request(DELETE sprintf("https://www.googleapis.com/fitness/v1/users/me/dataSources/%s/datasets/%s", $datasourceid, $datasetid));
	say $res->as_string;
} else {
	infof("There are no data point");
}

# データソースを削除する
infof("Deleting this datasource");
my $res = $google->request(DELETE sprintf("https://www.googleapis.com/fitness/v1/users/me/dataSources/%s", $datasourceid));
say $res->as_string;

OMRON の Wi-FI 体重計

突然話は変わるがOMRON の Wi-FI 体重計を買ったのは失敗だなーと思っている。Bluetooth 体重計のほうがハックしやすいと思うからだ。Wi-Fi 経由で https でサービスと接続されているとサービス側の仕様変更やサービス終了の影響をうけてしまう。そして実際、オムロンはPC側のサービスを終了してしまった。

しかし BT 対応の体重計を買いなおすのも嫌なので、Android アプリが取得しているデータを普通にスクリプト (Perl) で取得できるようにして、Fit にインポートできるようにした。毎日動かせば常に Google Fit 側へデータが同期されるので、たとえ OMRON のサービスが終了しても、最悪データは失われない。リバースエンジニアリングしたので同期スクリプトの公開は控えるが、Google Fit のノウハウだけ記録しておく次第 (BT 体重計から Fit へ同期するアプリケーションなんかを書くときに役立つはずだ)。

Google はウェブの会社で、ユーザーデータの重要性はよくよく理解していると思われるので、サービス終了の際にエクスポートをちゃんと提供することが期待できる。一方でオムロンにそれは期待することはできない。PC版の閲覧サービス終了させてきたしね。

3Dプリンタのモデル設計の温度感

ここでいう 3D プリンタは普及している FDM (Fused Deposition Modeling・熱溶解積層法) の話です。FDM は基本的に X/Y 精度が悪く、Z精度はそれに比べると高いという特徴があります。

具体的には X/Y については±0.5mmぐらいで、Zは±0.1mmで考えます。特に X/Y の精度の悪さは設計難易度にかかってきます。同一条件で出力したパーツを組合せる分にはともかく、他の規格品、例えばナットや、あるいは三脚ネジのようなものを出したいときは、だいたいの場合は何度かプリントして現物あわせをする必要があるのです。

±0.5mm これはキャリブレーションしてフィラメント量を調節していてもなお生じる誤差と考えたほうが良くて、キャリブレーションしていなければもっと精度が出ません。

概要

• KiCAD からの出力
• pcb2gcode の設定
• machinekit (LinuxCNC) での操作

KiCAD でのデザインルール

0.25mm 幅で削るので、これが限界。0.05mm でもトレランスをとれれば安定しやすい。

• 最小配線幅は 0.25mm が限界。できれば 0.3mm のほうが安定。
• クリアランスも 0.25mm が限界。できれば 0.3mm ぐらいにしたい。

KiCAD からのエクスポート

- 切削する銅箔層 (F.Cu or B.Cu) と Edge.Cut をガーバーに出力する
- ドリルファイルを出力する

pcb2gcode

以下のような前提で gcode 化する

• 30° 先端0.1mm のVカッターを掘る用に使う
• φ0.8mm のエンドミルを全ての穴開けに使う
• φ1.5mm のエンドミルかφ1mmで2枚刃を外形カットに使う
• 基板の厚さは 0.8mm か 1.6mm を使う。基板の歪みを矯正できるぶん、0.8mm のほうが細かいパターンは削りやすく感じる。

先端0.1mmのエンドミルといっても、実際買ってみると綺麗に 0.1mm になっていることはすくない。というかすぐ先端が折れる。計算するときは 0.15〜0.20mm として扱う。

切削速度を落とせばφ0.8mmで穴開け〜外形カットまで可能で、ツール取り替えの手間が減らせるはずだけど、0.8mm のミルは高価であんまり折りたくないので、別途φ1.5mmのミルを使っている。これは今後 0.8mm にするかも。あんまり太いミルで外形カットすると切削抵抗が大きくなり、両面テープが剥れてずれる可能性もあるので注意。

# Use standard mm
metric=true
metricoutput=1

front=tachometer-B_Cu.gbr
#back=
outline=tachometer-Edge_Cuts.gbr
drill=tachometer.drl

front-output=front.gcode
back-output=back.gcode
outline-output=outline.gcode
drill-output=drill.gcode
milldrill-output=milldrill.gcode

# https://github.com/chrysn-pull-requests/pcb2gcode/blob/graphical-documentation/man/options.svg
zwork=-0.1
zsafe=1
mill-feed=220
mill-speed=10000
mill-vertfeed=150
mill-diameters=0.22
milling-overlap=25%
isolation-width=0.5

zdrill=-1.7
zmilldrill=-1.7
zchange=20
drill-feed=100
drill-speed=10000
min-milldrill-hole-diameter=0
milldrill-diameter=0.8

# 外形カット時のミル直径
cutter-diameter=1
# PCB板厚+0.1mm
zcut=-1.7
cut-feed=500
cut-speed=10000
cut-infeed=1
cut-side=front
# mirror-axis=51.575mm

optimise=true
zero-start=true

pcb2gcode して生成 gcode をデスクトップとリモートの Machinekit に転送する。デスクトップにコピーしているのは CAMotics で読みこませて確認するときに便利なので。

• mirror-axis を基板サイズの半分に設定すること
  • これやらないと back 面がマイナスからはじまってしまう
  • 一度実行して表示される width を元に書きかえる必要がある

~/ghq/github.com/pcb2gcode/pcb2gcode/pcb2gcode && cp *.gcode ~/Desktop/ && scp *.gcode machinekit@192.168.0.240:gcode

確認

• CAMotics を起動して、すべてのファイルを読みこむ。
• Workpiece を以下のように設定して再描画
  • X: xxx/0
  • Y: xxx/0
  • Z: 1.6/-1.6

段取り

• 事前に捨て板の面出しをする (φ6mm ぐらいのミルで加工面全てを 0.2mm ほどさらう)
  • AutoLeveller 使うなら毎回やる必要はない。
• ニチバン ナイスタック 透明タイプ (材質がセロハンのもの) を使って切削基板を捨て板に固定する
• このときしっかり全面を押さえつけて捨て板に接着する (加工時の圧力で高さが変わらないように)

AutoLeveller

• AutoLeveller に切削対象 gcode を読みこませる
• Probe Clearance は 0.5〜1、Z Safe Height は 1、Z feed は 50 にする
• create probe file only にチェックを入れて、Create Levelled Gcode ボタンを押すと、ALProbeback.ngc ができる
• ALProbeback.ngc を machinekit に読みこませる
• 一旦 Probe を行い、Z を Touch Off する (原点を設定する)
• 実行して基板全体を Probe する。
• .ini と同じディレクトリに RawProbeLog.txt ができているので、ローカルに転送する
  • gcode 用のディレクトリに RawProbeLog.txt への symlink を貼っておくと便利
• RawProbeLog.txt を AutoLeveller に読みこませる
• create probe file only にチェックをはずして Create Levelled Gcode を押す
• ALback.ngc ができるので転送する

drill や外形カットなどは面倒なので AutoLeveller はかけず、0.1mm 余計に掘る。

https://lowreal.net/2016/10/19/1

AutoLeveller の起動

java -cp ~/ghq/bitbucket.org/daedelus1982/autoleveller/out/artifacts/autoleveller_jar/autoleveller.jar  com.cncsoftwaretools.autoleveller.Autoleveller

生成 gcode の転送

scp ~/Desktop/*.ngc machinekit@192.168.0.240:gcode 

プローブログを手元に転送

scp machinekit@192.168.0.240:gcode/RawProbeLog.txt ~/Desktop/

切削手順

基板パターン

• ALback.ngc を machinekit に読みこませる
• 実行すると Probe をつけろと言われるので、つけて Resume
• Probe後、Probe をはずせと言われるので、はずして Resume
• 切削がはじまる

ドリル

• エンドミルをφ0.8mmに交換
• Probe を行い、Z Touch Off
• Feed Override を 10% ぐらいに下げる (折れ対策。pcb2gcode が mill 時と milldrill 時でフィードレートが変えられないので)
• drill.gcode を読みこんで実行

外形

• エンドミルをφ1.5mmに交換
• Probe を行い、Z Touch Off
• outline.gcode を読みこんで実行

備考