Milk-V Duo256で ねこカメラを作る。~2~

前回、Duo256を使って庭にやってくる猫を自動認識し、レリーズ端子に接続した外部デジカメで撮影する事が出来ました。
でも下の写真の様にDuo256と一眼レフを並べるという、面倒な方法になっています。

でもね・・・

わざわざ一眼レフと接続しなくても、Duo256ひとつで撮影まで済ませたいですよね。
Duo256の開発環境はTDL-SDKというライブラリ群を使って行います。これを使ってカメラで撮影するとVIDEO_FRAME_Sという構造体に画像データが入るっぽいので、ここから画像を取り出してファイルに残せば済みそうですが、ドキュメントを見たり色々試したりしても、データを取り出す方法が見つかりません。
またDuo256にはOpenCV mobileというライブラリ群もリリースされていて、こちらを使って撮影する事もできるのですが、今度はYOLOに渡す為に画像をVIDEO_FRAME_Sに入れる方法が分かりません。
ならばこれらのライブラリ使わずにやろうとすると、今度はハードウェアにアクセスする方法が情報不足となるのです。
という状態なので、どなたか分かる方、教えてください。

で、また苦し紛れの対策その2

OpenCV mobileで静止画を撮影するサンプルプログラムと、静止画をYOLOで判定するサンプルプログラムが公開されているので、これらを改造して一旦画像ファイルに書き出したファイルをYOLOで判定する方法でやってみます。
でも毎回SDカードに書くとすぐにFLASHメモリがヤラれそうですよね。
ならばRAMディスクなら問題ないだろな・・・と思ってdfコマンドを実行したところ、/tmpはtmpfsデバイス(≒RAMディスク)をマウントしていました。
という事は/tmpの下に画像ファイルを置けばFDカードに悪影響は無いでしょう。

ではまずyolov5のサンプルプログラムを元に、猫、犬、カップ(デバッグ用)の検出有無を返すプログラムをnekoyoloという名前で作成しました。

次にopencv-mobileサンプルプログラムを元にしてnekoshotというプログラムを作成しました。こちらは静止画を撮影して/tmp下にjpegファイルを作成した後、上のnekoyoloを実行して戻り値が「検出あり」ならその画像を改めてSDカードに書き出す・・という動作を繰り返します。なおSDカードに書き出すファイル名は重複しない様に連番を付けておきます。

図にすると以下の感じ・・・


nekoyoloプロセスはその都度生成しては消えるので、起動のオーバーヘッドが加わりますが、今のところ2秒周期程度で繰り返しているのでまあ良しとします。

動かしてみる。

ではまた窓ガラスに貼り付けて動作させてみます。
前回の様に横に一眼レフを置く必要が無いので設置は簡単です。

Duo256とPCの間はUSB-NCMで接続しているので、動作しながらも下図の様にWinSCPで様子を見る事ができます。
下図の5つの画像ファイルの内、最初の3つは例によって動作確認用のカップの画像で、最後の2つには猫が写った様です。
なおDuo256内にはバッテリ駆動の時計は無いのでファイルの更新時刻はメチャクチャです。(USB-NCMではなくEthernet接続にすればNTPで時刻を合わせられる気がする)

早速ファイルを開いてみると・・・お、いるいる。

そしてもう一枚。

前回撮れた2枚の写真とは違う猫に見えますね。
もう暫く動作させてみましょう・・・

そして後日もう一枚。走ってる走ってる。

上のと同じ猫かもしれませんがハッキリ見えません。

・・・という事でDuo256単体で猫検出&撮影ができる様になりました。

こうなるとPCとは接続せずにモバイルバッテリーから電源を入れて放置するだけで撮影したいです。これには電源を入れたら勝手にnekoshotが起動する必要があります。
普通のLinuxだと/etc/rc3.dの下に設定ファイルを置いたりしますが、Duo256の場合/mnt/system/auto.shが起動時に実行される様なので下記の様に記載しました。
なおnekosyotとnekoyoloの実行ファイルは/root//workの下に置いています。
またLD_LIBRARY_PATHを設定しておかないとyoloがライブラリを見つけられませんでした。

プログラム

今回のプログラムです。
/data/nekoshot.tar.gz
/data/nekoyolo.tar.gz

コンパイル済バイナリも含んでいますが、再コンパイルする場合は前回のライブラリに加えてopencv mobileライブラリが必要です。インストール方法は本家の下記ページに記載があります。
https://milkv.io/docs/duo/resources/opencv-mobile

ライブラリの配置は下記前提にしています(これと違う場合はMakefileを要修正)。

~/milkv
  ├duo-examples
  ├cvitek-tdl-sdk-sg200x
  ├opencv-mobile-4.10.0-milkv-duo
  ├host-tools
  └myproj
   ├nekoshot
   ├ ├Makefile
   ├ └nekoshot.cpp
   └nekoyolo
    ├Makefile
    └nekoyolo.cpp

Milk-V Duo256で ねこカメラを作る。

前回に続きMilk-V Duo256をいじくっている話の続きです。

Duo256にはAIを処理する為のTPU(Tensor Processing Unit)が載っています。
前回書いた様に、トラ技2024年12月号にはこれを使ったサンプルの実行例が2件載っていたので、これに従い下記の動作を確認する事が出来ました。

  • 顔検出
    カメラの動作テストに含まれている。PC側でVLCを実行して動画をモニターでき、人間の顔を検出すると枠で囲んで表示する。
  • YOLOv5
    写真ファイルに対して物体検出&分類を実行し結果をテキストで表示する。

動画でYOLOv5を動かしてみる。

で、この先です。
YOLOを動画でも動かせるのかなーと思って色々調べたところ、開発ツールのcvitek-tdl-sdk-sg200xの下、sample/cvi_tdl ディレクトリにsample_vi_od.cというソースコードが付属していて、これをコンパイルすれば実行できそうな感じです。
それにはPC上でクロスコンパイルする必要があるのでWSL(Windows Subsystem for Linux)上で、下記ページに従い実行しました。

https://milkv.io/docs/duo/application-development/tdl-sdk/tdl-sdk-introduction

そしてコンパイルしたファイルをscpでDuo256に転送し、実行権も付けておきます。

このプログラムを実行するにはモデル名とモデルパスの2つの引数が必要です。
モデルパスは学習済AIモデルへのファイルパスで、モデル名はAIモデルに応じた動作をプログラムに伝える為の名前です。なのですが実際に何を指定したらいいのか、ズバッと書いた説明が見つかりません。
そこで引数無しで実行した時に表示されるUsageにモデル名一覧が書いてあったので、この中から”yolov3″で試してみます。そして学習済みモデルはhttps://github.com/milkv-duo/tdl-models/tree/milkv/cv181xにあったのをダウンロードしてきました。これを~/tdl-models/cv181x下に置いてこの中にあるyolov3.cvimodelを指定してみます。

こんな感じで・・・
./sample_vi_od yolov3 /root/tdl_models/cv181x/yolov3.cvimodel

しかしOut of memoryとか出てきて動作しません。

そこでモデル名に指定した引数がどう扱われるのかソースをみていくと、get_od_model_info()という関数に渡していました。更にこの関数を辿っていくとUsageには含まれていなかったYOLOv5も動作する様な記述があります。
という事で以下のコマンドラインでそれらしき動作を開始しました。
(コマンドが長ったらしくなるのが嫌なのでAIモデルは同じディレクトリにコピー済です)

./sample_vi_od yolo5 yolo5_s.cvimodel

でも下記の様にyolo5_mの方が認識結果が良い様です。

./sample_vi_od yolo5 yolo5_m.cvimodel

VLCでモニターすると・・

おお!それっぽく検出していますね。でも検出した物が何なのかを表示していないです。

コマンド画面上でも下記の様に何個の物体を見つけたかという数字は出ていますが、これが何なのかは表示していません。

ちょっといじくる。

という事で更にソースコード(sample_vi_od.c)を見てみます。
どうやらこのプログラムの中ではビデオデータを受け取るために二つのスレッドを生成し、一方はコマンド画面への結果表示、もう一方は検出した物体を囲む枠と文字情報を生成して映像に重ねた上でRTSPに流す(これをVLCで受けて表示している)仕組みになっている様です。

そして映像に枠を書く方の関数run_venc()の中を見ていくと、68行あたりに下の記述がありました。

sprintf(name, "%s: %.2f", stObjMeta.info[oid].name, stObjMeta.info[oid].bbox.score)

この行ではstObjMeta.info[oid].nameに物体名が入っている事を期待してそうですが表示されていません。
そこでstObjMeta.info[oid].classsというメンバー変数を表示させてみるとクラス番号が入っていました。YOLOのクラス番号は下表の様に80種の物体と番号が対応していて、クラス番号が15なら猫、16なら犬となります。

ならばこの番号を元に名前に変換してやれば良さそうです。
そこで提供された開発環境内のヘッダファイルにこの表に相当するコードがあるかと探しましたが見当たりません。
仕方ないので新たにyolov5class.hという名前のファイルを作ってこの中に記述し、これをソースにインクルードした上で先ほどの行を下の様に変更してみます。

sprintf(name, "%s: %.2f", yolov5class[stObjMeta.info[oid].classes], stObjMeta.info[oid].bbox.score);

すると・・・

いいんじゃないでしょうか。

そしてテキスト表示スレッド内のrun_tdl_thread()にも変更を加え、何を見つけたのを表示させました。

ねこカメラを作りたい。

という事でここからが本題です。我が家の庭はよく猫が通っていくので、猫を検出したら写真を残す「ねこカメラ」を作ってみたいと思います。

上記の通りYOLOv5は猫を見つけると15番が返ってきます。その時に画像を保存すれば出来上がり・・・と簡単に考えていたのですが画像をファイルに落とす方法が判らずハマりました。VIDEO_FRAME_Sという構造体に画像データが入っていそうなのですが取り出せないのです。

この状態だと進まないので、とりあえずは苦し紛れの策で対処したいと思います。
上記のテキスト表示スレッドで猫を示す15番を検出するとGPIO(G15)にパルスを一発出して、これを外部デジカメのレリーズ端子に入れて撮影するのです。
パルスを一発出した後の5秒間は出力無しにしています。またパルスと一緒にLEDも点灯して動作が分かる様にしました。

使ったカメラはちょっと古いCanonのデジタル一眼レフです。このカメラのレリーズ端子は2.5mmの3極ミニプラグで、シャッター、フォーカス、GNDの3端子があり、シャッター端子とGND端子を短絡するとシャッターが切られる仕組みです。

ではこんな回路で・・・

フォーカス回路も含めていますが自動でピントを合わせると時間がかかるので、マニュアルでピントを合わせておく事にします。 Duo256のGPIO端子の内、G15がシャッター、G14がフォーカスで、念のためにフォトカプラを経由にしました。

なお2.5mmのミニプラグが無かったので3.5mmへの変換ケーブルを急遽Amazonで購入。

そしてユニバーサル基板に搭載してハードは完成。

カメラは箱に入れ、内側をスプレー缶で黒に塗りました。Duo256本体は箱の裏側にテープで貼り付けています。

しかしこんなラズピコサイズのボード1枚で物体検出だの分類だのが出来てしまうというの、オドロキですね。。。

動作実験

2つのカメラを庭に向けて設置し、画角がほぼ一致する様に調整します。
そしてデジタル一眼レフはマニュアルでフォーカスを合わせておきました。

なおテスト用としてカップにも反応する様にしておいたので試してみます。
ちゃんとデジカメのシャッターが下りて撮影されましたね。

あとは猫が通るまで放置します。。。

結果

夕方の終了直前、お隣との塀の上を2匹で歩いている姿が撮れていました。
お隣が写っているままだとマズいのでぼかしを入れています。

翌日はカメラを下に向けて隣家が写らない角度に。。。
今回も一枚撮れていましたがマニュアルフォーカスをミスってピンボケになりました。

という事で・・・

最低限の状態で動いたという感じです。
でもやっぱりカメラ2台体制ではなくDuo256だけで完結したいですよね。。。
もうちょっとドキュメントを読んでみます。

参考

今回のプログラムはこれ→/data/nekocam.tar.gz

再コンパイルする場合は以下をインストールしておく必要があります。

これらのファイルが以下の配置にある前提でMakefileを作成しているので、異なる場合は修正が必要です。

~/milkv
  ├duo-examples
  ├cvitek-tdl-sdk-sg200x
  ├host-tools
  └myproj
   ├Makefile
   ├yolov5class.h
   └nekocam.c

Milk-V Duo256

昨年末のトラ技(2024年12月号)に載っていたMilk-V Duo256というマイコンボードが面白そうだったので衝動買いしました。動かしてみてハマった箇所もあったので覚え書き。

まずこんな箱に入ってきました。

本体。基板の色はランダムらしいですが届いたのはごく普通の基板色。
またピンヘッダが付属していそうな雰囲気ですが付いてませんでした。

こちらが開発ボード。本体基板を載せるとイーサーネット接続ができます。

そしてカメラ。フレキシブルケーブルが2本付属しているのは安心ですね。

動かしてみる。

トラ技の記事通りMicro-SDカードにシステムを書き込みました。
記事で分かりにくい部分は本家の説明ページを見ると良いです。

電源を入れる前にPCと接続しますが、基板に載っているUSB端子は良くあるUSB-Serial変換による接続ではありません。ここもトラ技記事に従って開発基板のシリアル端子に外付けUSB-Serial回路を接続しました。
写真のFRISKケースが外付けUSB-Serial回路で、中にFT-232RLが入っています。

※なお最新システムでは初期状態でUSB-NCMという仕組みが有効になっており、USBだけでも接続できる様になっています。下に記載の「ハマったところ」参照。

立ち上げると数秒でrootのプロンプトが出ました。

その後トラ技記事通りYOLO5の実行は問題なし。
そしてカメラとイーサネットケーブルを接続して顔認識を実行しようとした際、一瞬「camera-test.sh」がどこにあるんだろうと思いましたがパスが通してあったので、このまま実行すればOKでした。VLCで接続すると映像が表示され、顔を認識すると回りに四角枠が現れます。

ハマったところ

USB-NCM

最新システムだと初期状態でUSB-NCMが有効になっているので、PCとはUSBケーブル経由でTCP/IP接続できます。。。なのですが、なかなかうまくいかずハマりました。

まず開発ボードのUSB端子は電源入力だけなので本体ボード側のUSB端子にケーブルを挿す必要があります。
そしてWindowsのデバイスマネージャを見ながら本体にケーブルを挿しても「不明なUSBデバイス(デバイス記述子要求の失敗)」となって正しく認識されません。

分かったことは本体基板を開発ボードに載せているとごく稀にしか接続が成功せず、開発ボードは使わず本体基板だけの状態で接続すると成功する様になりました。

(この症状、ウチだけでしょうか?)


結局色々とイジる間はイーサーネットで接続するよりもUSBの方が便利なので開発基板無しで使っています。TCP/IPで接続するため、電源もSSHもVLCもUSBケーブル一本で済むのです。

rootパーティション拡張

32GBのSDカードを挿しているのにデフォルトではルートパーティションは752MBしか確保されておらず、残りの殆どが未使用状態になっていて、このままイジっていると直ぐに満杯になってしまいました。そこで本家のセットアップ説明に従いパーティションを拡張しました。
なお本家ページの説明ではパーティション番号3がルートパーティションでしたが、ウチのは2だったので読み替えて設定しました。
※説明通りにやれば既存のファイルは消えずにパーティションを拡張できています(でも責任は持てないです)。

という事で・・・

色々とイジくっています。

レーザー加工機Grbl(FluidNC)化 ~4~

また謎が発生

前回、CO2レーザーの出力を0にした時にもレーザーが漏れ出るという問題で、下図の47KΩを少し下げて対策したのでした。

この時、出力設定を17%程度にしたあたりからレーザーが出始める様になったので、もう少し調整して0%に近い所から出る様にしようと考えました。

前回の対策では47KΩを下げる為に220KΩを並列に接続した事で合成抵抗を38.7KΩにしていました。実はこの場合のざっくりした計算では5%程度からレーザーが出始めると見込んでいたのですが大きく違います。こうなるとカットアンドトライで並列抵抗を大きくしてみるしかありません。そこで510KΩとか1MΩを付けてみたのですが・・・出力開始点が少ししか下がってこないのです
なんか変です。そこで並列抵抗を外して元に戻したところ、これでも10%程度からしか出てきません

そもそも0%でもレーザーが出てしまうという問題だったのですが症状が消えてしまったのです。

なぜ?

やった事といえば電源をバラして下の写真の様に抵抗をハンダ付けしただけです。

この2点のハンダを溶かし直した事で何かが変わったのでしょうか?

そこで改造前の写真を丹念に拡大していくと・・・なんかこのハンダ付け怪しく見えませんか?

今となっては確かめる術がありませんが、ここが接続不良で数KΩ高くなっていたとしたら辻褄が合います。

本来47KΩのところが少し高めになり、そのため1IN+の電圧が僅かに下がります。するとアンプ1の出力が少し下がってレーザーをOFF出来なかったと。。。そこに抵抗を並列に付ける時にハンダを溶かし直したので接触が回復して本来の値に収まったと。。。

真相は分かりませんが現時点は元の抵抗値のままでレーザーをOFFにでき、出力開始点は10%程度になっており、多分これが本来の姿です。

うーん。何だったんだぁ?

レーザー加工機Grbl(FluidNC)化 ~3~

前回の続きです。
前回はレーザー加工機のコントローラーをLinuxCNCからFluidNCに変更したところ、ラスター描画が上手くいかないという状態でした。 LinuxCNCの時はレーザーパワーは固定し(ボリュームで手動設定)、出力のON/OFFのみスイッチングしていましたが、今回レーザーパワーをPWMで制御する方式に変更して写真の描画も目論んでいるのです。

ラスター描画の状態。

描画した結果が下の状態。縦線と三角形だけ描画したいのですが、絵が無い部分も焼けており、S0状態なのにレーザーが漏れ出ている様です。(S0は本来スピンドルの回転数を0にする命令ですが、ここではレーザーパワーを0にする意味となる)

ならばとS0の時にレーザー電源出力をOFFにする様「disable_with_s0」「true」に設定して同じGコードを実行したのが下の状態です。

こちらは往路と復路で位置が大きくずれています。

なおS0というのは下図レーザー電源のIN端子に入れる電圧を0Vにするという事で実際にはPWMにてDuty0%(常にL)を入れています。そして電源出力OFFとはK+、K-間を切断する事を意味します。

LasePS

まあ「disable_with_s0=true」で上手くいったとしても最小出力付近の制御が出来なくなるでしょうから、やはりS0時のレーザー漏れを無くすのが本来の道でしょう。

レーザーお漏らしの調査

なんでS0時にもレーザーが漏れ出てくるのか。まず疑ったのはPWM波形が綺麗なLになっていないんじゃないかという事。しかしオシロスコープで見たところはちゃんとLに見えます。でもLレベルが微妙に浮いていたりノイズが乗ってたりする可能性もありますよね。
そこでレーザー電源のIN端子をGNDに短絡して動作させてもやはり漏れ出ていました。ということでレーザー電源側の問題と思われます。

レーザー電源の調査

レーザー電源内部の問題っぽいですが20KV前後を出力する電源なので迂闊に触るのは危険です。

注意:ここから下はレーザー電源の蓋を開けていじくります。レーザー電源の内部はかなりの高電圧な部分があり危険です。これを参考にして同様の作業をされる場合には十分に注意してください。もし事故が起こってもこちらでは責任を負えません。

まずは情報収集から。ネット上で検索して同様な問題で困っている記事を探しましたが見当たりませんでした。
しかし「マーティの工房日誌」さんの所ではレーザー電源をバラして回路図まで描かれており、これが素晴らしく参考になります。
但し40WのCO2レーザー用という点は自分のと同じですが、中の基板は異なります。でも大体の構造は同じですね。

一応自分の電源についても見ながら、レーザーパワーの制御部分を回路図にしてみました。これには基板を裏と表から写真を撮り、下の様にPC上で裏面だけ反転表示にすれば配線を追いやすいのです。
なお部品面の配線は見えない部分もあり、実物を見ても分らない部分はマーティさんの資料に従いました。

制御ICはマーティさんの電源と同じTL494のSOP版で、周囲の回路もほぼ同じですね。

パワー制御の動作概略

TL494のデーターシートには下図の様なブロック図が掲載されています。
ざっくり言うとPWMコンパレータの出力がLになった時にレーザーが出ます。そしてPWMコンパレータは発振器のCT端子から来るのこぎり波とエラーアンプから来る信号を比較しています。

のこぎり波は反転入力なので、エラーアンプ信号よりものこぎり波が高い時にコンパレータ出力がになりレーザーが発射されます。
そしてデーターシートの記述によるとのこぎり波は0~3Vで変化しますが、図中に0.7Vが加えられているので0.7~3.7Vで変化する事になります。

図にするとこんな感じ。

今回はレーザーを全く出したくない時に少し出てしまうという問題なので、エラーアンプ出力が3.7Vよりも高くなっているべき所がどうなっているかを中心に見ていきます。

ではマーティさんの回路図と自分の実物を見比べながらエラーアンプ回りの要所のみ書き出したのが下の図です。

まず入力のPとINは両方共0Vの状態です。
エラーアンプは2個ありますが2側は使用していません(無効化するのに両入力とも0Vでいいのかという疑問はありますが動作しているので先に進みます)。
エラーアンプ1側はIN信号をゲイン1倍で反転増幅し、基準点は47Kと24Kの分割電圧となっています。
フォトカプラPC817も少しは電圧降下がある筈ですがデーターシートのグラフでは細かいところまで読み取れません。とりあえず0.1Vとしておきます。
するとIIN+は1.76VなのでINが0Vの時FBは3.52Vとなり、レーザーをOFFできる電圧3.7Vを超えていません
これが原因なのか???だとすれば経年劣化とかではなく自分以外の所でも同じ事が起こっていそうですが・・・

レーザー電源改造

とりあえず試してみましょう。それにはIIN+が現在1.76Vなのを1.85Vにしてやりたいです。その為には現在47KΩの抵抗を43KΩに交換すればよいのですが、手っ取り早くやるために手持ちの220KΩを並列に付けてみました。これだと合成抵抗38.7KΩでIIN+が1.97Vとなり、ちょっと上げ過ぎ感はありますがまずは試しです。

やってみたところ予想通りS0部分のレーザー漏れは無くなりました。

折角なので写真を描画してみます。(いつだかのHONDA-Jetの写真)
・・・中間色が全く出てませんね。

どれくらいのS値から出力が出るか調べていくと最大に対し17%程度からでした。もう少し抵抗値を詰めた方が良いかもしれませんがLaserWeb4の出力範囲を調整していくと・・・

結構写真っぽく描画できましたね。

そして・・・

抵抗値、どうしましょう?1~2%程度からレーザーが出る様に調整したいですが沼にハマりそうです。半固定抵抗になってれば良いのに。

またINへの入力は0~5VのPWMですがリニアに反応する範囲は3V幅という事になります。これ仕様なのかな?確かにボリュームで調整していた頃も70~80%付近から上は最大電流になってしまい変化しなかった様な(更には最小でもレーザーが出ていましたね)。
エラーアンプ1のゲインを下げて5V幅フルに反応する様にしてみたい気もします。。。

あと気になっているのは出力電流のリミッター的なフィードバックが1IN+に入っている様です(すみません、上の回路図では省略していますがマーティさんの回路図には載っており半固定抵抗DLで調整できる様です)。
この調整がずれてないかなというところを確認していませんでした。以前はほぼ20mAジャストが流れていたのでずれていたらDLを調整してみようと思います。

・・・という事でレーザー加工機のGRBL化はもう少し続きそうです。

レーザー加工機Grbl(FluidNC)化 ~2~

前回の投稿では「レーザー加工機のPCが立ち上がらなくなり、この機会に今までLinuxCNCで制御していたのをGRBLに変更しようと検討していたらPCが復活してしまった」件を書きました。
しかしGRBL化はその後も続けていて、途中色々とハマりながらも使える様になってきたのでその備忘録です。
なおGRBLといっても最近は32bitマイコン上で動作するものが多数リリースされているので、今回はESP32で動作するFluidNCを使う予定です。
※以下ではGRBLとFluidNCという単語は同じ意味で使っています。

まずは今までの制御回路を紹介

今までは古いPCにインストールしたLinuxCNCから、写真の基板にパラレルポート(プリンタポート)で接続していました。しかし今どきパラレルポートを備えたPCは見掛けないので、いつかはUSB化する必要があります。
なお「USB-パラレル変換ケーブル使えば?」と思われるかもしれませんが、これだとタイミングの問題があってダメなのです。

LaserCutterController

この基板は下の回路になっていて、左側の36ピンコネクタがパラレルポートです。
このパラレルポートにGRBL基板を繋いでやれば手っ取り早くできそうです。
なお変更点として、これまでレーザーのON/OFFはZ軸モーターの方向信号が下向きだったらON、上向きだったらOFFとし、レーザーパワーはレーザー電源にボリュームを接続した人力設定としていました(これだとCNCフライスで切削するGコードで済むのです)。
今後はGコードのM3,M4,M5命令でレーザーをON/OFFさせ、S値でパワーを決める様に変更しようと思います。

レーザーコントロール回路

FluidNC基板

FluidNCはESP32マイコン上で走るので下の様な回路を描きました。ESP32は先日3枚959円(送料無料)で買ったDevKitボードを載せることにします。
この図の36ピンパラレルコネクタを上図のパラレルコネクタに接続する訳です。
一応、水流センサーとドアオープンセンサーの端子も載せていますが、当面これらのセンサーは元の基板に接続した状態で使う予定です。

そして作った基板がこれ。
コネクタ付きフラットケーブル(45cm)はいつだったか10本入りのジャンクを買ったもの。これまで電線取り用途にしか使っていませんでしたが、今回はコネクタも含めて使用します。

こんな感じで元基板とGRBL基板とを接続しました。

元の基板を少し改造

なおESP32は3.3Vで動作しますが元基板R1~4のプルアップ電源は5Vです。抵抗が100KΩと大きいのでESP32の保護ダイオードが効いて3.3V+α程度に収まる事を期待していましたが、やってみたら5V近くまで上がっていました。たぶん壊す事はないと思いますが定格を超えているので念のため対策します。
これにはプルアップ電源をパラレルコネクタの18ピンに接続し、GRBL基板から3.3Vを貰う様に改造しました。

FluidNCをインストール

下記リンクページに書いてある通りにダウンロードしてバッチファイルを実行すればインストールできました。
http://wiki.fluidnc.com/en/installation
なお書き込むバイナリには3種類あり、「無線LANを使う」「Bluetoothを使う」「無線は全く使わない」に分かれていて、私は無線LAN版を書き込みました。

FluidNCの設定

インストールが終わったら設定です。
FluidNCの設定にはコンフィグファイルに書いて読み込ませる項目と、(WiFi設定の様に)コンフィグファイルに含まれない項目があります。
モーター制御やホーミングの情報設定はコンフィグファイルをconfig.yamlのファイル名で作成してWebインストーラーからアップロードします。
なおWebインストーラーは下の画面から入ります。Connctを押してCOM*番号を選び・・・

そして下の画面が出たら「File brouwer」を押してアップロードします・・・

実際のコンフィグファイルは夫々のマシン毎に違うでしょうけど、ウチのを参考に載せておきます。
config.yaml

なお無線LANの設定はコンフィグファイルには含まれてなくて、下図の様に直接Webインストーラーから設定します。

座標位置が表示されない問題対策

また実際に動作させてみたらレーザーヘッドの座標位置がLaserWeb4に表示されませんでした。どうやらFluidNCがレポートする情報がLaserWEB4が想定しているものと違うらしく、WebインストーラーのTerminalから次のコマンドで設定を変更する事で表示される様になりました。

$Report/Status=2

LaserWeb4をインストール

PC側のソフトはLaserWeb4を使う事にします。これはPCからGRBL基板にGコードを送るので「センダーソフト」と言われるものです。
またこれまでGコードはNCVCで作っていましたが、LaserWeb4はGコード生成もやってくれるので作業の手間が省けることを期待しています。
更にLaserWeb4とFluidNCの組み合わせなら、PC⇔ESP32間を無線LANで接続できるので、今まで使っていたLinuxマシンを使わず、少し離れたメインPCから接続できてとっても便利になる予感です。
LaserWeb4のインストールはインストーラーをダウンロードページから取ってきて実行するだけでした。

LaserWeb4の設定

まずは起動します。

ウィンドウ左側の「Settings」ボタンを押すと下図の様に幾つかのカテゴリに分かれたメニューが現れます。この中で今回書き換えたのはMachine ProfileMachineGcodeの3カ所です。

それぞれ次の様に設定しました。

〇Machine Profile
 Machine Id:HOIHOI-Laser ←装置名

〇Machine
MACHINE WIDTH:435mm ←X方向の最大値
MACHINE HEIGHT:350mm ←Y方向の最大値

〇Gcode
 GCODE END:
  M5 ; Disable Laser/Spindle
  G0Z1.0
  G0X0Y0
  G30
 TOOL ON:
  M4
 TOOL OFF:
  M5
 PWM MAX S VALUE:
  255

LaserWeb4とFluidNCの接続

ここまで来たらLaserWeb4とFluidNCを接続します。
といってもインストールの時点でPC-FluidNC間にはUSBケーブルを接続していましたよね。もしWebインストーラーとFluidNCが繋がったままなら切っておきます。
このままUSBで接続するにはLaserWeb4のCommsメニューを開きます。USB/SERIAL PORTのところは自分の環境のCOM*を選択して「Connect」ボタンを押すと・・・

右下に「接続したよ」っぽいメッセージが出て繋がった事が分かります。

でも折角なので無線LANで接続してみます。これには「MACHINE CONNECTION」をTelnetに変更してIPアドレスを設定しConnectを押します。

これで基本的には接続OKなのですが、我が家のレーザー加工機はWiFiアクセスポイントから少し距離があり、GRBL基板の前に人が経つと接続が切れたりしました。
これではマズいので工作室にWiFiアクセスポイントを増設する事にします。
という事で2ndSTREETに行って買ってきました(税込¥1210-)。これをアクセスポイントにすると安定して接続できる様になりました。

ベクターカットしてみる。

その他の色々とハマった部分は省略してベクターカットの実行です。ここからは順を追って・・・

まずjw-cadで下の様なテスト用の図を描きました。従来もそうでしたがカットする線と補助線とはレイヤーを分けておきます。
なおNCVCの場合だとレイヤー名に決まり(カットするレイヤーは”CAM01″等)がありましたがLaserWeb4の場合は後でカットするレイヤーを選択するので特に必要ありません(分かりやすいというメリットはあるけど)。
そしてdxf形式で保存し、念のためjww形式でも保存しておきます。

LaserWeb4の画面に戻り、Filesメニューから「Add Document」ボタンを押すとファイルセレクションが開くので、先ほどのdxfファイルを選択します。

この時点で画面上に図形が見える場合もありますが表示範囲を超えていて見えない場合もあります。そこでファイル名の部分(図では「テストカット.dxf」)をクリックすると、何やら数値を入れる小窓が開きます。ここでX-Min、Y-Minが図形を置く最小座標値なので5mm程度の小さめの値を入れると原点に近い場所に図形が移動します。
なお表示がシマシマ線なのは現在選択中の印です。

そしてカットしたいレイヤーだけを選択する為、ファイル名左側の「+」印を押すとファイルに含まれているレイヤーがそれぞれ表示されます。この中からカットしたいレイヤーをマウスでドラッグし、少し下にある「Drag document(s) here to add」にドロップしてやるとそのレイヤーがカット対象となり下に設定画面が開きます。

ここでレーザーパワーやカットレートを入れて・・・

「Generate」ボタンを押すとGコードを生成します。生成したコードを確認したい場合は目玉マークをクリックすると表示されます。

これで準備完了。
Control画面に戻って「Home all」を実行後、「run job」を押すと加工機が動作し・・

カット完了です。
だいぶお手軽に作業できる様になりましたね。

ESP32 Devkit基板への電源供給について

ここまでESP32基板へはUSBケーブルから給電していました。無線LAN化後も電源供給だけUSB電源を使っても良いのですが、スッキリさせるために加工機側から5Vを供給する端子を追加しました。

次、ラスター描画をしてみる。

みら太氏のブログによるとLaserWeb4によるラスター描画は動作が遅い上に上手く描画できなくてLightBurnに移行したという事が書かれています。LigutBurnはメチャ良いらしいですが有料ソフトなので、どちらにしても一旦LaserWeb4を試してから検討する事にします。我が家の用途では99%がベクターカットですしね。。。

という事で、とりあえずLaserWeb4でラスター描画をやってみました・・・が、案の定上手くいきません。

こういうテストパターンを描画したのですが・・・

結果がこれ。
レーザーOFFのところでも弱く漏れ出ている感じです。

レーザーの強弱はレーザー電源にPWMを入れる事で制御しており、この辺りが上手くいっていないのかも。。。

ならばとFluidNCの設定を「disable_with_s0=true」にしてみました。この設定をtrueにするとGコードの命令でS値を0にした際、(M5命令同様に)出力も止めるという意味になります。
なんか言葉では説明し辛いですね。下図のレーザー電源図でいうとINに入れるPWMを0に設定した時にK端子も一緒にOFFになるので完全にレーザーが出なくなる筈です。

LasePS
レーザー電源

この設定で同じGコードを実行したらこの様になりました。

不要なお漏らしは消えていますが、往路と復路でレーザー発射点がずれているっぽいです。上記みら太氏のブログでも往復でずれると言われているのはこの症状かもしれません。

この後色々とイジって現在は何とかなったのですが、そのあたりは次の投稿で・・・

レーザー加工機の制御PCが壊れてGrblへの変更を検討した件

先日スーパーカブのガスケットを切り出そうと思い、レーザー加工機を立上げようとしたらPCがOSを読み込めませんでした。 BIOSを開いてもハードディスクを認識していないのです。

操作パネルが無くバラバラ
正常だった頃の加工機

これはマズいです。レーザー加工機なしの生活は考えられません。
このPCはかなり古いPentium4時代のマザーボードを未だに使っており、LinuxCNCをインストールして加工機を制御していました。なので加工機との接続も化石の様なプリンターポートなんですよね。
一応LinuxCNCの設定ファイルはバックアップしてあるのでハードディスクを交換して入れ直せば良いのですが、そろそろUSBの時代を迎えたいと思いGRBLへの変更を検討しました。

GRBL検討

GRBLはArduinoUNOでCNC類を制御するオープンソースプロジェクトで、かなり前の投稿でも検討していました。→https://www.hoihoido.com/blog/LaserCutter-18/


しかしこの時は非常停止ボタンや水流センサーを接続する異常検出系の端子が足りなくてどうしようか考えている内に放置してしまったのです。


今回改めて調べるとGrblでもArduinoUNOを使うのはレガシーで、最近は色々な32bitマイコン上で動作させるのが普通になっている様です。
この中からESP32で動作させるFluidNCというのが良さそうです。というのも先日Aliexpressの安売りでESP32ボードを3枚959円で購入しているのです。

激安のESP32ボード。1枚あたり320円。
ちゃんと技適マークがついてるけどモジュールに書いてある文字が少ない気がする。
でも動作はしている。

このESP32ボードにFluidNCを入れ、その出力を現行制御基板のパラレル入力に入れてやれば安上がりかと考えています。

LaserCutterController
現行の制御基板

あれ、PC動いた。

という感じでFluidNCの検討を始めたのですが、ふと気になり壊れたPCのBIOS設定を確認したらS-ATAを使用しない設定になっていました。このマザーボードはS-ATA規格の出始め時期だったので(こんな基板いつまで使うねん!) S-ATAを使うかどうかという設定があって初期値は「使わない」だったのです。で、これを「使う」に変更したらあっさり立ち上がりました。時計は正常に動作していたので疑っていなかったのですが、翌日CMOSチェックサムエラーも出だしたのでボタン電池(CR2032)の電圧を見たら1.5Vでした。一瞬「電圧あるやん」と思ったけど、よく考えると3Vが正常ですね。半分しかありません。

という事でボタン電池を交換して復活したのですが、GRBL化の検討はこのまま進めたいと思います。また放置になるかもしれませんが。。。

ハンズマン ガラクタ市2024秋

恒例のハンズマン ガラクタ市が今日(2024年10月17日)から始まりました。
昨年は11月23日開始だったので油断してしまい、今朝の新聞チラシで開催を知りました。
なので朝一番には行けず、仕事が終わって夕方からの参戦です。

菊陽店に到着。
さっきまで大雨でしたが今は小降りになっています。

テーブル上のガラクタ市商品。この辺りからワクワクしてきます。

ドリルの刃が多数あり全て98円。1mmのは良く使うので何本か買っておきます。
プリント基板用に0.8mmがあれば嬉しいのですが見当たらず、代わりに0.3mmとか0.5mmがあり、使うかどうか分かりませんが買っておきます。

この辺からは電気関係。

3階からの風景。

という事で買ったもの

まず全体写真・・・

以下、目ぼしい物を紹介します。

先ほど書いた様にドリルの刃が全て98円です。

17mmのTレンチが30円

米式、英式、仏式対応の空気入れ979円。
(良くある変換アダプタ方式ではなく、仏式もそのまま接続できるのです)

Webカメラが398円(200万画素)

4色ボールペン3本で30円 (1本あたり10円!)

以上全部で2719円の買い物でした。
ハンズマンガラクタ市は今日から10月21日(月)迄です。
何日か後にも新たな商品が出たりするのでマメに覗いてみたいと思います。

LEDシーリングライトの常夜灯を修理

常夜灯(寝るとき点けておくオレンジ色の明かり)が点かなくなったLEDシーリングライトを修理しました。
全く点かない訳ではなく、最初は点くのに数秒後チラチラと点滅を始め、やがて消えてしまうのです。その後はOFF/ONを繰り返しても点かず、暫く放置すればまた最初だけは点く様になります。
何となくですが、冷えていると点いて温まると消えてしまう様に感じます(LEDってこんな壊れ方するのかな?)。

今回対象の照明とはこういうヤツです。NEC製HLDZE1462。

まず準備として机の上で電源を入れる為にこういうのを作りました。

そして天井から外してきて内部の金属カバーも外すと基板が見えてきました。

常夜灯はこの四角い部分。赤外線リモコン受講部と一緒になっています。

この四角いカバーは爪を押さえると外れます。そして裏から基板を固定しているネジ2本を外すと緑色の赤外線基板と白色の常夜灯基板の2枚が出てきました。
用途毎に基板がスッパリ分かれていますね。

常夜灯基板は片面配線のシンプルな基板です。

部品を載せていないパターンを無視すると、下図の様なLEDと10KΩの抵抗が並列に繋がっているだけ。
でも10KΩは何の為でしょう?最初は電流制限の直列抵抗かと思いましたが並列なんですよね。


黒/白線から基板に電流を流しても点きませんでした。LED自体が壊れているのか?
しかし基板からLEDを外し、リードをはんだ付けして通電すると・・・点きますね。

LED自体は生きているっぽいです。でもさっき黒/白線から通電しても点かなかった理由がわかりません。LEDのハンダ付け不良?

念のため本体側の確認として適当なLEDと10KΩ抵抗を並列にしてシーリングライトに接続してみました。すると正常に点灯します。
なおここのコネクタはTINYドローンでお馴染みのPHコネクタでした。

では問題のLEDに戻り、リード線を経由して基板に繋いでみます・・・点きますね。

では元通り基板に付け直してみます。

すると正常に点きました。やっぱりハンダ付け不良だったのかな?

では元に戻します。天井に取り付けて一安心・・・

・・と思ったら30分程使っているとまた点滅を始め、その内消えてしまいました。
直っていないのか・・・

もう一度LEDを外してリード線をはんだ付けしました。
そしてリード線を曲げようとして少し力を加えたとたん・・・真っ二つ。

LEDにクラックが入って割れかけていたため不安定だったのだと思います。

こうなると交換しかありません。手持ちの中から外形が近いLEDを持ってきました。

実は割れてしまう前に並べて撮影していました。
左がシーリングライトに入っていた物。右が手持ちのLED。手持ちの方が僅かに外形が大きいですが、頑張れば取り付けられそうです。なお発光色はどちらも似ていて電球っぽい色です。

新しいLEDを基板に取り付けました。動作はOKですね。
茶色になったフラックスはこの後ふき取りました。

再び天井に取り付けて数時間点灯し続けましたが今のところ消えずに点いています。

という事で、LEDが壊れかけていたというのが結論です。

電子負荷 PLZ72W ~その2~

ジャンクで貰った電子負荷のPLZ72W。先日の投稿でA設定側が動作しない旨を書きました
とりあえずはB側が使えれば望みの用途には使えるのですが、気になるので再びケースを開けてイジっているといつの間にか直ってしまいました

たぶんですが、電流値を決める多回転ボリュームが狭い所にあるので、どこかに接触していたのではないかと思います。電源スイッチを修理する時に前面パネルと共にボリュームも外したので、その時にやらかしたのかと。

ボリュームの取り付け角度によっては周囲の部品に当たるのです。
念のため、もう一度ボリュームを外して安心な角度で取り付け直しました。

A/B両方が正常になると電子負荷内部の発振器で負荷電流を交互に切替える事ができるので電源の追従性等も確認できます。

ためしに10V電源から5Ω抵抗を経由して1A⇔0.1Aを切替えた電圧を測定してみました。

予定通り9.5Vと5Vを交互に繰り返す波形が出てきます。
なおA/Bの保持時間を右下のツマミで変更できるので周波数やデューティーを設定できます。

ばっちりですね。次に電源を作るときには活用しようと思います。