2023年2月1日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 自作のライブラリをincludeしてコンパイルするには少し面倒があります。
 例えば、
 製作するアプリケーションファイル test_inkey
 メインのソースファイル test_inkey.c
 ライブラリのソースファイル std_inkey.c
 とした場合、
$ gcc -Wall -lm -o test_inkey -I ./ test_inkey.c std_inkey.c
 などとコンソールからコマンドを打たないといけません。
 Cのソースファイルが一つならVSCodeからショートカットで一発なんですけどね。

 この場合、makefileを作っておけばmakeコマンドで一発です。
 次がわかりやすい。
 Makefile の書き方 (C 言語)
 makeコマンドの使い方も丁寧に説明してくれています。

#C言語
Icon of admin
 Art-Netの受信に成功しました。
 先達の情報をいくつか合成しましたが、思った以上に簡単でした。
 ネットワークインターフェースの指定も出来ました。
 一安心ですが、次は送信しないといけません。
 デコード/エンコードをせずに受信値をリレーするだけですが、これが成功しないようでは受信値を加工する努力をしても意味がありません。

#[Art-Net]
Icon of admin
 Art-Netの送信にも成功しました。
 受信値を転送するだけですが、Art-Netデコーダから正常と思われる値が出力されています。
 今日は終わりにしますが、大きな課題がクリア出来て大満足です。
 ただ、8ユニバースを出力しているdot2が一杯いっぱいの様子。発熱も凄いし画面もコマ送りです。

 ちなみにですが、recvfrom()の4番目のパラメータを「MSG_DONTWAIT」にすると受信待ちしません。先達の例では待ちアリの「0」を定義してioctl()に待ち無し(ノンブロッキング)を設定していることが多いのですが、「MSG_DONTWAIT」を使った方がストレスが無い感じ。
 で、気付いたのですが、C言語は速い。速いが故の対策が必要になる始末。受送信テストでは終了のためのキー入力やタイムアウトを入れるのが面倒だったのでfor文による一定回数の繰り返しで試したのですが、受信待ちを無くした後はPythonでの実験の際に使った回数では一瞬で終わってしまいます。プログラムが間違っているのかと思う程でした。てことは、あまりにも無意味な回数recvfrom()を呼んでいることになりますので、受信が無い場合は100~500usecくらい待ちを入れた方がいいみたいです。バッファを読みに行っているだけなので気にしなくていいって話もありますが、ANSIエスケープシーケンスを用いた画面表示も適度な待ちを入れないと画面がフリッカーを起こす程です。数か月かかりましたが、C言語を勉強して良かったと思います。遅いのを対策するのは大変ですが、速いのを抑え込むのは比較的簡単ですからね。
 ここまで速いとマルチプロセスを使わなくてもいいのではないか?って気持ちも芽生えます。使った方が速さ以外に都合が良いこともあるので使いますケド。

 基本的な受送信が確認出来ましたので、関数化しつつArt-Net(正しくはArt-DMX)のデコード/エンコードも書きましょう。

#[Art-Net] #C言語

2023年2月2日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 Art-Netのデコード/エンコードも出来ました。受信した1配列のバイナリデータを分類して構造体に取り込むのがデコード、項目別の構造体から送信用のバイナリデータに変換するのがエンコードです。
 実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
 topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを1つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
 今のところ製作は順調です。3月末までに1日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。

#[Art-Net] #C言語

2023年2月3日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 Art-Netの入口と出口は出来ましたので機能を組みます。C言語に替えた為に処理能力に余裕が出て複座なプロセス処理を多用しなくても良さそうですが、そもそもの処理をどうするか吟味しないといけません。
 搭載予定の機能は、ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)です。スタックフェーダー機能はミキサー機能に含まれます。
 さて、どうしようかな。

#[Art-Net] #C言語

2023年2月4日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 諸々イイ感じに書き進められていますが、処理タイミングという一見簡単そうで実は面倒なことに取り組んでいます。
 先日作ったキー入力処理とArt-Net処理を混ぜているのですが、それぞれに合った時間間隔で実行しないといけません。キー入力は100msec、Art-Netは100usecです。求められる処理間隔が3桁も違うので同じ時間間隔ではどちらかが破綻します。それぞれをそれぞれの時間間隔で実行するにはどうするか。他の処理を止めること無く処理を続けるにはどうするか。
 基本は前回処理の日時と現在日時の差から経過時間を評価する方法です。一定の時間間隔で処理を呼ぶのではなく、呼ばれても経過時間が要求未満なら何もしない方法です。signal()を用いて一定時間間隔で関数を実行させるのが王道でしょうが、singal()ですと終わっているべき他処理のチェックが必要になるのでどっちもどっちです。私の書き方が悪いのかもしれませんが、signal()を多用するとバグの原因になりやすいようです。
 なんにしても前回処理からの経過時間で対策してみます。そのために必要なのは現在日時の取得です。POSIX時間と呼ばれる1970年1月1日0時0分0秒からの経過秒数を取得出来るのでこれを用います。50マイクロ秒くらいの分解能が欲しいので秒単位では不足しますが、精度はともかく1ナノ秒単位で値を得られますから十分です。
 下記はその値を取得するテストプログラムです。
 秒とナノ秒が別々の変数で得られるので、評価を簡単にするためにひとまとめにします。ただし、int型は4バイト長(OSが32bitの場合)のためデータ長が不足しますので、8バイト長(OSが32bitの場合)の unsigned long long int型を用います。2038年問題はとりあえず気にしない。。。

Raspberry Pi 4B / Rasbian11_32bit(blueseye) / コンパイラ:OS標準gcc
#include <stdio.h>
#include <time.h>

int main( int argc, char *argv[] ) {
  struct timespec now ;
  unsigned long long int now_nsec ;
  // 現在POSIX時を取得
  clock_gettime( CLOCK_REALTIME, &now ) ;            // 現在POSIX時間値を取得
  now_nsec = ( unsigned long long int )now.tv_sec * 1e9     // unsigned long long int型(8バイト長int)変数に
        + now.tv_nsec ;                   // 取得値をひとまとめにする(nsec)
  // 確認表示
  printf( "%11ld.%09ld sec.\n", now.tv_sec, now.tv_nsec ) ;   // 取得値を表示
  printf( "%21lld nsec.\n", now_nsec ) ;             // ひとまとめにした数値を表示
  // 終了
  return 0 ;
}

※ このブログシステムでは#や[が機能文字扱いなので、上記ではこれらを全角文字で書いています。空白も全角です。
◆ 参考
 時間情報の取得方法と扱い方


 取得に必要なのは「// 現在POSIX時を取得」以下の2行(表記は3行)です。
 実際の処理では、取得した秒とナノ秒を合わせた数値がnow_nsec入りますので現在日時値とし、同じ方法で前回の処理で取得した値との差で経過時間を評価します。単位がnsecなら1秒は1000000000(1e9)ですから、100msecは100000000(1e8)、100usecは100000(1e5)です。良い意味で処理が速いC言語では多用すべき手法です。
 関数化・ライブラリ化するとソースは美しいですが、2行で出来ることなので都度の直書きでもいいかなと。将来、2038年問題に対策しやすくしておくならライブラリ化しといた方がいいけど。
 PICのアセンブラでも近いことをしていますが、それがPICで様々なことを実現出来ている要因だったりします。処理タイミングの管理はとても重要です。

#C言語

2023年2月5日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 各所の処理タイミングで難儀しましたが、第1フェーズと呼んでもいい段階は終わりました。
 まとまったのは次の通り。
1)Art-Netを受信してデコード。
2)エンコードして送信。
3)受信値を表示。
4)カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
 この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
 スッキリした画面に値がキレイに表示されると気持ち良いです。

 ちなみに、画面表示を除く主処理1フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
 今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。

 次はデータ処理の本丸です。
 Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。

追記
 処理タイミングを調整したところ1フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
 不思議なのは、受信している8ユニバース中、0ユニバースに比べ7ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは1フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。

#[Art-Net]
Icon of admin
 オレメモ

 ANSIエスケープシーケンスにおいてカーソルの表示/非表示を定義。
RaspberryPi 4B / Rasbian11_32bit / コンパイラ:OS標準gcc
\e[?25h カーソルの表示
\e[?25l カーソルの非表示


 相変わらずの不思議な呪文。

#C言語

2023年2月6日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 本業もやらねばなりませんがArtNet-Engineも進めたい。
 ArtNet-Engineの課題はデータ処理の構成です。

 まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
 送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
 フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
 内部的には8ユニバースのパッチを考えていますが卓も8台想定します。64ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
 当面は送信元の仕分けと64ユニバースを8ユニバースにマージする処理を書きます。

 処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
 Pythonとは違い、for文が速いC言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。C言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。

#[Art-Net] #C言語
Icon of admin
 本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。

 ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、8ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、8ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。

 現時点での1フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん?。
 作りたい物にはなりそうですが、8ユニバース8卓(64ユニバース入力)は厳しい気がします。これに対応するには1フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は8台ですが、同時に使える(HTPミックスの対象となる)のを3-4台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは40ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
 どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。

 ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。

追記
 調整したところ、1ユニバース受信する1フェーズが平均30usec、例外値が200usec程度になりました。
 同時に8卓使っても1本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
 送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。

#[Art-Net] #C言語

2023年2月7日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 ArtNet-Engineの入口出口キー操作は触るたびに問題点が見えてきます。なかなか次に進めません。
 次の課題は受信スタックです。これは得たデータをレーンと呼ぶ内部的な経路と送信元毎に仕分けしたモノです。8レーン8送信元、64ユニバースの一時保存です。一見データ量が多いようですが32kBです。映像画像に比べたらわずかな量です。
 受信毎に本処理まですればいい気もしますが、送信元から送られるデータは時間的に一定ではありませんので、受信の都度本処理までするとややこしくて重くなるのです。
 ならば、一定の規則で受信データを整頓し、送信元×レーン毎の入れ子に最新値という形で一時保存してから本処理を行えばシンプルな処理になります。
 こんなややこしいことをしてもDMX規格の最大速の1フレーム程度にレイテンシーを抑えようとしています。
 もちろんタイムアウトも必要です。DMXはデータが1秒間更新されなければ送信が無くなったと判断する規格ですから受信日時を見て判断します。これは優先度が低い処理ですから優先度が高い処理が実行されない空き時間を用います。極端な話、タイムアウトは1秒が基本でも5秒かかったところで実用上の問題は無いと考えます。そんなにかかることは無いと思いますが、2秒くらいで処理されれば実用だと思います。それ以前にDMXのタイムアウトが1秒ってことを知る人が少ないのですから気にしない。

#[Art-Net]
Icon of admin
 RaspberryPi4Bが正価で入手出来たと先日書きました。国内はまだの様ですが、中国からRaspberryPiCM4も正価で入手出来ました。
 CM4は組込み用途に特化し過ぎているために単体では何も出来ませんが、用途に合わせてインターフェースボードを作ればコンパクトでスッキリしたハードウェアを構成出来ます。
 いずれオリジナルのインターフェースを作ってみたいと思っていますが、とりあえずはEtherNetが2口付いた既製品と共にCM4をオーダー。
 ArtNet-PatchはCM4を用いて作りたいのです。プログラミングには4Bを使っていますが、製品にするにはちょっと違うので。

#RaspberryPi #[Art-Net]
Icon of admin
 コレ、欲しいかも。

 公道は走れませんけどね。

#雑談
Icon of admin
 そういや中華電機のムービングが故障しました。
 調光以外、起動後の初期化は正常にするけど卓の信号を受け付けない。画面やキー操作は正常。
 製品によりますが、ムービングライトは調光、PAN/TILT、その他の機能が別々の脳味噌で制御されていることが多いようです。タコみたいですね。
 内部を見ますと、DMXを受信している基板から調光ドライバにPWM信号が出ていて、PAN/TILTとその他の機能の脳味噌に向けて1本のRS485の信号が出ています。
 起動後の初期化が正常に出来て一部の機能だけ卓から操作が出来ないとなればRS485信号がPAN/TILTとその他の機能の脳味噌に届いていないとしか思えません。
 回転軸を通っているケーブルが断線するのはよくあることですが末端まで正常に導通しています。受信側の脳味噌基板は3枚ですが、初期化動作が正常なのに3枚とも壊れているとは考えにくい。
 DMXを受信して中向けのRS485を出している基板が怪しいとなるのですが、この基板上のRS485ドライバICをテスターで当たるとおかしい。3.3v仕様のSN75176互換品みたいですが、SN75176の故障でありがちな症状を示しています。SN75176は静電気にとても弱いので珍しいことではありませんケドね。
 このICを交換してみようと思いますが、レア品ではないものの日本国内では1000個単位でしか手に入らない製品なので中華電機に発注。2/15着ですからしばらく待ちです。

#照明器具 #電子工作

2023年2月10日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 車で20分くらいのところに水族館があります。
 知り合いの職員さんに呼ばれて打ち合わせに行ったのですが、大きな水槽に「イワシ」が群舞。
 職人が磨き込んだ銀箔のごとき魚体に思わず、「美味そう!!」と口から零れる。
 「・・・やっちまった!」と焦るも、水族館さんにとっては嬉しい誉め言葉だそうな。
 飼育担当の方と仲良くなりました。

#雑談

2023年2月12日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。

 ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
 ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
 罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
 不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ?という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。

 ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
 試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。

#C言語 #RaspberryPi

2023年2月14日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 ANSIエスケープシーケンスによるテキスト画面表示はやりたいことのやり方が見えてきました。先にも書いた通り、ウィンドウマネージャに近い考え方で関数ライブラリにまとめる方針です。
 ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
 平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
 ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。

#[Art-Net] #C言語
Icon of admin
 Art-Net製品はほぼ趣味で開発しているのでいいですが、DoctorMXで有名なクワテックさんのラインナップは素晴らしいです。
 是非ゴングインターナショナルさんのサイトからご覧になって頂きたいですが、間違いなく世界レベルの製品ばかりです。業界内には国産のDMX関連製品を正しく評価していない気配があるように思いますが、DMX関連品の導入をお考えなら海外製品の前にクワテック製品を検討することをお勧めします。リクエストすると機能を追加してくれたりしますしね。
 最近多くなったライトアップに於いても、ショーコントローラーValenciaの導入を検討しています。半仮設用途に向いたDMXも扱えるマルチメディアシーケンサーは他に無いと言ってもよく、なんと言っても特定の日、特定の曜日でショーの実施を設定できるのは強味です。ダスライトの上位機種にも同様のカレンダー機能はありますが、そもそも明かり作りのツールとして個人的には嫌いです。
 余談ですが間違っても案件ステマではありません。ゴングさんから購入することは少なくありませんが、クワテックさん程の開発力があったらなぁ~と羨望の気持ちでカタログを眺めているだけですwww

#照明器具
Icon of admin
 故障した中華電機のムービングライトは回復しました。
 予想通りRS485のトランシーバーICがダメだったようです。
 ただ、治ったのはいいですが、そもそもナゼ壊れたのか。
 SN75176系が静電気に弱いのは事実ですが、基板間の通信ですから外部配線にさらされることはありませんし、同様のICを使っている受け側は壊れていいませんので、静電気が原因だとしてもどこから回り込んでナゼこれだけなのか。同じ基板に搭載されている他のICは壊れていませんので、起動時の瞬間的な電圧異常が原因だったとしてもナゼこのICだけなのか。他のICはサージ保護が施されているのかもしれませんけれど。
 原因不明なので再発の可能性は十分にあります。他の機体が同様の故障を起こすかもしれません。
 RS485トランシーバーICは10個単位の販売でしたので予備はあります。しばらく様子見です。

追記
 RS485トランシーバーICはSN75176互換の3.3vSOP-8パッケージの品なら使えそうです。今回は全く同じモノを中華電機から仕入れましたが、秋月さんでも互換品が手に入ります。
 静電気にも過電圧にも強いLT1785の姉妹品に3.3vのSOP-8パッケージの物があればいいのですけどね。
 実験で電子ライターの火花を与えたことがありますが、SN75176は即死、LT1785は損傷しませんでした。

追伸2
 LT1785と同等の耐久性を持つ定格電圧3.0~5.5v品がありました。S8パッケージのLTC2862-2(max250kbps)です。
 過電圧耐性±60v、EMI(静電気耐性)1.5kvです。壊そうとしても簡単には壊せないかも。姉妹品のLTC2862-1は高スペックで20Mbpsまで対応しますがオーバースペックです。
 パッケージはS8とありますがSOP-8と同等の様です。
 ネット検索では国内小売りにもAliExpressにも見当たりません。入手性に難ありです。

#照明器具 #電子工作

2023年2月15日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 別な中華電機のムービングを修理しました。
 先日のはプロファイル系で明るさも芸もある中規模の機体ですが、今日のはPAR球1個と同程度の価格でお茶濁しとして使っている小型ビームライトです。
 MacAura1台の費用で30台以上買えますので使い方によっては費用対効果が高いのです。私は12台とか16台をエフェクトエンジン頼りでグループ使いしますが、思った以上にボリューム感のある照明が作れます。Auraは素晴らしい機体ですが1台で何が出来る?って話です。
 もちろん、Auraに比べたら極悪に精度が悪く光が貧相で、細いビームをブン回すしか能がありませんが、往年の応用工学スピナーが向きと色を制御出来ると思えば悪くありません。

 主な故障は4色のLEDのウチ1色が点かないというものです。
 基板を当たりますと点かない物はドライバICのハンダ付けが甘いようで、ハンダをし直すと回復するケースが大半です。中華電機がどうのではなく、価格相応といったところでしょうか。
 ハンダをし直しても治らない物はセンシング抵抗を着け直すと治ります。LEDに流れる電流を検出する回路の抵抗ですが過熱で抵抗値が狂うようです。この抵抗は1wクラスの様ですが3wに交換すると症状が出なくなるようです。中華電機の器具は設計に余裕がないのかこういった故障はよくあります。
 他には電源モジュールのスイッチングトランジスタが飛ぶケースです。これも設計がギリギリのようで、元のトランジスタよりも大きな定格を持つトランジスタに交換すると落ち着きます。電源の入力部の保護回路がダメな物もありましたが、バリスタを交換して落ち着きました。作った側は200v環境で開発しているためか、中華電機の製品を100vで使うとこんなこともあるのでしょう。
 日本国内の感覚では無償即対応の不良ですが、相手が中華ですし価格も価格ですから自力でナンボです。対策すれば使えるのですから、大陸的な感覚で扱いましょう。中華電機の照明器具は半完成のキットなんですよ。内部を探ってエラーを見つけて直すのも趣味的には楽しいしwww

 ですが、ハンダが甘い基板が多数見つかったので全数チェックしなければなりません。これがアベレージかもしれませんので。。。
 未チェック品が30台近くあるので、全ての基板をチェックして動作もチェックするにはそれなりの手間と時間がかかります。

#照明器具 #電子工作

2023年2月16日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 中華電機の小型ムービングライトで現場に出ていないのをチェックしましたが1台が変。
 主要部品のハンダを当て直して抵抗を替えると点くっちゃ点くのですが、しばらく休ませて再起動すると点かなかったりします。叩くと点いたりするので始末が悪い。必ずしも点かないワケではないので原因が絞れません。
 基板を外して裏側のパターンやハンダを見ても不審な点は見当たらないのですが、この際関係してそうな配線のハンダをすべて当て直してみました。
 すると、平滑コイルを着けるハンダからブクブク泡が出てきます。見た目は着いているのですが、天ぷらハンダ(ハンダの中に気泡が入っている状態)の一例です。気泡が入っているため、テスターで導通しても電流が多いと機能しなかったりします。コイルの導線のエナメル被覆がキチンと剥かれていない感じもしますけどね。
 放熱板が電源端子になっているスイッチングICは基板のパターンと放熱板の間からフラックスの泡が出てきます。これはハンダのフラックで着いているだけでハンダで着いていない可能性が高い症状です。一見動いても、過熱してくるとフラックスの気泡が膨らみ隙間を広げて接点が甘くなることもあるようです。昭和の白黒テレビが「叩けば映る」とされた原因でもあるようです。
 ハンダはどう見ても鉛入りで質は酷く、施工はヘタクソです。安いってこういうことだよねぇ~とか思いながら手直ししましたがお粗末です。
 これらの対策が功を奏したのか偶然なのかわかりませんが、不審な挙動は無くなり安定して点く様になりました。
 一晩冷まして明日再チェックです。

#照明器具 #電子工作
Icon of admin
 照明器具のメンテナンスでは製作中のArtNet-Engineを通してDMX信号を送っています。
 入力をデコードして一時スタックし、それをエンコードして送るだけの状態ですが、目に付く遅れもなく不審な挙動もなく何の芸もなく普通に動きます。
 今のところ遅れても1フレームなので、このレスポンスでまとまれば御の字かなと。当たり前が当たり前に出来ればそれでいいのです。

 ボチボチ現場対応も増えつつあり、部下の仮打ちが終わって作業スペースを確保出来たので本業の道具もメンテナンスしなければなりません。ArtNet-Engineなど趣味の開発はペースダウンです。

#[Art-Net] #電子工作
Icon of admin
 ここ最近、中華電機からのお届け物が速い。
 これまでは「お届け予定日」から数日以内に届けば良い方で、下手すりゃ数週間遅れることも珍しくありませんでした。
 何がどう変わったのかわかりませんが、最近は予定日よりも早い。
 数日前に届いた物は予定より半月も早い。好印象を持たせるためのふかした予定日だったとしても、DHLなどを使わずに1週間で届いたのですから間違いなく速い。

 てなわけで、RaspberryPiCM4が入荷しました。小さいとは聞いていましたが、思った以上に小さい。
 半導体不足で入手難でしたから現物を見るは初めてです。箱を見た瞬間、あまりの小ささにRaspberryPiのロゴが入ったノベルティが送られてきたのか?、やられたのか?と思ったくらいです。
 灯を入れてチェックする時間はしばらく取れそうにありませんが、想像が広がる楽しい一品です。

#RaspberryPi #中華電機

2023年2月17日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 RaspberryPiCM4は単体では動きません。なんらかのインターフェースボードが必要です。
 ArtNet-Routerに使うのであればEtherポートが2個、HDMI、USB3.0が付いている物が良いなぁ~くらいの気持ちで買ったボードには「SIMカードスロット」が付いています。
20230217134603-admin.jpg
 お目当てではなかったのですが、どうせならLTEモデムも実験してみようかと。出先でIoT的に使うならネット回線も繋いでおきたいと思っていました。ネットに繋がりさえすればVPNでどうにもでもなります。
 ちなみに、3割程安いすごく似たボードがありますが、こちらにはSIMカードスロットがありません。M.2スロットも安い方がEキーで今回のはBキーです。どちらが良いというより目的が違います。
 モデムカードは「L850-GL」をオーダー。日本国内のプラチナバンドにも対応する数少ないM.2モデムです。価格は約3,500円(2023年2月現在)ですが、プラチナバンドに対応した外付けのwifiルーターよりも安価です。ドライバはOS標準に無いそうですが、チップメーカー純正のドライバがGitHubにあります。
 設定は先達の情報を継ぎ接ぎしてどうにかしましょう。

#RaspberryPi

2023年2月21日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 思った以上に本業が忙しくなってしまいましたが、アルゴリズムの検討はしています。
 今はキー入力からコマンドを起こす処理です。これも思った以上に難しい。
 入力されたコマンドを実行する際に処理が出来なければエラーを吐く方法もアリですが、入力する途中で制限をかけた方がコマンド実行に負担をかけないのでいいかなと。
 また、コマンドの入力中でも一部の機能は実行したい。例えばランプチェックなどです。入力中に状況を確認して最終決定が出来れば操作性が良くなるからです。コマンド入力が確定せずともそれをチェックし、構文確認や一部の機能を実行出来る様にしたいのです。
 とまぁ、言うのは簡単ですが、これをどう処理したものか。ケースバイケースでベタ処理を書くのは無駄が多いので、出来る限りリソースを汎用化することでメンテナンス性も良くしておきたい。プログラム書きの基本だと思っていますが、同じ処理は一つしか書かないってことです。

#C言語

2023年2月22日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 写真を喋っているように加工するAIだそうです。

 突っ込みどころはあれど凄いですね。
 シンギュラリティ(人工知能(AI)が人類の知能を超える転換点(技術的特異点)、または、それにより人間の生活に大きな変化が起こるという概念のこと。)が近々やってくると言われていますが、現在の加速度的な進歩から想像するに、私が人であるウチにやってくるのは間違いないかと。
 こんな調子で照明プラン・オペをやってくれるAIも出現しませんかね。技術的に可能でも商業的にありえないかな?
 ちなみに、サムネの女性に瓜二つな知人がいますwww

#雑談
Icon of admin
 JAXAのH-3が打ち上らなかったことが「失敗」か「中止」かで騒いでいる方々がいます。
 期待通りに衛星を軌道投入出来なかったことは事実ですが、発射事業としては「失敗」であり、機体運用としては「中止」なだけではないかと。立場が違えば観点と言葉が違うってだけなんじゃないすかね。「成功」か「失敗」かと聞かれたら「失敗」だし、「完了」か「中止」かと聞かれたら「中止」なだけとも言えます。ただ、私がJAXA推しで規模は小さくても物作りをしているからですが、無能を印象付けるために「失敗」の言葉を使うような記事には嫌悪を感じてしまうのです。
 今回の件は、高価な衛星と機体を失うことなく「安全に中止出来た」という意味で「成功」だと私は考えます。発射0.4秒前に不具合を検知して停止出来たことがどれだけ凄い事か。飛ばなかったことは明らかなマイナスポイントで誉められたもんぢゃありませんが、資産としての機材を保全する点から見れば衛星の持ち主や保険会社に有益な輸送システムであることを証明したとも言えます。
 H-3は、高い信頼性と豊富な成功実績を持つH-2を単に大きくしたシステムではなく、主エンジンLE-9を代表とする新機軸を多く取り入れたシステムです。しかも、費用を抑えて輸送能力を大幅に向上させるという無茶振り事業です。これが初回で大成功を収められなかったからってダメの烙印を押すのはどうかと思います。成せなかったことに寛容になれとは言いませんが、人のために責任ある仕事をしたことのない人によくある反応なので読んでて溜息。どうしてもJAXAやH-3に烙印を捺したいなら、将来H-3によって実現出来たサービスを使っちゃいけません。ま、そういう仁義を持てない人ほど「失敗」という言葉を使ってマウントを取りたがるのでしょうけど。
 今時のネット言葉ごとく「おわりだよ」的な発言をするのは簡単です。少なくない税金を使った事業は計画通りに成果を出すことが当然であり、その成否を世間に知らせることも大切なことですが、その事業の達成が長期的に有益で望ましいことなら今後どうするべきかを論ずることも同様に大切なことです。将来のための思考も提案も行動もせず目先の結果をあげつらう愚民には沈黙を求めたいものです。せめて居酒屋トークに留めておけと。
 何にしても、1ヶ月後の再実施が成功することを祈るばかりです。

#雑談

2023年2月24日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 Art-Net関連は脳裏に湧いたアイデアを一通り吐き出したら次の壁が見えてしまいました。
 Pythonでは思うように作れなかったことがC言語によって解決出来たことは成果ですが、最後の壁を攻略したと思ったのに次の壁が霧の先に見えています。登る方法や降りる方法、はたまたトンネルを掘る方法を地道に探さんといけません。登るべきか掘るべきかルートを変えるべきかも壁の先が見えないのでわからんのですけど、壁が間近に見えるところまで行って一服すかね。
 壁と書きましたが、その筋の専門家にとっては小さな水溜りかな?

 四の五のと言葉を積んでも出来んことは出来んので、一服ついでに棚上げになってるネタに手を付けています。
 「後は組むだけ」で放置してあるネタが幾つかあるのでそれをヤリ切ってしまいましょう。
 児童公園の築山を攻略してガッツポーズする50代も格好悪すぎてワルくないwww

#雑談

2023年2月25日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 先日、「同じ処理は一つしか書かない」ってことを書きましたが、これを突き詰めるとオブジェクト指向なんだなと。
 私にとってPythonで学習した最大の成果ですが、C言語でコレを成すのはC++です。
 残念ながら「オブジェクト指向ってなんぞや!?」を説明できる知識も文才も私にはありません。Pythonでは感覚的に便利に使っていましたが、煮詰まった今、神達の凄さを垣間見られた気分になっています。悪夢から逃げたくて光明を得た夢を見ているだけかもしれませんがwww

 「神達」ってのは私の勝手な呼び方です。UNIXを始め現代の社会基盤に無くてはならないシステムの礎を構築した特別な先人のことです。残念ながら社会性に乏しく商売で成功した方は少ないのですが、彼らの成果には驚きが満ちています。論理性ではなくその閃きに「神」を感じるのです。ぶっちゃけ、「天才とナンとかは紙一重」で「こいつらの頭の中おかしくね??」ってことなんですけど。
 こういった「ちょっとおかしな人たちの成果」を社会に普及させたって意味でビル・ゲイツさんの存在は大きいと思います。一部からはMS-DOSの一件で「有史以来、最大の詐欺師」と呼ばれているようですが、「ちょっとおかしな人たち」には絶対不可能な「ちょっとおかしな人たちの成果」を巨大なマーケットにしたのは彼です。エンジニアとしては凡才な彼は商人としては非凡だったんすかね。
 かのスティーブ・ジョブスさんも同類の詐欺師ですが、私は勝手に「電気で夢を見るピカソ」と彼を呼んでいます。この人もエンジニアとしては凡才だと思いますが、誰にも見えてない世界を夢に見られる天才デザイナーだったと思うのです。私たちが使っているガジェットの幾つかは彼によって世に根付きました。突き詰めれば彼がゼロから発想した物は思い当たりませんが、「これをこうしたら面白いのだ!!」を押し通した身勝手さには距離を置いて尊敬を感じます。彼がAppleⅡを皮切りにLisa、Macintosh、NeXT、iPod、iPhoneを世の中に欲しがらせたことは紛れもない事実です。商売が巧いというより、彼が欲しいモノを作ったら未来を手に出来た消費者が勝手に盛り上がってしまったという凄く不思議な展開を感じます。「ちょっとおかしな人たちから見てもすごくおかしな人」だったそうですけど、その時代の非常識を押し通さないと次の時代の常識は作れないのかなぁ~なんて思ったり。
 思い出しましたが、TRON(トロン)が発展して普及してたらなぁ~って思います。1998年にはイングラムが警らをする日本だったかもしれません。提唱者である坂村教授が開発初期に執筆された本を読み直しましたが「この方は預言者か?」と思うことばかり。預言者の最高峰は神の中の神であるアラン・ケイ老師であり、TRONもそのアイデアに触発されたプロジェクトの一つでしかないのですが、今や当たり前となっている事の具体的な方法論と開発フローが40年前の本に書かれています。しかも、現実の歴史と酷似する内容。すげー。当時の中坊は頑張って読んで理解不能ながらも感銘を受けた。Art-Netでナニかしようとしている今の自分にはTRONの血が少しだけ入っていると思い込んでいますwww

 毎度のワケわからんことを書きましたが、非凡な先人のことを妄想したら凡人にも閃きが落ちてこないかなぁ~。

#雑談

2023年2月27日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 中華電機ムービングの筐体が割れています。アッパーボックスの樹脂パネルです。これを修理します。
 樹脂の補修は材質を把握するのが第一歩です。材質によって治し方が違うからです。
 材質の判断は匂いで見当を付けて溶剤もしくは接着剤で溶解具合いを見るのが基本です。今回のはABSでした。

 ABSどうしの接着ならコレが基本でしょう。セメダインの「ABS用」です。
 接着には様々な方法がありますが、これは「溶着」です。材を溶かして結合させます。
 面積のあるABSどうしの接着ならコレを両側に塗って貼り合わせればほとんど場合十分です。
20230227200529-admin.jpg
 今回のブツは肉薄なので肉盛りして補強した方がいいみたいです。破断面がキチンと嚙み合いませんので歪みというか応力がかなり残っているようです。今回の破損も衝撃が引き金だとしても応力のために割れやすくなっていたとも思われます。加熱して応力を取ることも出来るそうですが、職人技なので私には無理です。
 こういう時にはプラリペアです。樹脂材全般に使えますが、ABSとは相性が良いので裏側に盛って補強にします。
20230227201504-admin.jpg
 ただ、単にプラリペアを盛るより接合面に谷を掘って盛るのがお勧めです。
 こんな時、ミニルーターが便利です。私はPROXXONのミニルーターを使っています。
20230227204722-admin.jpg

 ABS用で形を戻し、裏側の目立たないところにプラリペアを盛って補強します。

#器具の修理

2023年2月28日 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 中華電機の小さなムービングライトが全数戻ってきたので修理をしています。これまでの修理で確認すべき点が出ているので全台予防修理です。
 作業は主にハンダ付けの確認です。正常に動く機体でもハンダコテを当てると故障機体と同じ症状が見られますのでやっておいた方がいいでしょう。1年生部下でもここまでヘタには出来ないよねってくらい酷い施工なので念には念をです。
 一度にやりきれない台数ですからヒマを見てボチボチと。

#器具の修理