電装工芸日記
- 舞台照明機器の製作とか -
タグ「器具の製作」を含む投稿［122件］（2ページ目）
OMRONさんのUPSを3Uラックケースに取り付けてみました。
写真は良くありませんが、UPSを3Dプリンタ製のコの字で上下から挟み、その側面にインサートナットを取り付けてラックケースの天板からボルト止めしています。
思った以上というか過剰な強度で固定されています。ラックケースと完全一体！
友人が経営する鉄工場さんに19インチパネルをオーダーしているので、それが入荷したら本組みです。
固定のためのコの字は木材で作っても良かったのですが、固定のためにはそれなりの精度が必要だし、3Dプリンタならデータさえあれば放置プレイで完成するので楽です。フィラメントは大量に消費しますが、このクソ暑さの中で刻みはやりたくない。
追記
このラックケースには裏面にラックレール(ネジ穴の開いたアングル)が付いていません。
後付けの既製品は驚きの高値なので３Ｄプリンタで作りました。余程重いモノを取り付けない限り強度は十分です。
最近、なんでもかんでも３Ｄプリンタで作っていますが便利なので仕方ありません。
#器具の製作
写真は良くありませんが、UPSを3Dプリンタ製のコの字で上下から挟み、その側面にインサートナットを取り付けてラックケースの天板からボルト止めしています。
思った以上というか過剰な強度で固定されています。ラックケースと完全一体！
友人が経営する鉄工場さんに19インチパネルをオーダーしているので、それが入荷したら本組みです。
固定のためのコの字は木材で作っても良かったのですが、固定のためにはそれなりの精度が必要だし、3Dプリンタならデータさえあれば放置プレイで完成するので楽です。フィラメントは大量に消費しますが、このクソ暑さの中で刻みはやりたくない。
追記
このラックケースには裏面にラックレール(ネジ穴の開いたアングル)が付いていません。
後付けの既製品は驚きの高値なので３Ｄプリンタで作りました。余程重いモノを取り付けない限り強度は十分です。
最近、なんでもかんでも３Ｄプリンタで作っていますが便利なので仕方ありません。
#器具の製作
今どきのデジタルコンソールは音響でも照明でも起動に数分かかります。瞬間停電であっても卓電源が落ちるのは避けたい。この対策には無停電電源装置(UPS)が効果的です。
前々から UPS のパッケージを組もうと思っていたのですが、本格的組むことにしたので製品調べ。OMRONさん一択です。海外製で安価な物はありますが将来必ず必要になる交換バッテリーの入手に不安があります。その点OMRONさんには安心感があります。
と、久しぶりにOMRONさんのサイトを見たら製品ラインナップが大きく変わっていました。
UPSの機能を大別しますと、
１）常時バッテリー供給か平時は入力電源供給で停電時バッテリー供給か。
２）バックアップ時の出力がPWMによる疑似ACか正弦波か。
となります。
望ましいのは常時バッテリー供給の正弦波ですが、こういった製品は一般的に高価です。
そんな基準で見ていたら、OMRONさんの廉価版が平時入力電源供給の停電時正弦波になっていました。PWMによる疑似ACは最廉価版だけになってます。これはスゲー。
さぞお高くなったろうなと思ったら意外や意外、価格は据え置きの機能アップでした。
製品は「BY120S」と「BY80S」です。BY120Sが負荷容量720w/重量8.5kg、BY80Sが負荷容量500w/重量6.4kgです。手ごろ感があります。
定価は微妙に躊躇しますが実売は4万～6万円です。トラブル損金の前払いと考えたら安価でしょう。これが高価と言われたらトラブルを真正面から受け止めて頂くしかありません。
これを3Uのラックケースに入れるのが基本方針です。
無垢のラックパネルを削るのは大変ですし、タカチ電機さんに加工を依頼すると高額です。友人が三代目社長をやっている鉄工所にラックパネルの製作を依頼しました。
#器具の製作
前々から UPS のパッケージを組もうと思っていたのですが、本格的組むことにしたので製品調べ。OMRONさん一択です。海外製で安価な物はありますが将来必ず必要になる交換バッテリーの入手に不安があります。その点OMRONさんには安心感があります。
と、久しぶりにOMRONさんのサイトを見たら製品ラインナップが大きく変わっていました。
UPSの機能を大別しますと、
１）常時バッテリー供給か平時は入力電源供給で停電時バッテリー供給か。
２）バックアップ時の出力がPWMによる疑似ACか正弦波か。
となります。
望ましいのは常時バッテリー供給の正弦波ですが、こういった製品は一般的に高価です。
そんな基準で見ていたら、OMRONさんの廉価版が平時入力電源供給の停電時正弦波になっていました。PWMによる疑似ACは最廉価版だけになってます。これはスゲー。
さぞお高くなったろうなと思ったら意外や意外、価格は据え置きの機能アップでした。
製品は「BY120S」と「BY80S」です。BY120Sが負荷容量720w/重量8.5kg、BY80Sが負荷容量500w/重量6.4kgです。手ごろ感があります。
定価は微妙に躊躇しますが実売は4万～6万円です。トラブル損金の前払いと考えたら安価でしょう。これが高価と言われたらトラブルを真正面から受け止めて頂くしかありません。
これを3Uのラックケースに入れるのが基本方針です。
無垢のラックパネルを削るのは大変ですし、タカチ電機さんに加工を依頼すると高額です。友人が三代目社長をやっている鉄工所にラックパネルの製作を依頼しました。
#器具の製作
Art-Net node の電源には在庫の電源基板を使うことにしました。
数年前に倒産してしまったイーター電機の製品です。この会社の製品はサイズの割に出力が大きく廉価版でも出力波形が綺麗。優秀なメーカーが安いだけの中国製に駆逐されてしまったのは残念でならず、同じモノを買うことは叶いませんが、医療グレード一歩手前の安定した動作を求めたいならこういった製品がいい。国産にこだわりませんが、TDKラムダさんが頑張っていることが救いです。
とは言うものの、裸の基板ですから何かしらの函に入れねばいけません。もちろん3Dプリンタのお仕事です。無料で使う手続きがわかったFusionでサクッとモデリングしてプリントです。寸法の出し方がわかってきたので一発ＯＫ。実装ではひっくり返して写真の表を下にします。
仮組みにも搬送時の振動に耐えらえる作りは求めたい。
#器具の製作 #[Art-Net]
数年前に倒産してしまったイーター電機の製品です。この会社の製品はサイズの割に出力が大きく廉価版でも出力波形が綺麗。優秀なメーカーが安いだけの中国製に駆逐されてしまったのは残念でならず、同じモノを買うことは叶いませんが、医療グレード一歩手前の安定した動作を求めたいならこういった製品がいい。国産にこだわりませんが、TDKラムダさんが頑張っていることが救いです。
とは言うものの、裸の基板ですから何かしらの函に入れねばいけません。もちろん3Dプリンタのお仕事です。無料で使う手続きがわかったFusionでサクッとモデリングしてプリントです。寸法の出し方がわかってきたので一発ＯＫ。実装ではひっくり返して写真の表を下にします。
仮組みにも搬送時の振動に耐えらえる作りは求めたい。
#器具の製作 #[Art-Net]
RaspberryPi が案外色んなことに対応できるのは GPU のオカゲだそうな。
GPU は画像処理を担うモジュールですが、計算に特化した GPGPU という使い方も出来るらしい。
GPGPU はその昔の FPU と呼ばれた計算チップとは意味が違います。メモリに展開した複数の値に対して同時に計算が出来るらしい。代数計算というかC言語などで言う配列に対してすべての要素を同時に計算するらしい。具体的にどうすれば何が出来るのかはわからないのですが、比較的簡単な計算を同時に沢山出来ると思えばいいらしい。「算数」が全ての私と「数学」を操る方とでは「比較的簡単」の意味は違うと思いますけど、例えば動画の明暗を調整するなんて計算には向いてますよね。すべてのドットに対して輝度を上げたり下げたりするのですから。
この機能は調光卓を作るのに向いてますね。調光卓は沢山の値に一意の値を掛け合わせることをひたすらやっているのです。forループで１個づつ計算するよりメモリ転送の時間はかかっても一斉に計算するなら後者の方が速いかもしれません。
パッチマシンは設定を参照しながら値を並べ直す作業がほとんどですから GPGPU を使ってもあまり意味が無いと思われますが、卓を作るならば GPGPU を使えたらと思ってしまいます。群の数に一定の値を当てて積を得る作業が高速化出来たら作れると思うのです。位相をオフセットした sin などを当てられたらエフェクトエンジンそのものです。
#器具の製作
GPU は画像処理を担うモジュールですが、計算に特化した GPGPU という使い方も出来るらしい。
GPGPU はその昔の FPU と呼ばれた計算チップとは意味が違います。メモリに展開した複数の値に対して同時に計算が出来るらしい。代数計算というかC言語などで言う配列に対してすべての要素を同時に計算するらしい。具体的にどうすれば何が出来るのかはわからないのですが、比較的簡単な計算を同時に沢山出来ると思えばいいらしい。「算数」が全ての私と「数学」を操る方とでは「比較的簡単」の意味は違うと思いますけど、例えば動画の明暗を調整するなんて計算には向いてますよね。すべてのドットに対して輝度を上げたり下げたりするのですから。
この機能は調光卓を作るのに向いてますね。調光卓は沢山の値に一意の値を掛け合わせることをひたすらやっているのです。forループで１個づつ計算するよりメモリ転送の時間はかかっても一斉に計算するなら後者の方が速いかもしれません。
パッチマシンは設定を参照しながら値を並べ直す作業がほとんどですから GPGPU を使ってもあまり意味が無いと思われますが、卓を作るならば GPGPU を使えたらと思ってしまいます。群の数に一定の値を当てて積を得る作業が高速化出来たら作れると思うのです。位相をオフセットした sin などを当てられたらエフェクトエンジンそのものです。
#器具の製作
昼休みに自宅に戻りプリントを開始。帰宅したらプリントされていました。
仮組みしたらこんな感じ。
間違いない強度を与えてから減らすのではなく、ギリギリ貧弱に作って補強しようと思ったのですが十分にホールドしています。運用上起こりうる加速度に十分耐えられそう。
どこまで簡素に出来るかって意味では勉強になりました。
#器具の製作
仮組みしたらこんな感じ。
間違いない強度を与えてから減らすのではなく、ギリギリ貧弱に作って補強しようと思ったのですが十分にホールドしています。運用上起こりうる加速度に十分耐えられそう。
どこまで簡素に出来るかって意味では勉強になりました。
#器具の製作
MoC を通して Art-Net_node を使うには数品組み合わせなければなりません。最終的には綺麗にパッケージしたいですが色々試してから決めたいかなと。ただ、テストの段階でもバラバラのままでは美しくありません。せめて合板にまとめる位はしたいかなと。こういった場合、ネジ止めのステーが付いてない機器を固定するのに苦労します。特にACアダプタの類は何の取り付け機構も付いていません。両面テープでもいいのですが、真夏の倉庫に放置しようものなら糊残りが酷いことになるので嫌いです。
ならばステーを作ればいいのです。
早速 Fusion でデータ作成。簡単な形状ですから３Dプリンタの CAM データまでやっても15分くらい。プリントの予想時間はとんでもない数字ですけど。
#器具の製作
ならばステーを作ればいいのです。
早速 Fusion でデータ作成。簡単な形状ですから３Dプリンタの CAM データまでやっても15分くらい。プリントの予想時間はとんでもない数字ですけど。
#器具の製作
現地照明でしたが、シュートが終わったらバラシまで待機という名の休憩。直しとトラブルシュートに対応出来ればいいのでまとまった空き時間です。こんな時は設計という名の妄想が一番です。
課題は毎度おなじみ「ArtNetPatch」です。主にソフトウェアの構成が課題です。
受けたデータを一時保存、加工、出力しますので、機能は映像ストリーミングに近いかもしれませんが、自分のイメージはデータベースです。
その昔ファイルメーカーを母体に機材の稼働管理システムを作って今も使っていますが、データを動的に仕分けて加工する感覚が今回活用出来ています。
アルゴリズムと言えばそうなんですが、データを保管する構造体の設計が主な作業です。可能か不可能かを確認しながらになりますが、最終的にまとめる構造体が決まれば仕分けて加工するアルゴリズムはおのずと決まってくるので私にはこの感覚で進めるのが性に合っているようです。処理の全体像が見えてきました。
アセンブラではないので構想の段階で処理時間の見込みを付けることは難しいのですが、そもそもRaspberryPiのCPUにおけるマシンコードの動作速度はどうだと計算したら恐ろしい数字。ARMの2.4GHzですが、PICの感覚で単純計算したら１クロック当たりの時間は0.42nsec。PICに比べたら桁違いというか単位違い。OSを介するので単純には比べられないもののマシンコードのイメージで書けばかなり速くなりそう。例えば、積や商を求めるために四則演算をするかビットシフトをするかってことです。2倍や1/2などの2の乗数に関わる積や商ならビットシフトの方が速いハズです。この辺りが「C言語はアセンブラを汎用化したもの」ってイメージであり、Pythonとは違い、C言語はアセンブラの感覚で使うベシってのが私個人の感覚になりつつあります。出来るだけ単純な計算方法を目指してデータ構造を考えるのです。Ｃ言語の難解さがアセンブラ傾向のアプローチで軽くなった気分です。普通は逆なんでしょうけど。
Ｃ言語を作った神達はアセンブラをマクロ化して手間を減らすところから始まってますので、世代を経ても底辺はアセンブラなんでしょう。同時代のCOBOLやFORTRANは意味付けが違うようですけど。
勝手な妄想はともかく、どんなデータをどう変換・加工するかを明らかにすればおのずと見えてくるようです。
#[Art-Net] #器具の製作 #Ｃ言語
課題は毎度おなじみ「ArtNetPatch」です。主にソフトウェアの構成が課題です。
受けたデータを一時保存、加工、出力しますので、機能は映像ストリーミングに近いかもしれませんが、自分のイメージはデータベースです。
その昔ファイルメーカーを母体に機材の稼働管理システムを作って今も使っていますが、データを動的に仕分けて加工する感覚が今回活用出来ています。
アルゴリズムと言えばそうなんですが、データを保管する構造体の設計が主な作業です。可能か不可能かを確認しながらになりますが、最終的にまとめる構造体が決まれば仕分けて加工するアルゴリズムはおのずと決まってくるので私にはこの感覚で進めるのが性に合っているようです。処理の全体像が見えてきました。
アセンブラではないので構想の段階で処理時間の見込みを付けることは難しいのですが、そもそもRaspberryPiのCPUにおけるマシンコードの動作速度はどうだと計算したら恐ろしい数字。ARMの2.4GHzですが、PICの感覚で単純計算したら１クロック当たりの時間は0.42nsec。PICに比べたら桁違いというか単位違い。OSを介するので単純には比べられないもののマシンコードのイメージで書けばかなり速くなりそう。例えば、積や商を求めるために四則演算をするかビットシフトをするかってことです。2倍や1/2などの2の乗数に関わる積や商ならビットシフトの方が速いハズです。この辺りが「C言語はアセンブラを汎用化したもの」ってイメージであり、Pythonとは違い、C言語はアセンブラの感覚で使うベシってのが私個人の感覚になりつつあります。出来るだけ単純な計算方法を目指してデータ構造を考えるのです。Ｃ言語の難解さがアセンブラ傾向のアプローチで軽くなった気分です。普通は逆なんでしょうけど。
Ｃ言語を作った神達はアセンブラをマクロ化して手間を減らすところから始まってますので、世代を経ても底辺はアセンブラなんでしょう。同時代のCOBOLやFORTRANは意味付けが違うようですけど。
勝手な妄想はともかく、どんなデータをどう変換・加工するかを明らかにすればおのずと見えてくるようです。
#[Art-Net] #器具の製作 #Ｃ言語
EoC を通しても動く Art-Net-node が安価に手に入るなら「コンソール・パック」を作ろうかな。UPS(無停電電源装置)、Art-Net-node(レガシーDMXの入力のため)、EoCコンバーター、Ethernet-Hub(PoE)、インターカム・パワーサプライなど卓周りで使いそうなモノを一つにまとめるのです。2Uか3Uのラックケースに入るかな。
同じ要領で「ステージ・パック」もあるといいですね。これにはインターカム・パワーサプライではなくDMXスプリッターを入れましょう。
箱作りに手間はかかりますが、既製品を固定するだけですので比較的簡単です。
#器具の製作
同じ要領で「ステージ・パック」もあるといいですね。これにはインターカム・パワーサプライではなくDMXスプリッターを入れましょう。
箱作りに手間はかかりますが、既製品を固定するだけですので比較的簡単です。
#器具の製作
現場ですが、簡単なひな壇を組むだけの現地道具なので終演までヒマです。
ArtNetPatch の ap_transmitter の構造を構造体配列を元に整理したのですが、割り切って構成したら案外軽い処理になりました。メモリの節約など考えず、条件分岐や計算を出来るだけ減らし繰り返しをヒトまとめにする方針だからでしょうか。
実際に組んで実行時間を計測しなければなりませんが、パッチ処理の後にもディレイやプロファイルカーブの処理を入れられそうな予感がします。
receive(受信)、bind(入力ユニバースを内部Bus(ユニバース)にパッチ、ここで数値をマージしてHTPミキサーとします)、pre-delay、pre-profile-curve、patch、post-delay、post-profile-curve、transmit といった流れで考えています。
ついてはモジュール構成を少し変えます。
ap_transmitter の中の数値操作と Art-net の出力を分割します。
fps はともかく、すべてのユニバースを連続して送るのは避けた方がいいかなと思うので、ユニバース毎にインターバルを持たせるためです。
１）アプリの起動部とし、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値をまとめる「ap_effect」
５）Art-Net を出力する「ap_transmitter」
６）データのタイムアウト管理をする「ap_timeout」
今後はタイムラグを減らす工夫を考えてみましょう。
出力の目標は 30fps 以上、出来れば 36fps ですが、1/36秒以内に処理を一巡出来るなら遅れても1フレームとなります。無理ならスレッド的なアプローチで考えて出来るだけ遅れを少なくしましょう。
何にしても、試作をして処理時間と処理負荷の計測が必要です。
こんな複雑なシステムは10回くらい書き直すつもりで試すしかありません。素人の私が結果を完全に予測するなんで無理ですもん。
#[Art-Net] #器具の製作 #Ｃ言語
ArtNetPatch の ap_transmitter の構造を構造体配列を元に整理したのですが、割り切って構成したら案外軽い処理になりました。メモリの節約など考えず、条件分岐や計算を出来るだけ減らし繰り返しをヒトまとめにする方針だからでしょうか。
実際に組んで実行時間を計測しなければなりませんが、パッチ処理の後にもディレイやプロファイルカーブの処理を入れられそうな予感がします。
receive(受信)、bind(入力ユニバースを内部Bus(ユニバース)にパッチ、ここで数値をマージしてHTPミキサーとします)、pre-delay、pre-profile-curve、patch、post-delay、post-profile-curve、transmit といった流れで考えています。
ついてはモジュール構成を少し変えます。
ap_transmitter の中の数値操作と Art-net の出力を分割します。
fps はともかく、すべてのユニバースを連続して送るのは避けた方がいいかなと思うので、ユニバース毎にインターバルを持たせるためです。
１）アプリの起動部とし、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値をまとめる「ap_effect」
５）Art-Net を出力する「ap_transmitter」
６）データのタイムアウト管理をする「ap_timeout」
今後はタイムラグを減らす工夫を考えてみましょう。
出力の目標は 30fps 以上、出来れば 36fps ですが、1/36秒以内に処理を一巡出来るなら遅れても1フレームとなります。無理ならスレッド的なアプローチで考えて出来るだけ遅れを少なくしましょう。
何にしても、試作をして処理時間と処理負荷の計測が必要です。
こんな複雑なシステムは10回くらい書き直すつもりで試すしかありません。素人の私が結果を完全に予測するなんで無理ですもん。
#[Art-Net] #器具の製作 #Ｃ言語
ArtNetPatch の構成イメージが見えてきました。
この後は「ap_transmitter」の具体化でしょうか。これが ArtNetPatch の核であり一番重い処理です。
モジュール間を繋ぐ構造体配列が見えればその他のモジュールを作ることは可能ですし、画面表示とか作って手ごたえを感じたいってのはありますが、最終的にデータを取りまとめる「ap_transmitter」が見えませんと構造体配列を決めることが出来ません。
#[Art-Net] #器具の製作
この後は「ap_transmitter」の具体化でしょうか。これが ArtNetPatch の核であり一番重い処理です。
モジュール間を繋ぐ構造体配列が見えればその他のモジュールを作ることは可能ですし、画面表示とか作って手ごたえを感じたいってのはありますが、最終的にデータを取りまとめる「ap_transmitter」が見えませんと構造体配列を決めることが出来ません。
#[Art-Net] #器具の製作