電装工芸日記
- 舞台照明機器の製作とか -
2026年4月 この範囲を時系列順で読む この範囲をファイルに出力する
3Dプリンタは壁面に横穴を開けると上下に少し潰れてしまいます。マイナス寸法ですからドリルで仕上げればいいのですが、ある程度見越した寸法にした方が良いようです。トライアンドエラーになるので様子を見ながら調整です。
来週には部品が揃いそうですから、ファームウェアも書き始めています。表示は10/60進数ですが、16進数から変換するのではなく、23:59:59.9で折り返す10/60進数のインクリメントカウンタです。この部分は単純なので空き時間にサクッと書けました。
DMXの受信は過去書いたファームウェアから拝借し、7zeg表示のコントロールは新規作成です。7zeg表示は桁送りをするサーチ式ですが、桁をONにする時間長で輝度調整が出来る様にします。日中の屋外もあれば暗い屋内もありますから調整出来た方がいいと思うのです。設定値の保存まではしませんけど。
#ガチ工作 #器具の製作
来週には部品が揃いそうですから、ファームウェアも書き始めています。表示は10/60進数ですが、16進数から変換するのではなく、23:59:59.9で折り返す10/60進数のインクリメントカウンタです。この部分は単純なので空き時間にサクッと書けました。
DMXの受信は過去書いたファームウェアから拝借し、7zeg表示のコントロールは新規作成です。7zeg表示は桁送りをするサーチ式ですが、桁をONにする時間長で輝度調整が出来る様にします。日中の屋外もあれば暗い屋内もありますから調整出来た方がいいと思うのです。設定値の保存まではしませんけど。
#ガチ工作 #器具の製作
2026年3月 この範囲を時系列順で読む この範囲をファイルに出力する
時間が空いたので DMXtimer の回路図を書いてみました。短時間で描いたのですこし雑です。
基板を書いて中華基板に発注しましょう。
※ 基板の都合に合わせて回路を変更しました。
#器具の製作
基板を書いて中華基板に発注しましょう。
※ 基板の都合に合わせて回路を変更しました。
#器具の製作
「DMXタイマー」は私が作るモノに興味を示さない部下ですら「欲しい！」ときました。興味を示さないのは話や図だけでは物の想像が出来ないからですが、DMXタイマーは伝わり易かったようです。
こりゃ作るしかありません。
必要な技術は大したことありませんが、７ゼグを点灯させるのに電力をそこそこ喰うのと、時計としてどれくらいの精度を求めるかによって労力が違います。
分を二桁、秒を二桁、1/10秒を一桁にしようと思います。時間値をどうするかは思案中ですが、24時間表示にしとけば後でタイムコードの表示にも使えるかな？
フィクスチャープロファイルを自作出来ない調光卓もありますのでディマーとして扱えればいいかなと。動作はDMXアドレスを512ch固定、値000で停止クリア、値001以上でカウントとします。これでカウント開始を255と打ち込めばゆっくりF.Iでもそれほど遅れないかなと。
#器具の製作
こりゃ作るしかありません。
必要な技術は大したことありませんが、７ゼグを点灯させるのに電力をそこそこ喰うのと、時計としてどれくらいの精度を求めるかによって労力が違います。
分を二桁、秒を二桁、1/10秒を一桁にしようと思います。時間値をどうするかは思案中ですが、24時間表示にしとけば後でタイムコードの表示にも使えるかな？
フィクスチャープロファイルを自作出来ない調光卓もありますのでディマーとして扱えればいいかなと。動作はDMXアドレスを512ch固定、値000で停止クリア、値001以上でカウントとします。これでカウント開始を255と打ち込めばゆっくりF.Iでもそれほど遅れないかなと。
#器具の製作
お世話になっている他社さんからの依頼で現地照明の増員でした。
そこで話をしていたところ、調光卓のGOボタンで動くストップウォッチが欲しいとのこと。ストリートダンスなどの音源演目の現場で調光卓とストップウォッチを両方叩くのは手が足りないことがあると。うん、よくわかります。
条件を整理しますと、曲に対する最初のCUEでストップウォッチが動き出し、曲が終わったところで停止というか次の曲の開始までにリセットされていればいいと。まさにその通り！
以前、音源に合わせたタイムコードを出力する研究をしていました。これとは違ったアプローチですが求める本筋は同じです。
さてどうするか。MA系の卓ですと接点出力がありますのでこれを用いてストップウォッチを制御する方法もありますが、汎用性を考えるならDMXで動くストップウォッチがあればいいのでは？と閃く。
例えば、512chが000なら停止、255ならカウント開始みたいにしておいてディマー感覚でCUEにデータを入れておけばいいってことです。ストップウォッチはカウント開始、停止、クリアの３つの動作が基本になりますのでそれぞれに値を割り振っておけばいい。F.Iの始まりでも動いて欲しいので001でカウント開始がいいのかな？卓とは無関係のストップウォッチを手操作で動かすよりは便利になればいいので厳密さはボチボチでいいと思う。
なんにしても、「DMXタイマー」って名前で試案してみましょう。
#器具の製作
そこで話をしていたところ、調光卓のGOボタンで動くストップウォッチが欲しいとのこと。ストリートダンスなどの音源演目の現場で調光卓とストップウォッチを両方叩くのは手が足りないことがあると。うん、よくわかります。
条件を整理しますと、曲に対する最初のCUEでストップウォッチが動き出し、曲が終わったところで停止というか次の曲の開始までにリセットされていればいいと。まさにその通り！
以前、音源に合わせたタイムコードを出力する研究をしていました。これとは違ったアプローチですが求める本筋は同じです。
さてどうするか。MA系の卓ですと接点出力がありますのでこれを用いてストップウォッチを制御する方法もありますが、汎用性を考えるならDMXで動くストップウォッチがあればいいのでは？と閃く。
例えば、512chが000なら停止、255ならカウント開始みたいにしておいてディマー感覚でCUEにデータを入れておけばいいってことです。ストップウォッチはカウント開始、停止、クリアの３つの動作が基本になりますのでそれぞれに値を割り振っておけばいい。F.Iの始まりでも動いて欲しいので001でカウント開始がいいのかな？卓とは無関係のストップウォッチを手操作で動かすよりは便利になればいいので厳密さはボチボチでいいと思う。
なんにしても、「DMXタイマー」って名前で試案してみましょう。
#器具の製作
Art-Net / ArtDMX を受信して何かをするプログラムを書けそうな気になってきました。
まずはコンソールを１台とし、ループバッファに Art-Net をひたすらスタックし、最新の ArtDMX を dump 表示させるものを製作しましょう。これが出来なきゃ何も出来ないってくらいシンプルなものです。
ここから複数コンソール対応など、データの取り扱いを色々実験していきます。[コンソール]-[ユニバース]-[データ] の３階層のデータ管理を十分に煮詰めずに先に進んでも良いことはありません。以前の試作から進んでいなかったのはこの辺りに原因があります。このところ AIさんとやり取りしていたのはデータ管理を整理するためです。
#器具の製作 #[Art-Net]
まずはコンソールを１台とし、ループバッファに Art-Net をひたすらスタックし、最新の ArtDMX を dump 表示させるものを製作しましょう。これが出来なきゃ何も出来ないってくらいシンプルなものです。
ここから複数コンソール対応など、データの取り扱いを色々実験していきます。[コンソール]-[ユニバース]-[データ] の３階層のデータ管理を十分に煮詰めずに先に進んでも良いことはありません。以前の試作から進んでいなかったのはこの辺りに原因があります。このところ AIさんとやり取りしていたのはデータ管理を整理するためです。
#器具の製作 #[Art-Net]
AI/Geminiさんに聞いたところ、RaspberryPiでは4byte単位、4kB単位でキリ良く考えるとストレスが少ないのだそうな。1byte単位のデータでも4byteで扱った方が良いってことです。
パディング対策して詰め々々がイイって話を振ってきたのもGeminiさんですが、知識のある年寄りに時間を開けて話を聞いた時のような困惑を感じたりしたり。。。
追記
4byte、64byte、4096byte区切りでメモリを扱う様に構造体などを定義すると良いのだそうです。更に、構造体のメモリ上のアドレスをアトリビュートで64の倍数値にするのもお勧めとのこと。
4byteはCPUのレジスタの長さ、64byteはキャッシュの転送単位、4096byteはメモリページの扱い単位です。
気にしなくても動きますが、CPUやOSの挙動において無駄を省くことに繋がるらしいです。
#Ｃ言語
パディング対策して詰め々々がイイって話を振ってきたのもGeminiさんですが、知識のある年寄りに時間を開けて話を聞いた時のような困惑を感じたりしたり。。。
追記
4byte、64byte、4096byte区切りでメモリを扱う様に構造体などを定義すると良いのだそうです。更に、構造体のメモリ上のアドレスをアトリビュートで64の倍数値にするのもお勧めとのこと。
4byteはCPUのレジスタの長さ、64byteはキャッシュの転送単位、4096byteはメモリページの扱い単位です。
気にしなくても動きますが、CPUやOSの挙動において無駄を省くことに繋がるらしいです。
#Ｃ言語
Ｃ言語の共用体(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 を作ったのかを考えるとワクワクします。
とまぁ、最近Ｃ言語の理解が進んで一人笑いが止まらないアホの戯言でした。
オレメモです。
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、８センダー、各16ユニバースで最短でも1.45秒分の保存が出来るハズです。十進数で8192なのは２進数(16進数)でキリの良い数値のため折り返し評価が少ない処理で出来るからです。十進数8192は16進数0x2000でキリがよく処理しやすいのです。このあたりはアセンブリ言語だけでPICマイコンと会話をしてきた者にとって自然な着想です。10進数は人が日常的に使い慣れているだけで特筆するほど合理的な数体系ではありませんし、今どきのコンピュータ(論理回路)に合わせた方が便利です。
ヘッダーチェックは当該の配列要素(例えば an_stack[1024] )を示すポインタからmemcmpで12バイトをチェックすれば済みますので共用体には定義しません。
ArtDMX以外のパケットにも使えるチェック方法です。
#Ｃ言語
されど、今回の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 を作ったのかを考えるとワクワクします。
とまぁ、最近Ｃ言語の理解が進んで一人笑いが止まらないアホの戯言でした。
オレメモです。
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、８センダー、各16ユニバースで最短でも1.45秒分の保存が出来るハズです。十進数で8192なのは２進数(16進数)でキリの良い数値のため折り返し評価が少ない処理で出来るからです。十進数8192は16進数0x2000でキリがよく処理しやすいのです。このあたりはアセンブリ言語だけでPICマイコンと会話をしてきた者にとって自然な着想です。10進数は人が日常的に使い慣れているだけで特筆するほど合理的な数体系ではありませんし、今どきのコンピュータ(論理回路)に合わせた方が便利です。
ヘッダーチェックは当該の配列要素(例えば an_stack[1024] )を示すポインタからmemcmpで12バイトをチェックすれば済みますので共用体には定義しません。
ArtDMX以外のパケットにも使えるチェック方法です。
#Ｃ言語
先日の現場はヒマな時間が長かったのでＣ言語の教科書を読みまくってみましたがかなり整理出来ました。
昨今の教科書はポインタの説明が丁寧です。ハードウェアとしてのメモリの動作がアタマに入っていないと分かり難いことですが、私はPICのアセンブラで普通に扱ってきたことなので改めてではありますが素直に理解出来ました。わかってしまえばむしろ便利だなと。変数の読み書き方法が何種類もあることになるので混乱すると思いますが、どれもメモリへのアクセス手段だと捉え直せばいいだけでした。このあたりが整理できるとmmapも自然に理解出来ます。
ヘッダーファイルはコピペでテキトウに書いていましたが、意味と書き方が整理できました。後はmakefileが整理出来れば良さそうです。
#Ｃ言語
昨今の教科書はポインタの説明が丁寧です。ハードウェアとしてのメモリの動作がアタマに入っていないと分かり難いことですが、私はPICのアセンブラで普通に扱ってきたことなので改めてではありますが素直に理解出来ました。わかってしまえばむしろ便利だなと。変数の読み書き方法が何種類もあることになるので混乱すると思いますが、どれもメモリへのアクセス手段だと捉え直せばいいだけでした。このあたりが整理できるとmmapも自然に理解出来ます。
ヘッダーファイルはコピペでテキトウに書いていましたが、意味と書き方が整理できました。後はmakefileが整理出来れば良さそうです。
#Ｃ言語
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121