🗐 電装工芸日記 - 舞台照明機器の製作とか -

今年は開発案件を進めたい

or 管理画面へ

2026年3月 この範囲を時系列順で読む この範囲をファイルに出力する

Icon of admin
 Art-Net / ArtDMX を受信して何かをするプログラムを書けそうな気になってきました。
 まずはコンソールを1台とし、ループバッファに Art-Net をひたすらスタックし、最新の ArtDMX を dump 表示させるものを製作しましょう。これが出来なきゃ何も出来ないってくらいシンプルなものです。
 ここから複数コンソール対応など、データの取り扱いを色々実験していきます。[コンソール]-[ユニバース]-[データ] の3階層のデータ管理を十分に煮詰めずに先に進んでも良いことはありません。以前の試作から進んでいなかったのはこの辺りに原因があります。このところ AIさんとやり取りしていたのはデータ管理を整理するためです。

#器具の製作 #[Art-Net]
Icon of admin
 AI/Geminiさんに聞いたところ、RaspberryPiでは4byte単位、4kB単位でキリ良く考えるとストレスが少ないのだそうな。1byte単位のデータでも4byteで扱った方が良いってことです。
 パディング対策して詰め々々がイイって話を振ってきたのもGeminiさんですが、知識のある年寄りに時間を開けて話を聞いた時のような困惑を感じたりしたり。。。

追記
 4byte、64byte、4096byte区切りでメモリを扱う様に構造体などを定義すると良いのだそうです。更に、構造体のメモリ上のアドレスをアトリビュートで64の倍数値にするのもお勧めとのこと。
 4byteはCPUのレジスタの長さ、64byteはキャッシュの転送単位、4096byteはメモリページの扱い単位です。
 気にしなくても動きますが、CPUやOSの挙動において無駄を省くことに繋がるらしいです。

#C言語
Icon of admin
 C言語の共用体(union)ですが、教科書やら動画を見ますと「あまり使い道が無い」的な解説が多いような気がします。
 されど、今回のArt-Net系の装置では便利です。Art-Net のポート番号 0x1936(6454) の受信値をとりあえず突っ込むだけで要素毎に取り出すことも出来るからです。例えば ArtDMX は530バイトのパケットですが、受信値を uint8_t[530] (または unsigned char[530]) の配列として保存するだけで ArtDMX の構造体としても扱えます。パディングに注意は必要ですが、便利に使えると思うのです。ID、OpCode、ProVer をまとめて評価するのに先頭12バイトを uint8_t[12] としておいて memcmp で判別することも出来ます。AertDMX と別種の Art-Net パケットもシームレスに扱えそうです。
 天才を超越した神たちが何故 union を作ったのかを考えるとワクワクします。

 とまぁ、最近C言語の理解が進んで一人笑いが止まらないアホの戯言でした。

 オレメモです。
 gccで構造体のパディングを回避する書き方。struct に続いて「__attribute__((__packed__))」を入れるそうな。gcc独特の書式らしいので、コンパイラに合わせた書式を使ってください。

typedef struct __attribute__((__packed__)) {
 uint8_t ID[8];
 uint8_t OpCode[2];
 uint8_t ProVerHi;
 uint8_t ProVerLow;
 uint8_t Sequence;
 uint8_t Physical;
 uint8_t SubUni;
 uint8_t Net;
 uint8_t LengthHi;
 uint8_t Length;
 uint8_t Data[512];
} ad_t;

ad_t ad_data;


 ArtDMXを保存する構造体はこんな感じに書けばよいのでしょう。たぶん。
 この型を sizeof で見て530バイトならヨシです。

 ついでに共用体の定義(案)です。

// Art-Netの受信値を収める構造体
typedef struct __attribute__((__packed__)) {
 uint8_t resv[530];
} an_t;

// ArtDMXを取り出す構造体
typedef struct __attribute__((__packed__)) {
 uint8_t ID[8];
 uint8_t OpCode[2];
 uint8_t ProVerHi;
 uint8_t ProVerLow;
 uint8_t Sequence;
 uint8_t Physical;
 uint8_t SubUni;
 uint8_t Net;
 uint8_t LengthHi;
 uint8_t Length;
 uint8_t Data[512];
} ad_t;

// Art-Netの受信値を保存する共用体ループバッファ
union {
 an_t an_resv;
 ad_t ad_data;
} an_stack[8192];


 こういうことでいいのかな?
 共用体の書き方はまだよくわかってないのですけど。

 共用体の配列を作って Art-Net のポートで受信したパケットを延々と保存します。8191番まで記録したら0に折り返すループバッファです。
 8192個あれば44fps、8センダー、各16ユニバースで最短でも1.45秒分の保存が出来るハズです。十進数で8192なのは2進数(16進数)でキリの良い数値のため折り返し評価が少ない処理で出来るからです。十進数8192は16進数0x2000でキリがよく処理しやすいのです。このあたりはアセンブリ言語だけでPICマイコンと会話をしてきた者にとって自然な着想です。10進数は人が日常的に使い慣れているだけで特筆するほど合理的な数体系ではありませんし、今どきのコンピュータ(論理回路)に合わせた方が便利です。

 ヘッダーチェックは当該の配列要素(例えば an_stack[1024] )を示すポインタからmemcmpで12バイトをチェックすれば済みますので共用体には定義しません。
 ArtDMX以外のパケットにも使えるチェック方法です。

#C言語
Icon of admin
 先日の現場はヒマな時間が長かったのでC言語の教科書を読みまくってみましたがかなり整理出来ました。
 昨今の教科書はポインタの説明が丁寧です。ハードウェアとしてのメモリの動作がアタマに入っていないと分かり難いことですが、私はPICのアセンブラで普通に扱ってきたことなので改めてではありますが素直に理解出来ました。わかってしまえばむしろ便利だなと。変数の読み書き方法が何種類もあることになるので混乱すると思いますが、どれもメモリへのアクセス手段だと捉え直せばいいだけでした。このあたりが整理できるとmmapも自然に理解出来ます。
 ヘッダーファイルはコピペでテキトウに書いていましたが、意味と書き方が整理できました。後はmakefileが整理出来れば良さそうです。

#C言語

2026年2月 この範囲を時系列順で読む この範囲をファイルに出力する

Icon of admin
 部下には花粉症持ちが沢山います。軽症な者もいますが、重症な奴は鼻水ダラダラ目が腫れて口やノドの中が痒いと言ってます。見てて気の毒になります。
 少しでも楽になるように何かしてあげたいのですが、どうしたらいいものか。
 何か作れないかなって工作のネタです。ちなみに、昭和生まれ昭和育ちのおじさんの辞書に「花粉症」という言葉は載っていません。

 重症な奴に聞くと「お風呂に入っている時は凄く楽で幸せ」とのこと。花粉症の症状が劇的に治まるのだそうです。花粉は湿度が高いと飛び散らないので、花粉が無いのと同じになるのかな?。
 部屋の中は空気清浄器と加湿器で対策もしているそうですが、無いよりは楽だけれど、入浴中の浴室には敵わないそうな。
 そこで湧いてきたのですが、空気をそんな空間に通す装置があったらどうだろう。湯船にお湯をためた浴室に通した空気を部屋に導き入れるイメージです。高湿度フィルタって感じですかね?。室内を浴室の様な状態するワケにはいきませんので高湿度にする加湿器は違うような気がします。
 さらに聞くと、マスクの中に入れる濡れフィルタは効果があるそうな。濡れフィルタに花粉が吸着するのでしょう。ただ、しばらく時間が経つと濡れフィルタに付いた花粉を吸うことになるので、短時間ならいいけど良し悪しだそうな。
 そこで思い付いたのですが、リング状にした布地や紐を水にくぐらせながらグルグル回して風を当てたらどうだろう。ゲル状で空気中に漂う水に花粉を触れさせるのが一番効果的なイメージはあるけど、水に触れさせるのは効果があるような気がします。リング状にした布地や紐を使うのは水の表面面積を増やす意味です。くぐらせる水の容器に超音波振動子を入れておけば布地や紐に付いた花粉を落とせるかなってイメージもあります。
 もちろん、水を張った容器の底から空気を出す方法もありかなと。水槽のエアレーションのイメージです。エアーポンプの中を花粉が通るのか?って疑問はありますケドね。

 アレルギー反応でアタマがボーっとするらしいし寝不足も困ります。人材は機材ぢゃありませんが、メンテナンスのための専用工具を作るイメージで取り組んでみましょう。
 ちょうどというか、自宅の石油ファンヒーターが1台不動になってしまったのでこのドンガラを使ってみましょう。

追記
 調べたら、水をフィルタにする空気清浄機がありました。「水空気清浄機」とか「水式空気清浄器」と呼ばれる種類の様です。
 これらが花粉症に効果があるかは不明ですが、作るとしたらのイメージの一つなのは確かです。
 さてさて。

#器具の製作
 
Icon of admin
 糸ハンダは白光(Hakko)さんの製品を使っています。長年愛用しているだけと言えばそれまでですが、伸びや馴染みが良くて使いやすいと思います。
 そんな白光さんの糸ハンダですが、製品ラインナップが変わった様子。これまでは150gや300g巻きでしたが、ホームページを見ると一般向けは100m巻きか1m巻きになっています。ただ、近所のホームセンターには100m巻きがありません。一般的なDIY用途なら1m巻きは正解かもしれませんが私にとっては物足りません。amazonさんに以前の150g巻き製品がありましたので、とりあえずポチっときました。
 ちなみにハンダコテは「FX-600」を使っています。これも白光さんの製品です。簡易的な温度調整機能が付いていますが、設定温度を高めにするとすでに付いたハンダを取るのが楽です。先端は相手物に合わせて使い分けていますが、平べったくて幅のある物が便利です。ムービングライトの修理で表面実装のICを取り外した際には幅広の先端で設定温度を高めにしたところ楽に作業が出来ました。

#電子工作
Icon of admin
 別なムービングライトも修理。もちろん中華電機から仕入れた代物。
 作業場ではLEDが点灯するのに現場でしばらく使うとダメ。熱を持つと何らかの支障が出ると思われます。
 考えられる原因は二つ。一つ目はドライブFETの放熱不良によるサーマルプロテクト。二つ目は大きな電流が流れる経路の抵抗値異常。どちらもハンダ付け不良によるものと思われます。点灯しない色のFETとターミナルは「天ぷらハンダ」になっていることが多い様子。ハンダコテを当てるとブクブクと気泡が出ます。これが原因だと断定は出来ませんが、天ぷらハンダは明らかな不良ですから、ハンダ吸収線でハンダを取り除き盛り直します。物凄く質の悪いハンダ(特にフラックス)を使っていて閉口しましたが・・・。
 現場運用しないと確認は出来ませんが、怪しい機体はすべてハンダを当て直すことにします。

#器具の修理
Icon of admin
 Art-Net 切替&パッチマシンを作るためにC言語を勉強しなおしています。AI/Geminiさんから学んだことですが、C言語はいわゆる高級言語(PythonやJAVAなど)ではなくアセンブリ言語の一つと捉えて教科書を読み直したところわかるわかる、すっげーわかる。なんだ簡単じゃねーかってくらいです。高級言語ほど抽象化されていないけれど、「機械としてのコンピュータ」を操っている感じが強いのにマシンコード(PIC16アセンブリしか知りませんが)を直にさわる時ほどレジスタやメモリに気を配らなくてもいい。途方もなく膨大で広大なライブラリの世界を網羅するのは不可能ですが、基本的なライブラリを使ったC言語として定義された基本書式はPIC16アセンブリのちょっと上くらいです。もちろん、CPUは何をやっているのか、メモリとは何のためにあるのか、I/Oっちゃ何よって基本機構をわかっている必要はありますけど。
 教科書は買い直しました。所有しているのは2008年執筆が一番新しいのですが、20年近く経って書式が変わってきているようです。例えば1バイトを表すcharはint8_tとも書けるようです。コンパイルが通るならば古くても新しくてもいいのですが、どうせならこれからの書式に慣れた方がいいかなと思うのです。
 アセンブリ言語は愚直にベタに書くモノだと思っています。10年後の自分が楽しんで読める内容にしたいですね。

#C言語
Icon of admin
 中華電機から買ったムービングライトが2台故障中です。1台はズーム、1台はゴボホイルが動きません。
 過去記事にもありますが、症状から想像するにステッピングモーターのドライバICの破損だと思われるので交換します。ICはしばらく前に入荷していたのですが、ようやく作業時間が取れました。
 表面実装タイプのICですから作業は少々難しいのですが、交換したところ正常化しました。観察をするとICのお腹にある放熱用のパターンにハンダがしっかり入っていなかった様子。過加熱による熱破壊ではないかと想像しています。

#器具の修理
Icon of admin
 よかれと思って公開しても何かあったら補償しろと言われるのはイヤなのでGPLライセンスで公開しようと思います。手の内は全部見せるし自由に使ってもらっていいけどサポートも補償もしないよってことです。運よく出来上がってからの話ですが、コードを書き始める前に発生しうる責任問題の対策は考えておきたいのです。
 そこで色々考えたのですが、コンテナのDockerを使おうかなと。ご存じ無い方に説明する語彙力は持ち合わせておりませんが、インストーラーではありませんがコマンド一発でインストールが出来る環境構築の母体です。公開するソースコードはもちろんライセンスの宣言なども入れておけるので「知らんがな」にも対応出来そうです。これらをGitHubで公開して履歴を残します。Dockerはとにかく便利です。もしシステムがおかしくなってもDockerのパッケージを入れ直すだけですべてが元に戻るからです。インストール説明書を作る手間も省けます。細かいことを知りたい方はAIさんに聞いてください。
 課題があまりに多くなりすぎてどこから手をつけたモノか困っていますが、一つ一つ片づけていきましょう。

#ガチ工作 #[Art-Net] #器具の製作

■思ってみた

すっかり春ですねぇ。

編集

■複合検索:

  • 投稿者名:
  • 投稿年月:
  • #タグ:
  • カテゴリ:
  • 出力順序:

■日付検索:

■カレンダー:

2026年3月
1234567
891011121314
15161718192021
22232425262728
293031

■カテゴリ:

■最近の投稿:

最終更新日時:
2026年4月21日(火) 06時51分15秒