RXマイコンの最適化に対する知見

RX65N Envision Kit が発売されてもうじき1年がたとうとしているが、アプリケーションを作っている人は非常に少ないように感じる・・
サーチエンジンで探しても、あまり有益な情報を探せない、現在、秋月では売り切れとなっており、それなりに購入している人はいると思うのだが、何か面白いアプリを作って発表し、ソースコードを公開している人はほとんどいないように感じる。
何がハードルになっているのか?・・・
それに比べて、M5Stack、ESP32、ARMなど海外のマイクロコントローラーは、非常に沢山あるようなのだが・・・
※何かあったら、リンクを教えて下さい。

さて、以前に「Arduino 用レイトレーサー」を実装している人がいて、コードが公開されていたので、RX65Nにポートしてみた。
その過程で、ルネサス公式のフォーラムにそのリンクを張った。
しばらくして、色々な指摘を受けた。
※自分のブログにも同じような指摘が返信されていたが、検証の材料が無く、ほぼスルー状態だった。
※自分の間違った知見もある・・

ルネサスのフォーラムでは、具体的な実験を行い、検証を行ってくれた。(感謝)
※単に思いつきで返信するだけじゃなく、このような、有益な内容のある濃い情報が重要だ、言うだけなら誰でもできる、何か発信するなら、せめて、自分で「手」を動かして、検証可能な情報を返して欲しいものだ。

そこで、指摘された事についてまとめておきたい。

  • gcc では RXv2 コアの最適化が不十分
  • double 定数を使っているのが余計
  • std::sqrt はdoubleの関数なので、sqrtf を使った方が良い
  • RXv2には、fsqrt 専用命令が用意されている
  • ESP32 などで公開されているベンチマークは、レイのサンプリングは「1」で行っているがRXでは、「4」で行っていて条件が異なる

gcc の RXv2 の最適化に関しては、自分の考え方が少しある。
まず、gcc のオフィシャルなソースコードを使う事を前提としているので、ルネサス社が、gcc に最適化のコードをコミットするまで待つしかない・・
現在ルネサス社は、独自にGNUツールを公開しているが、最新版は4.8系となっており、C++ の最新のコードをコンパイルする事が出来ない。
※ルネサス社が提供するGNUツールでコンパイルした場合、最適化「-O3」で、最大7~15%くらい良いコードが出る場合があるようだが、これは今後検証してみたい。
※オフィシャルな gcc では、「-mcpu=rx64m」など専用デバイスのオプションは無いが、標準で、RX600 系のコード出力となっている。

double の定数や、double 専用 API は、指摘を受ける前に既に、変更済みで、それで、ほんの少し高速になっていた。

標準の数学ライブラリでは、平方根を求める「sqrt、sqrtf」はニュートン法を使っており、RXv2 に備わっている、fsqrt 専用命令とは微妙に計算結果が異なっているものと思うので、標準では使わないのだと思っていた。
だが、この命令に切り替えた場合、倍の速度でレンダリングするようなので、この知見を素直に受け入れた。

#if defined(SIG_RX64M) || defined(SIG_RX71M) || defined(SIG_RX65N) || defined(SIG_RX24T)
static inline float sqrtf_(float x)
{
    __asm __volatile(
        "fsqrt %0, %0\n" \
        : "+r"(x) \
    );
    return x;
}
static inline int ceilf_(float x)
{
    int y;
    __asm __volatile(
        "pushc fpsw\n"
        "mvtc #0b10, fpsw\n"
        "round %0, %0\n"
        "popc fpsw\n"
        : "=r"(y) \
        : "r"(x) \
    );
    return y;
}
#else
static inline float sqrtf_(float x) { return sqrtf(x); }
static inline int ceilf_(float x) { return ceilf(x); }
#endif

レイのサンプリング数に関しては、全くノーマークだった、元ソースでは、標準「4」だったので、素直に「4」で行っていたが、ベンチマークを行っている Arduino のスケッチでは、「1」にして API を呼んでおり(卑怯なのではw)、大体4倍のレンダリング時間となっていた。
※「STM32F7 200MHz」では、0.62秒と非常に高速なので、この違いは、何なのか、疑問に思っていた・・・

以上の知見を受け、RX65N Envision Kit でレンダリングすると・・・

約0.83秒と、STM32F7 200MHz と比較しても、十分戦闘力のある値となったw
元は7.7秒とかだったので、素晴らしいパフォーマンスアップとなった。
※ESP32(160MHz)は、13秒みたいだが、これは、他にバリアとなる事象があるように思う
※このような有益な情報を提供してくれた「fujita nozomu」氏に感謝したい!

全ソースコードは以前から公開しているが、コンパイル環境を作り、フレームワークなどをチェックアウトする必要があるので、実行バイナリーも公開している。
・裏にあるスイッチを押す毎に、フルスクリーン(480×272)、レイのサンプリングを変更してのレンダリングを行う。

「raytracer.hpp」は、かなり柔軟性があり、ベンチマークには最適なので、PIC32や、他のマイコンでも十分実行できる、別のマイコンで試した人がいれば、是非情報を公開して欲しい~

WR250Xのバッテリー交換

昨日、大月から談合坂SAへ昼飯を食べに近くのにバイクに乗ったら、セルの回りが凄く弱っていると感じたー
これは、かなりヤバイレベル。
※山梨は、都心に比べて寒いので、バッテリーの劣化は注意を要すると思う。
※出先で、セルが動かなくなったら、WR250の場合、押しがけでエンジンを始動するのは凄く難しいと思う。
※ニュートラルにしないとオートデコンプが機能しない?(実際はやった事無いので、判らないが、あの高圧縮比のエンジンはクランクが相当重そうだ)

リチウムイオン系バッテリーは、2年前に買っていたが、元々のシールドバッテリーがまだ元気だったので、交換しないでいた・・(2年も持つとは・・)

リチウムイオン系バッテリーは同等の容量でも小さく軽い、今回買ったのは、容量的にはリッターバイクでも使えるものだが、それでも小さく軽い。
※LFX14L2-BS12
※バッテリーは、容量(大きい分には問題無い)の他、+、-端子の向きや位置が異なるものがあるので、十分適合を確認しておく必要がある。

パッケージには、サイズを合わせる為スポンジシートが色々入っていて、適当に切り貼りして、大きさを合わせる事が出来る。

交換は簡単で、10mmのソケット(シートを固定しているボルト)、5mmのスクリューキャップ、+ドライバー、カッター
交換して、元気にセルが回るようになったー
※サイドカバーは、シートを外さないと、外しにくい

チェーン、スプロケも交換用に買ったのだが、もう少し大丈夫な感じだ・・

PicoJPEG デコーダーを使う

以前に JPEG デコーダー「libjpeg」ライブラリーをポートしようと思ったものの、記憶割り当て不足で、実用的に使えなかった。
※libjpeg では、内部で画像サイズのRGBメモリを割り当てる為、当然のようにメモリ不足になってしまう。
ルネサスでは、オリジナルの JPEG(RXv2 DSP 命令で最適化した)ライブラリを公開しているようだが、肝心のコア部分ソースコードは未公開で、バイナリ化されており、gcc からは使う事が出来ないようだった。
そこで、libjepg を改修して、記憶割り当てを何とかしようと思ったが、既に、JPEGのデコードを少メモリで実現する「PicoJPEG」がある事に気が付いた。
なので、このライブラリを使わせてもらう事にした。

ポートは簡単で、「picojpeg.c」をコンパイルしてリンクするだけだ。
ただ、コンパイルエラーが出たので、多少修正した。
※ sequence-point のエラー
※このエラーは、式の評価順番に関係するもので、オリジナルの書き方は、C 言語の規約では「未定義」となるもののようだ。
https://www.jpcert.or.jp/sc-rules/c-exp30-c.htm

    *pDstR++ = addAndClamp(pDstR[0], crR);

以下のように書き換えた。

    *pDstR = addAndClamp(pDstR[0], crR);
    pDstR++;

サンプルを参考に C++ から簡潔に呼べるようにラッパーを実装した。
ラッパーは、テンプレートライブラリで、描画クラスを「参照」で与える仕様とした。
※BMP のデコーダーと同等の仕様。

ただ、PicoJPEG デコーダーは、「プログレッシブ」でセーブされたフォーマットをサポートしておらず「ベースライン」のみとなっている。
※「プログレッシブ」は、ブラウザなどで、最初荒く、後、詳細に表示するもので、通信速度が遅かった昔の名残で、最近のネット速度を考えると、ほぼ使う必要が無いモードと言える。
※プログレッシブ・エラーが出た場合には、フォームを確認して、「ベースライン」でセーブする必要がある。

480x272、ベースライン(最適)のJPEG表示サンプル
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
/*!
    @brief  PicoJPEG デコーダー
    @param[in]  RENDER  描画ファンクタ
*/
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++//
template <class RENDER>
class picojpeg_in {
.....
};

※描画を行うクラスを「RENDER」で渡す。
※「RENDER」クラスでは、「plot」APIを通して描画を行う。
picojpeg_in.hpp

今回、RX65N Envision Kit (AUDIO プレイヤー)でデコードと描画のテストを行った。
https://github.com/hirakuni45/RX/tree/master/RTK5_AUDIO_sample
※ターミナルからの「jpeg」コマンドでJPEGファイルを描画できる。

また、ID3 に含まれるPIC、APIC タグで埋め込まれたJPEG画像をデコードして表示させるようにした、ただ、適切なスケーリングをしていない為適切な大きさで表示されない。
※これは、今後対応する事にする。
又、PNG 画像もサポートされない・・

組み込みマイコンでstd::functionを~

少し落ち着いたので(実際は、やるべき事が山済み状態だけど・・)気になっていた部分をクリーンナップしている。
現在、俺俺フレームワークは、リアルタイムOSの助けを借りない方法で実装を行っているので、一連の長い処理を書く場合などにはコールバックの仕組みを与えている。
C++11 以降、STL には、そのような場合便利で安全な方法が多数用意されている。
しかし、その場合、通常は「stdc++」をリンクする必要があり、その場合、許容出来ない程大量のワークエリアを消費し、実用的では無い場合があった。

さて、コールバック機能を実装する場合、どうしても、「std::function」を使いたい。
・このテンプレートは、非常に強力かつ高機能だが、詳しい使い方は、検索してほしい。
・このテンプレートにする最大の理由は、ラムダ式が使える事で、コールバックの中身を「直」で実装できる。

しかしながら、これを使うとなると、関連する例外処理など他の機能を利用している為、stdc++ ライブラリのリンクが必須となってしまう。
しかし、よく調べると、g++では、「supc++」ライブラリが分離されておりこれをリンクすれば、最低限の消費で済む事が判った。
※「supc++」は「stdc++」ライブラリのランタイム部分のみ。
※例外の外部関数を実装する必要がある。

namespace std {
    void __throw_bad_function_call()
    {
        abort();
    }
}

※コンパイラオプションで例外を禁止していても、これだけはリンクする必要があるようだ。
※これは、「common/stdapi.cpp」に分離してあるので、Makefile にこのソースを追加する必要がある。

コールバック関数の登録で、重要となるのは、たとえば、クラス内からコールバックを設定するような場合だが、普通に書いた場合、「static」な関数しか登録できない。
※それでも別の逃げ方が無い訳では無いが、少し面倒・・
static だと、クラス内の public メンバーなどにアクセス出来ない。
そこで便利なテクニックとして、ラムダ式によるキャプチャー機能を利用する事で、以下のようにクラス内メソッドを呼び出す事が可能となる。

void play_loop_(const char* root, const char* start)
{
    static loop_t t;
    t.start = start;
    if(strlen(start) != 0) {
        t.enable = true;
    } else {
        t.enable = false;
    }
    sdc_.set_dir_list_limit(1);
    sdc_.start_dir_list(root,
        [&](const char* name, const FILINFO* fi, bool dir, void* option) { play_loop_func_(name, fi, dir, option); }, true, &t);
}

上記コードは、オーディオプレイヤーのコードで、ディレクトリーを巡って、オーディオファイルを再生する。
「sdc_.start_dir_list()」で、ファイル情報アクセス時に、設定されたコールバックが起動する。
「play_loop_func_」は、ラムダ式のキャプチャー「[&]」が あり、クラス内のリソースにアクセスする事が出来る。(これは本当に便利だ!)

まとめ:
「std::function」を使う事で、関数オブジェクトの利便性が強化された、これは、C++11以降の恩恵で、かなり大きなトピックと言えるが、組み込みマイコンのような制限されたリソースでもそれを活用できる事が判った事は大きい~

RX71Mを試す

かなり昔にデバイスは購入してあったのだが、中々試せないまま、RX65Nなどに寄り道していたのだが、240MHzの実力を評価したくて、一応試してみた。
RXv3
の発表があり、「RX71M」も最高性能のRXマイコンでは無くなってしまったが、それでも、240MHzは120MHz版に比べてどのくらいの性能があるのか試しておきたい。

169ピンのユニバーサル基板も手持ちが最後なので、次は基板を起こす方が良さそうだ・・(この基板、安くて小さくて便利なのだが、販売終了しているぽぃ)
以前にRX64Mの試作では、SDRAMの32ビットバスを試したが、あれは、ちょっとマズイ・・、32ビットのデータ幅を割り当てると、他に使うペリフェラルが極端に制限されてしまい、イーサーネットやSDHCに割り振る事が難しくなる、なので、今回は16ビットバスでSDRAMを載せようと思う。
※このデバイスは「もらった」もので、SDHC未対応なのだが・・・
RX65NのEnvisionキットでファミコンエミュレーターなどを試して、やはり外部メモリーは必須だ・・(内臓メモリが1Mバイトくらいあれば・・)
RX71Mには、RX65NのようなLCD制御機能は無いが、単純に接続するだけなら、EXDMA転送で代用できそうだし、SSI(シリアルサウンドインターフェース)など、デジタルオーディオ系にも強そうだ。

今回試作して判った事として、電源ラインの重要性だった、面倒なので、アナログの電源は接続しなかったのだが、それが原因で、ブートモード(SCIインターフェース)でデバイスのコネクションが正常に終了せず、接続できなかった、電源は全て接続してパスコンも付けていたのだが、原因がわからずにいたが、関係無いと思うけど的な感じで、アナログ電源を接続したら、あっけなく正常動作した。

240MHz動作は、既に実績があると(依然にRX71Mを使ったボードを設計して、納入した実績があり、その時は問題なかった・・)思っていたが、何か怪しい動作をする。
具体的には、240MHzで動かすと、SCI関係で文字化けを起こす・・
CPUのクロック以外は、120MHz版と変わらないので、原因が判らない・・
プログラムは暴走する訳ではなく、動いているようだ。
120MHzであれば問題無い・・
どうも、240MHz動作時は、最大で240mAの電流が必要らしいので、そのせいかと思ったが違うようだ・・
ただ、USBから供給する電源の品質はあんまし良くないのと、瞬間的に大きな電流を「引く」とかなりドロップする。

オシロで、SCIの信号を確認して、やっと解決、ベースクロックのPLL定数を求めるソフトのバグだった・・、240MHzと思っていたら180MHzだった。
※そりゃー文字化けするよなぁーwww
クロック設定クラスは、以前に収めた機器では、240MHz固定だったのだが、最近テンプレート化して、色々柔軟性を求める仕様に拡張した過程で、マズイ実装を行っており、120MHzだけは正確に機能していた・・・
ハードの問題だと思って色々対策して、結局ソフトのバグとゆーのは、まぁ良くある話なのだがー、最近視力が落ちて、配線の質が落ちており、ハードに自信が無いと思っているのもある・・
さらに、鉛フリーハンダは、温度に敏感で、少し低いと綺麗に付かない。

中華製VFDで問題発生(CNC6040)

CNCの要と言えるスピンドルモーター、80mm直径、ER16、水冷式を購入、それに合わせてVFD(インバーター)も購入(HY01D511B)、物が届いたので、早速火入れをしてみた。

ところが、超低速では回るものの、周波数を上げると10Hzくらいで停止してエラーコードらしきものが表示され強制停止する。
「E.oL.A」
このエラー、マニュアルを見ても載っていない・・・
設定が悪いのかと思い、色々変更してみたが、同じようにエラー表示で停止する。
不具合の問題を切り分ける為、別のVFDに接続して回してみた(やはり中華製)、こちらでは、ギュンギュン回る、やはりVFDの初期不良のようだ、VFDの横にテクニカルサポートのメールアドレスが印刷してあるので、メールで不具合を聞いてみたら、モーターの型番を教えて欲しいとの事で、写真を撮って、メールを返した。
※英語の文書を作るのは翻訳エンジン頼みなので、イマイチだ・・・
今、ココ・・・
初期不良だとしても、送り返す手間や送料など、かなり面倒な事になる・・
まぁ仕方無い、それが中華品質だ・・・

そもそも、日本製のインバーターだと、100Vで使えるものが少ないうえに割高だし、少し調べた限りでは、100V、1.5KWはラインナップしていない。
かと言って200V用を買って、屋内配線を200V対応にするとか、かなりハードルが高い、昇圧トランスを買うにもコストが高い・・・
どうしたもんか・・・
まぁ、対応がアレな場合、修理するしか無いと思える。
それか、インバーターを自作するしか無いかも・・・

エラー表示のVFD
問題無く動作するVFD、非常に概観が似ているが、違うメーカーのようだ・・・

動作するVFDは、RS485で制御する事が出来ないようなので、追加で買ったのだが「ハズレ」を引いたようだ・・・

KIT-RX65Nラップタイマー(その1)

デジタルストレージオシロスコープは、部品が揃って無いので、保留状態となっており、新たにラップタイマーの実装を行っている、ゆくゆくはデータロガー的な物にしようと思う。
本当は「もて耐」で使う予定だったが、本業が忙しく間に合わなかった・・・

RX65N Envision Kit で何かを作る場合、ケースはどうするか?
ピッタリ収まるような汎用品を探したが、見つからない・・
※かなり大きく厚くなってしまう・・・
そうなると、作るしか無い、以前に「フォーレックス」と言う発砲プラスチックでケースを作った事がある、カッターで切れて軽くて作りやすいものの、意外と柔軟性が無く、簡単に割れたりもする。
そこで、専用ケースを作る為、とりあえず、一番安い3Dプリンターを買ってみた。
まだ組み立て中で調整も試運転もできていないが、前から欲しかった事もあり、ついついポチってしまったw
※比較的安い物を買ったので、安物買いのナントカにならないか不安ではあるのだが・・・

ラップタイマー的な物は、昔にAVRで作った事がある、液晶は128×64のモノクロで、今でも動作するのだが、かなり大きく(厚みがある)、バイクに付けるには少し大きすぎる・・
ラップタイマーだけなら、P-LAP などで十分だが、それなりの値段でもあるし、GPS を使った区間タイム表示、インジェクターパルスを収集して正確な燃費計など、やりたい事は色々あり、性懲りも無くまた作る事にした。
※今までに、何回もやり直してきたが、中途半端な状態でストールする苦い過去がある。
とりあえず、以前のリソースを元に液晶のGUIデザインなどをカットアンドトライで行っているのだが、解像度が高いので GUI のビットマップなどを作り直す必要がある、また、タッチパネルなので、それに合った操作性にする必要がある。

その前に、カラー画像を表示する為、BMPファイルのローダーをポーティングした。
BMPなら、比較的フォーマットが単純なので、メモリーを多く消費せず、また以前にアプリ用に実装したソースコードがほぼそのまま使える。
※少し前に JPEG のローダーをポーティングしたのだが、libjpeg では、構造上、一時メモリが必要で、メモリ不足で動作しなかった、libjpeg の API 操作だけで、一時メモリを必要としない方法もありそうだが、それに関連する情報が少なく、ライブラリソースを研究する時間的余裕が無く保留にしてある。
BMP でも、通常は、デコードした画像情報を一旦メモリーに蓄えて、フレームバッファにコピーする手法を取るのだが、余分なメモリーは無いので、デコードしながら直接フレームバッファに描画する。
BMP では、フルカラーは無圧縮、インデックスカラーはランレングス圧縮なので、ワーク用メモリを殆ど消費しない。
この為、BMP ローダーをテンプレート・クラスとして、描画クラスを参照で渡す仕組みに変更した。

template<class RENDER>
class bmp_in {
    RENDER&    render_;
...
    bmp_in(RENDER& render) : render_(render) ... { }
};

コンストラクターで、RENDER クラスの参照を渡す、BMP デコード時、このクラスを使ってフレームバッファに直接描画する。
※テストで使った BMP ファイルは24ビットカラーだけど、液晶は RGB565 なので、マッハバンドが気になる、またこの液晶は、視野角がかなり狭いのが痛い(低価格だから仕方無いのか・・)
※BMP 形式では、24、32、ビットフォーマットは圧縮されないので、やはりPNGなどもサポートする必要がありそうだー、その場合、Zライブラリーもポーティングする必要性がある。

GUI の部品は、bmc (ビットマップコンバーター)で変換した bitmap ストリームとして持っていて、他に、オブジェクトの横幅、高さ情報も保持している。
液晶が 128×64 くらいでは、この方法でも部品が小さいので問題無いが、480×272くらいだと、オブジェクトが大きく、速度の面でも、メモリーの面でも効率が悪い。
そこで、今後の事を考えて bmc に機能を追加して、簡単な圧縮フォーマットを実装する必要がありそうだー
とりあえず、カラーは考えないで、モノクロで、そこそこ、描画が効率良く行えるように、シンプルなフォーマットを考える必要がある。
※本来、モノカラーでも、「黒」、「白」の他に「透過」のアトリビュートが欲しいところではあるが、部品の描画を行うアプリ側で、細かく実装を行い、何とか見た目の問題を回避している、より複雑な GUI が沢山あると、これではマズイと思うのだが、その時考える事にしておく・・・

また、GPSから出てくるテキストのパースなどを実装する必要があり、実験したいのだが、部屋の中では、電波が弱くて受信出来ない、そこで外部アンテナを取り付けて、アンテナだけ外に出すようにした、実験してみると、窓枠に置いておけば、(窓が閉まっていても)ギリギリ受信出来る事を確認して、出てくる「経度、緯度」から、自宅の位置を確認した。
※以前にSUP500、GPSレシーバーを使っていたが、販売されていないので、10Hz出力が可能な物「GTPA013」を再度購入した、外部アンテナと、接続コネクターは秋月で入手出来た。
GPS関係では、データをロギングした後に軌跡を表示したりするアプリも作る必要があり、まだまだ調べたり実験する事が沢山あるので、これからの研究が必要な分野なので、まだまだ時間がかかりそうと思う。

CNC-6040、リニアブッシュの交換(その2)

注文していた、オープン型リニアブッシュが届いたので、交換した。
やはり、以前の物とは明らかに違う、今度のは、ガタつきが無く(当然だけど・・)、シャフトに通すと、少し渋いくらいな感じだ、今回グリスではなく話題の「ベルハンマー」を購入したので、それをスプレーしたら、かなりスムーズに動くようになった。

ホルダーからリニアブッシュを抜く際に、何か良いものが無いか探したら、サランラップの芯が、ベストなサイズだった、しかも紙なのだが強度も十分にあり、キズも付かずに、簡単に抜く事が出来た。
向かって左側のホルダーは、少しきつめになるように加工(トゲ的な出っ張りを数箇所作って調整されていた)されているが、右側は、加工は無く、スルスル入る、ホルダーには、ブッシュを押さえる為と思われる、ネジ穴があり、そこに、ビスを付けて適度に締め付け(フライスなどのテーブルのカミソリを押さえるような)、ガタ付きをキャンセルできるようにしてあるので一応利用させてもらった。

次に、テーブルを固定するボルトが渋いので、タップを立て直す。
この時、タッピングペーストを使うが、以下の物が優れもので、穴あけでも抜群の威力を発揮する、この感覚は使った人じゃないと判らないが、CRCやオイルなどとは雲泥の違いがある、そんなに高い物では無く量も多くてリーズナブルだと思うので、穴あけなど、一度試してみる事をお勧めしたい!

Tスロット・テーブルを固定する穴は、かなりいい加減で、中心に空いていない箇所があり、ミニルーターを使って、適度に広げた、また、使っているビスが短い為、ネジが噛む部分が短く、強く締め付けられない、しかも普通形状のビスが使われているが、スロットを使う場合に「あたる」ので皿ネジか、低頭ネジを使うべきと思う、こうゆう質の悪さは、折込済みとは言え、やはりガッカリする、ほんの少しだけ気を使うだけで良いのに・・・
ステッピングモーターを固定するビスも、上部ユニットを固定するビスも短すぎて、ネジを噛む部分がほんの少ししか無い、強く締めたら簡単にネジ山が飛んでしまうだろう・・
剛性の強化も必要なので、少しづつ観察しながら進めていこうと思う。
※スピンドルモーターを買い間違えてしまい、注文しなおしたので、まだ先は長い・・

このCNCを載せる為、新たにメタルラックを購入して、天板を加工した、外は雨なので、家の中で電動ノコを使ったら、削りかすが凄くて掃除が大変だった・・・(当たり前だけど)
CNCを運転するまでに、左右と後ろ、前にボードを貼って、切子が飛散しないようにしないと大変な事になる、その板も購入してあるが、それはもう少し後で加工する事にする。
前は、透明な板とかにして、中が見えるようにしたいものだ・・・

RX24Tを使ったCNCコントローラーボード(その1)

CNCで、各軸を動かすモーター制御は、市販されているボードを使う事も出来るが、大抵はPCから制御するだけのボードで、PCを介さない状態で、手動で動かすインターフェースや、各軸の位置表示(PCの画面で行う)なども欲しいと思うので自作してみる事にした。
また、Gコードをパースするだけじゃない方法など色々なフォーマットや、インテリジェンスな制御系も試せる(カメラで画像認識を併用するなど)と思う、他にフライス盤をCNC化するのが中途な状態でもあり、最低2台は必要な事もある。

一般的に、Gコードのパース、制御では、「Mach3」が有名で、このソフトウェアーは非常に優れていて、柔軟性もあるのだが、ライセンス料が少し高い(自分にとっては)、また、ドライブのハードウェアーを簡単にする為、パラレルポートに直接駆動パルスを出力する仕組みで、PCの能力や、裏で動作するデーモン系の動作などに左右される印象を受ける(これは回避するHowToが十分整ってはいると思うのだが)、ハードやソフトを自作する方がよっぽど面倒で時間のかかる作業ではと思うのだが、「作ってみたかった」のが大きい。

マイコンは何にするか考えたが、自分の手持ちで手頃なのはRX24Tだ、このマイコン、元々はモーター制御などに適した構成のRXマイコンだけど、普通に他の用途に使っても十分な性能で、安く、CPの高いマイコンだと思う、ただ、USBは内臓されていないので、PCとのインターフェースはシリアル通信を使う事になる。(以前に10個まとめて買ったので、まだ沢山ある、@540)
・RX、32ビットコア
・80MHz動作
・PWMタイマーなどが80MHzで駆動できる。
・256Kのプログラムメモリーと16KのRAM
※最近では、CANインターフェース付きで、プログラムメモリーが512K、RAMが32Kの製品が、ほぼ同じ価格で販売されているようだ。(@570)

モーターはステップモーターなので、32段階のマイクロステップ動作が可能なドライバーを3台購入した。(1個7ドルほどだった)
「マイクロステップ」は、元々イギリスのベンチャー企業が始めたと思うのだが、磁気回路の特性に合わせて、相に流れる電流をベクトル制御する事で、見かけの分解能を再分割する技術だ、2相のステップモーターの場合、直交するXY軸の関係なので、それぞれ、サイン、コサインの電流割合で制御する事で、理論的には、無限大に分解能を上げる事が出来る。
今回買ったドライバーは、32段階までが可能なので、1回転200ステップのモーターなので、6400パルスで1回転の制御が出来る。
モーターの定格は、3Vで3Aのようだが、それは静特性で、動特性では、回転速度が速くなる程コイルのリアクタンスにより電流が流れにくくなるため、より高い電圧が必要になる、今回のドライバーは最大40Vで3.5Aまで可能なので、丁度良いと思う。
また、モーターを動かしたり停止したりを繰り返す場合、ドライバーはチョッパー動作でそれなりの効率ではあるが、モーターに蓄えらたエネルギーを吸収する必要があり、ドライバーはかなり発熱すると思うが、それなりに大きなヒートシンクが付いている。

とりあえず、モーターの回転は確認出来たので、ソフトを作りこんでいこうと思う。
まず、3軸同期で直線移動などだが、一般的には「ブレゼンハム」のアルゴリズムで、ステップパルスを生成するのが相場だろうが、自分は、分数を使う事にする(結果的にはほぼ同じだが・・)。
分数の場合、分母、分子を組で管理して、単純な足し算を使って行い、1以上になったら、パルスを発生させ、分子から分母を引く、このようにすると、切捨てが起こらないので、誤差が全く発生しない。
ハードウェアーは、リミットスイッチの入力インターフェースが無いので、それも載せる必要があるが、アイソレーションに使うフォトカプラが手元に無い・・
また、スピンドルモーターの制御用出力も載せる必要がある、スピンドルモーターは、三相モーターで、インバーターで制御するが、そのままだとOn/Offしか出来ない。
回転数の制御はボリュームなので、D/A出力も必要だろうか・・(シリアル接続で、コマンドで出来れば良いのだが、このインバーターには機能が無いようだ・・・)

CNC-6040を購入

東京から山梨の一軒家に引っ越して、もう9ヶ月になる。
いまだに、荷物整理などもままならない状況ではあるが、仕事も落ち着いて、多少時間を取れるようになったので、工作部屋の整理を始めた。

そして、中華のCNCを導入する事にして、今月の初めころ、物色していたが、オークションに出品されている物や、色々情報を集めた結果、「AliExpress」で買う事にした。
最初は、比較的手ごろで、バリエーションが多い「3020」系にしようと思ったが、イマイチ工作サイズが小さい、そこで奮発して「6040」系にする事にしたが、機材の値段は許容範囲でも、送料がかなり高い・・
それでも、日本の業者から買うよりはずっと安い。
このCNCは、基本、アクリルや、木材などがターゲットだが、アルミくらいなら、許容できる精度で削れるものと思う、また、改造すれば、剛性を上げたり色々出来るものと思う。

全て揃ったパッケージでは、日本向けに(電源電圧の仕様など)適当な物が少なく、バラで買う方が自分の好みの仕様に出来る事がわかって、バラで購入する事にした。

「バラ」と言っても、本体、ステップモーター、ステップモータードライバー、スピンドルモーター、スピンドルモータードライバー、くらいの分類で、色々選べる。

本体:
https://ja.aliexpress.com/item/Best-cnc-machining-aluminum-parts-mini-6040-CNC-router-lathe-assembled-motor-with-limit-switch/32868175584.html?spm=a2g0s.9042311.0.0.49974c4dSiOurA
先日、DHLで送られてきたー、送料だけで190ドル、本体600ドル。
本体は3軸分のステップモーターが付属しており、ちゃんとした?ボールスクリュー仕様で、剛性もそこそこありそうな物だった。
※探すと、もっと安い物はあるのだが、より剛性がありそうな物にしておいた。
ほぼ、組み立てられた状態で二つの箱に分けられて送られてきた、かなり重い(40キロ~50キロくらいある・・)

梱包を解いて取り出してみた、機材はほぼ組み立て済みで、Y軸とテーブル、XZ軸周りの二つになっている。
しかし・・・、いきなりトラブル、Y軸の移動は、オープン型の円形リニアガイドと20mmのシャフトが使われているが、指でラジアル方向に押すと明らかにガタつきがある・・・

どうやら不良らしいが、交換のやりとりや手間がわずらわしいので、リニアガイドだけ別途買って自分で交換する事にした。(LM20UUOP)
https://ja.aliexpress.com/item/MSM-Open-Type-Linear-Bearings-4pcs-lot-LM12UUOP-LM16UUOP-LM20UUOP-LM25UUOP-LM30UUOP-Shaft-Sliding-Ball-Bushings/32816522273.html?spm=a2g0s.9042311.0.0.49974c4dSiOurA
※4ピースで14ドル程度、一応、「高品質」な物を購入した。
日本でも大手のベアリングメーカーがリニアブッシュは扱っているが、オープン型は見つからなかった、また中華製だが、今度は大丈夫と思いたい・・(このくらいのトラブルは折込済みだ)
送料は無料だが、到着まで二週間くらいかかるようだ(多分船便なのだろう・・)

XZ軸部は、カバーのアルミが、おもっきり曲がってる・・・、梱包時に重いステップモーターの箱がこの上に乗っており、それで曲がったものと思う・・・

基本的に中華品質とは、そのような物で、その分安いので我慢する、それがイヤだったら、日本の業者から購入すれば良いだけの話。
※日本で買うと3倍以上のコストになると思う。
分解してみて、きり粉が、隙間に残っていたり、タップ立てがいい加減だったり、色々あるが、それくらいなら、自分で対応できる、基本的にそれが楽しめるくらいじゃないと駄目なんだと思う。
痛いのは、スピンドルモーターの仕様だ、写真の説明では65mmとなっていたので、直径65mmのスピンドルモーターを買ったが、実際には80mmのようだ・・・
スピンドルモーターは100ドルくらいなので買いなおすか、スペーサーを作って対応するか、思案中・・・
他に使いたい用途もあるので、物が届いたら、どうするか、また考える事にする。

追記:
よく調べたら、オープン型リニアブッシュ、日本製も扱ってた・・
ただ、値段は4倍くらいする(スチール製)、もう注文しちゃったので、それがイマイチなら、日本製に交換する・・
https://www.monotaro.com/g/00504277/

Just another WordPress site