Original Prusa i3 MK2S Kit (3Dプリンタ) を買ってた | tech - 氾濫原 と書いたすぐ1ヶ月ほどあとに MK3 というメジャーアップグレードバージョンが販売されてしまってガックリきたが、部分的に MK3 からアップグレードを取り入れた MK2.5 Upgrade Kit というのが同時に用意され、直近購入ユーザ向けに割引の案内があったため、申し込んでおいていた。それが先日届いたのでアップグレード作業を行なった。

何が変わるか

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でプリントされたものが付属するが、ネジ止めするところを割ってしまった。
    • プリントレイヤー間で割れたので接着剤でつけた。ここはネジを締めること自体にトルクが必要なので、いまいちどこまでやれば止まっているのかわかりにくい
  1. トップ
  2. tech
  3. Original Prusa MK2.5 Upgrade がきたので作業した

MIDI デバイスを Lightroom のコントローラとして使えるプラグインとして MIDI2LR というのがある。市販のMIDIコントローラを使ってLightroomの現像パラメータなどを可変できるというもの。

しかし意外と市販のMIDIコントローラでちょうどいいのがないという問題がある。インターフェイス上の制限から、最適なコントローラは単純なロータリーエンコーダとスイッチの組合せで、常にインクリメンタルな値を送るものとなる。

ちょうどいいのがないなら専用品を作れば良いので、まずブレッドボードレベルで実装してみる。

コード

ロータリーエンコーダを処理するコードがあるのでちょっと長く見えるが 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 拡張が必要になる気がする。

  1. トップ
  2. tech
  3. mbed USBMIDI で Lightroom 用の MIDI インターフェイスを作る

BLE Nano を使っていた自作キーボードだったが、Mac のアップデートとともにまた不安定になってしまい、使う気を失ってしまった (数時間ごとに再ペアリングが必要に)。直す気力もなくてしばらく放置していたが、そろそろ観念して USB 接続のキーボードに作りかえることとした。

作りかえるといっても、キーボードの部分は I2C GPIO のモジュールとして動くように作ってあるので、マイコンまわりを載せ変えて実装を書くだけになる。

ということで、タイトルの通り LPC11U35 を使ってキーボードを実装しなおした。

コード: https://github.com/cho45/keyboard-lpc11u35

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 を作ったほうがいい気がするので (レポート定義もいじれるようになるし)、実際はそうしています。

ハマりポイント

sleep() がうまくいかない

ハマることはないと書いたが、メインループで sleep() (Active Sleeep) を使ってデバイスを割り込み待ちにするコードを書いたところ、USBHID#send() が失敗するという状態になった。どうやらUSBの状態まで狂わすようだったのでビジーループに変えた。

なんでおかしくなるのか、実装を読んだりマニュアルを読んだりして調べてみてもよくわからない。USB のクロックは有効だし、USB まわりの電源も sleep で切れるようなものはないように思える。

割り込み用のピンのプルアップが弱い

内部プルアップ時の電流がスペックだと 50μA となっている。電源電圧 3.3V なら 66kΩ 相当のプルアップとなる。

I2C を 2kΩでプルアップ動かしていると、この内部プルアップのピンをかなり動かしてしまうようだった。とりあえずは大丈夫そうだったが、今後誤動作の原因となりそうだったので、こちらも同様に 2kΩ で外部プルアップとした。

その他くだらないハマり

  • 一部のLANケーブルと相性がなぜか悪い
  • キーボード側で断線
    • かなり細いパターンの部分が見えないレベルで断線しており、割込みがかからない状態であった
  • sleep をやめたことによるバグ
    • キー入力がないときは I2C バスをやすませるような動作にしていたが、条件判定用の数値が sleep をやめたことによりアンダーフローしていた。
  • 時々キーが二重入力される
    • USB の通信遅延?
    • DEBUG 用に printf してるのが同期出力なのが原因っぽいので、本番で使う場合は必ず全 printf をオフにするように

接続

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

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

筐体の作りなおし

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

  1. トップ
  2. tech
  3. LPC11U35 でUSBキーボードを作る

NKRO (N-key Rollover) というのは、おおざっぱに言うとキーボードのキーを同時押ししたとき、いくつ認識するか?ということです。

NKRO の理想的には以下の挙動になります。

  • いくつキーを押しても全て同時に押されていることがコンピュータから認識される

これを NKRO として定義すると、全ての USB HID キーボードは NKRO ではありません。なぜなら、USB HID キーボードは修飾キーを除くと6キーまでしか押されていることを送信できないからです。

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 信号を送るため、理論的にはこちらのほうが早いことになります。

  1. トップ
  2. tech
  3. USB キーボードでの NKRO