電装工芸日記
- 舞台照明機器の製作とか -
全年全月11日の投稿［35件］（3ページ目）
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
LTC Generator は24時間カウントの関数をPythonで書いてみました。限りなく本チャンに近いモノです。
期待通りの動作をします。卓への接続テストはまだですが、オシロスコープには波形が出ます。
ただ、24時間で約40秒の遅れが出ます。１時間あたり約1.7秒ですから無視出来ません。
時間のクリックカウントはPICで行っていますが、TMR1のコンペア値が１個多いと仮定すると辻褄が合います。そういえば、TMR2でコンペアと同様の機構と思われるPWMを作る場合は折り返しで１カウント余計にかかるハズ。データシートには記載が見受けられなかったけど、TMR1のコンペアモードでも同様なのかもしれません。
コンペアの定数値を変更して改めてテストしましょう。
#PIC #タイムコード
期待通りの動作をします。卓への接続テストはまだですが、オシロスコープには波形が出ます。
ただ、24時間で約40秒の遅れが出ます。１時間あたり約1.7秒ですから無視出来ません。
時間のクリックカウントはPICで行っていますが、TMR1のコンペア値が１個多いと仮定すると辻褄が合います。そういえば、TMR2でコンペアと同様の機構と思われるPWMを作る場合は折り返しで１カウント余計にかかるハズ。データシートには記載が見受けられなかったけど、TMR1のコンペアモードでも同様なのかもしれません。
コンペアの定数値を変更して改めてテストしましょう。
#PIC #タイムコード
2023年5月 この範囲を時系列順で読む この範囲をファイルに出力する
頭の区切りが付かないので、LTC-Generatorの回路図を描いてみました。
FT232RLを使ってPICにUARTを送る
→ PICで所定のbpsの差動バイフェーズ化する
→ PICの出力を分圧して約1vp-p(要は2v)にする
→ オペアンプの1:1ボルテージフォロア回路で音声信号化
→ 出力
といった簡単な構成です。
1vなので音声信号としては約+3dBです。
グランドループさせない様にした方がいのかな？
追記
気分が乗って描いてしまった基板の3D図も揚げます。
折角なので発注しました。
本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ～。
#器具の製作 #タイムコード
FT232RLを使ってPICにUARTを送る
→ PICで所定のbpsの差動バイフェーズ化する
→ PICの出力を分圧して約1vp-p(要は2v)にする
→ オペアンプの1:1ボルテージフォロア回路で音声信号化
→ 出力
といった簡単な構成です。
1vなので音声信号としては約+3dBです。
グランドループさせない様にした方がいのかな？
追記
気分が乗って描いてしまった基板の3D図も揚げます。
折角なので発注しました。
本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ～。
#器具の製作 #タイムコード
タイムコードの使用にあたり卓(MAdot2)の挙動で重要となるのは次の点です。
・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。
取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
注意点が２点あります。
１）CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
２）卓に入力されるタイムコードの有効無効を操作出来なければならない。
(1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(１曲あたり10分割振りとか)。
(2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。
一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな？
その筋に詳しい音響担当に相談していますのでしばらく待ちです。
・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ～。
#タイムコード #器具の製作
・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。
取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
注意点が２点あります。
１）CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
２）卓に入力されるタイムコードの有効無効を操作出来なければならない。
(1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(１曲あたり10分割振りとか)。
(2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。
一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな？
その筋に詳しい音響担当に相談していますのでしばらく待ちです。
・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ～。
#タイムコード #器具の製作
2023年4月 この範囲を時系列順で読む この範囲をファイルに出力する
先日ユニクロに行ったのですが、会計方法に驚いた。
いわゆるセルフレジの部類ですが、買い物カゴごと所定の場所に置くと一瞬で合計金額が出てきます。
正直「何が起こった！？」「前の人の会計ぢゃね？？」パニクリましたよ。
商品のタグをよく見たら「IC-Tag」と書いてあります。なるほどねぇ～と思いつつ、「IC-Tagってホントに安くなったんだ」とか「人件費考えたら割に合うだろうなぁ」とか「万引き防止にもなるねぇ」とか考えてしまう自分。
IC-Tagは簡単に言うなら小さい小さいwi-fiマイコンです。厳密にはwi-fiとは違うのですが、無線でデータをやりとりするって意味で捉えてください。不思議なのは電源を持っていないのに動くのです。なんでだろ！？
細かい事はわからないのですが、少し調べてみてもいいですね。
そこまでする価値があるかは別にして、機材に付けておけば数のチェックが一瞬です。時間に追われるツアーとか大量の機材を扱うところではいいかもしれません。
#雑談
いわゆるセルフレジの部類ですが、買い物カゴごと所定の場所に置くと一瞬で合計金額が出てきます。
正直「何が起こった！？」「前の人の会計ぢゃね？？」パニクリましたよ。
商品のタグをよく見たら「IC-Tag」と書いてあります。なるほどねぇ～と思いつつ、「IC-Tagってホントに安くなったんだ」とか「人件費考えたら割に合うだろうなぁ」とか「万引き防止にもなるねぇ」とか考えてしまう自分。
IC-Tagは簡単に言うなら小さい小さいwi-fiマイコンです。厳密にはwi-fiとは違うのですが、無線でデータをやりとりするって意味で捉えてください。不思議なのは電源を持っていないのに動くのです。なんでだろ！？
細かい事はわからないのですが、少し調べてみてもいいですね。
そこまでする価値があるかは別にして、機材に付けておけば数のチェックが一瞬です。時間に追われるツアーとか大量の機材を扱うところではいいかもしれません。
#雑談
プリントが終わったので仮組み。
寸法の修正はありますが一応形になりました。あと2-3回やれば条件が出るでしょう。
実際はアルミ角パイプの中にコレを入れます。
３Ｄプリンタは復活したようです。
#３Ｄプリンタ
寸法の修正はありますが一応形になりました。あと2-3回やれば条件が出るでしょう。
実際はアルミ角パイプの中にコレを入れます。
３Ｄプリンタは復活したようです。
#３Ｄプリンタ
2022年7月 この範囲を時系列順で読む この範囲をファイルに出力する
以前購入した加熱台ではリフローハンダがうまくいきません。
専用の機械を買おうかと思いましたが、ネットの書き込みを読むと「TESCOM TSF601」がイイ感じとのこと。庫内に熱風を回すタイプのコンベクションオーブンです。これで成功されている例が多いようです。
温度の管理は、盤面の温度設定だけでは不十分で、熱電対などでの実測が必要みたいです。手持ちで試して具合がいいなら専用の温度計を買いましょう。
懸念するのはハンダペーストです。溶解温度138度の低温タイプを使ったレポートが多いので購入を考えましたが今は品薄で手に入りません。185度の物は手元にあるので当面はこれで試してみましょう。
追記
帰宅して試しました。
ストップウォッチを片手にやってみましたが簡単でした。本体のリレーのカチカチ音とヒーターの発光を参考に計測します。
テストピースは3wのLED素子を秋月さんの六角アルミ基板に取り付ける作業です。
ソルダーペーストはXG-50。溶解温度185度の物です。
基板にソルダーペーストを塗ってLEDを置きます。
基板を庫内に入れ160度設定で起動します。時間管理はストップウォッチなので、TSF601のタイマは作業中に落ちない15～20分くらいの設定にします。
リレーが切れる音が鳴ってヒーターが切れたところからストップウォッチで計測します。予熱です。
90秒予熱したら温度設定ダイヤルを230度まで回します。ストップウォッチもリセットします。
温度が上がってソルダーペーストが溶け始めたところから20秒後に電源を切って網ごと取り出し冷却。
部品の耐熱限界を考えると230度に切り替えてから90秒たってもソルダーペーストが溶けない場合は失敗と思ってよさそう。この場合はハンダゴテで誤魔化すしかありません。
上記のレシピでLEDは正常に点灯しました。これでいいのかまだわかりませんが、LED素子が大丈夫なら他の部品でも良いと思われます。
さらに追記
上記のレシピではLEDの透明カバーが変形しました。低融点のソルダーペーストを使ってリフローの温度を下げる必要があると思われます。
リフローでハンダ付けしたLEDを５灯直列ツナギにし、DC24v電源のCL6807ドライブで問題無く点灯しました。電流値も設計通りです。
長時間点灯を試すにはヒートシンクを取り付けないといけません。
今日のところはヨシとします。
#電子工作
2022年6月 この範囲を時系列順で読む この範囲をファイルに出力する
新しい劇場のホール資料作りは振り出しに戻しました。試行錯誤の過程でデータのステータスがおかしくなってしまったからです。
AutoCADのデータをVectorWorks9.5に読ませることには成功したものの、VectorWorks9.5では正しく解釈が出来ないステータスがあるようで、これをどうにかしようとしたところダメなデータにしてしまったと思われます。クセが見えてきたので、あと2-3回試せば思ったように処理出来るでしょう。
手間っちゃ手間ですが、建築データを基にすれば白紙から書き起こすより早いですのでヨシとしましょう。
#本業
AutoCADのデータをVectorWorks9.5に読ませることには成功したものの、VectorWorks9.5では正しく解釈が出来ないステータスがあるようで、これをどうにかしようとしたところダメなデータにしてしまったと思われます。クセが見えてきたので、あと2-3回試せば思ったように処理出来るでしょう。
手間っちゃ手間ですが、建築データを基にすれば白紙から書き起こすより早いですのでヨシとしましょう。
#本業
2022年4月 この範囲を時系列順で読む この範囲をファイルに出力する
Art-Netを書き進めていました。
ようやく卓を２枚使える状況になったので、複数の送信元を受ける処理を試してみました。
基本的には問題なく動くのですが・・・受信するユニバース総数、いや、送信されるユニバースの総数が10以上になると動作がおかしくなります。こういった装置ですから処理できる量に限度はあるものですが、それにしても挙動がおかしい。
いろいろ試したところ、multiprocessingでプロセス間通信をするmultiprocessing.queueが遅いことによるタイミング遅れであることが判明。せっかくプロセスを分けて処理効率を上げようとしてもプロセス間の通信が遅くては本末転倒。８ユニバースくらいのデータなら扱えるものの、さらにプロセスを増やす必要があるのにこれでは困る。
Python3.8以降で追加された共有メモリが使えれば解決するっぽいけれど、現在使っているRasbianはDebian10(buster)ベースなのでPython3.7。Debian11(buleseye)ベースのRasbianに上げればPython3.9.2になるけれど、bulesyeは過去との互換性に少し難があるらしい。Pythonは動くと思うけど、他から引っ張ってくるドライバに不安がある。
プロセス間通信には他の方法もあるけれど、どの方法をとってもかなりの書き直しが必要になりそう。
トホホ気分ではありますが仕方ありません。
追記
悩んでも始まらないので、Rasbianをbullseyeにアップグレードしています。
たぶん、古い流儀を引っ張るより、最新にした方が良いと思うからです。
ダメならダメでbusterを再インストール。
#Python #[Art-Net]
ようやく卓を２枚使える状況になったので、複数の送信元を受ける処理を試してみました。
基本的には問題なく動くのですが・・・受信するユニバース総数、いや、送信されるユニバースの総数が10以上になると動作がおかしくなります。こういった装置ですから処理できる量に限度はあるものですが、それにしても挙動がおかしい。
いろいろ試したところ、multiprocessingでプロセス間通信をするmultiprocessing.queueが遅いことによるタイミング遅れであることが判明。せっかくプロセスを分けて処理効率を上げようとしてもプロセス間の通信が遅くては本末転倒。８ユニバースくらいのデータなら扱えるものの、さらにプロセスを増やす必要があるのにこれでは困る。
Python3.8以降で追加された共有メモリが使えれば解決するっぽいけれど、現在使っているRasbianはDebian10(buster)ベースなのでPython3.7。Debian11(buleseye)ベースのRasbianに上げればPython3.9.2になるけれど、bulesyeは過去との互換性に少し難があるらしい。Pythonは動くと思うけど、他から引っ張ってくるドライバに不安がある。
プロセス間通信には他の方法もあるけれど、どの方法をとってもかなりの書き直しが必要になりそう。
トホホ気分ではありますが仕方ありません。
追記
悩んでも始まらないので、Rasbianをbullseyeにアップグレードしています。
たぶん、古い流儀を引っ張るより、最新にした方が良いと思うからです。
ダメならダメでbusterを再インストール。
#Python #[Art-Net]
昨日はオフでしたが、体中が痛くて身動き取れず。
リフローハンダの試験をしたいのですが、何時になることやら・・・
今日も今日とてライトアップのバラシ。
日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
せめてArt-Netのライブラリを進めておくことにします。
#[Art-Net]
リフローハンダの試験をしたいのですが、何時になることやら・・・
今日も今日とてライトアップのバラシ。
日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
せめてArt-Netのライブラリを進めておくことにします。
#[Art-Net]
2022年3月 この範囲を時系列順で読む この範囲をファイルに出力する
Art-Netは入口の処理がまとまったので肝心のパッチ処理を考えています。
パッチとは入口と出口を１対多の関係で結びつける処理です。基本的な考え方は簡単ですがどう処理したものか。
と、言いますのも、処理の回数が多いので、１回１回の処理を限りなく軽くしないと間に合いません。
単純に考えればfor文を使ってスロット単位に移し替えをすればいいのですが、これではちょいと遅いようです。
何か無いかと調べたところnumpyに良い処理方法がありました。
「ファンシーインデックス」と呼ばれる方法です。
numpyの配列はインデックスで内容を参照できますが、インデックスに配列を使うことも出来、これを「ファンシーインデックス」と呼ぶようです。
パッチにおいては、出力側が参照する入口側のスロットのインデックスを配列にして使います(パッチマップ)。
一番単純な入力１ユニバース-出力１ユニバースを処理するとして、
入口側の配列が５スロットある場合
input = np.array( [ 11, 22, 30, 44, 50 ] )
とし、
これに対するパッチマップを
map = np.array( [ 0, 3, 4, 2, 2, 3, 1 ] )
とした場合、
patched_values = input[ map ] ※ 内部的には input[ [ 0, 3, 4, 2, 2, 3, 1 ] ] と同意
print( patched_values )
>>> [ 11 44 50 30 30 44 22 ]
インデックスの基底数がゼロなので注意が必要ですが、mapに記載されたインデックスでinputを参照し、配列としてoutputを得られます。
入力のスタック(input_stack)が[ delay, route, address ]の３次元配列の場合は、出力側スロット視点で次の３つの配列をインデックスにします。
delay_index_map：スロットごとのディレイレイヤーのインデックスを表すインデックスの配列 (取り扱いスロット数分・現在のカレントindexからオフセット済み)
※ delay_index_map = ( <ディレイレイヤーのスタック数> + <現在のカレントindex> - delay_map ) % <ディレイレイヤーのスタック数>
in_route_map：入力スロットのルートを表すインデックスの配列 (取り扱いスロット数分)
in_slot_map：入力スロットのアドレスを表すインデックスの配列 (取り扱いスロット数分)
※ in_route_mapとin_slot_mapを合わせてpatch_mapとなる。
とすると、
patched_values = input_stack[ [ delay_index_map, in_route_map, in_slot_map ] ]
patched_values は取り扱いスロット数分の１次元配列です。
ディレイの処理も含めて１行のコマンドで出力値を得られます。素晴らしい。
ここでスロットデータが１次元配列になるので、ここから先、出力ポートに渡すまではスロットを１本の通し番号で扱った方が良さそう。
同様の方法でカーブプロファイル変換も出来ます。
カーブプロファイル(curve_profile_values)を 変換後レベル値[ プロファイルナンバー, 元レベル値 ] 、カーブプロファイルマップ(curve_profile_map)をプロファイルナンバー[ スロットアドレス ]とし、変換した配列を curve_converted_values とすると。
curve_converted_values = curve_profile_values[ curve_profile_map, patched_values ]
※ len( curve_profile_map ) == len( patched_values ) がTrueなこと。
curve_converted_valuesを出力ルートとスロットアドレスの２次元配列にするなら、
output_values = curve_converted_values.reshape( <ルートの本数>, 512 )
※ <ルートの本数> × 512 = 取り扱いスロット総数 であること
コマンドが少ないから処理時間が短いとは限りませんが、少なくともfor文を用いた処理より軽いことは間違いありません。
numpy素晴らしい。
#Python #[Art-Net]
パッチとは入口と出口を１対多の関係で結びつける処理です。基本的な考え方は簡単ですがどう処理したものか。
と、言いますのも、処理の回数が多いので、１回１回の処理を限りなく軽くしないと間に合いません。
単純に考えればfor文を使ってスロット単位に移し替えをすればいいのですが、これではちょいと遅いようです。
何か無いかと調べたところnumpyに良い処理方法がありました。
「ファンシーインデックス」と呼ばれる方法です。
numpyの配列はインデックスで内容を参照できますが、インデックスに配列を使うことも出来、これを「ファンシーインデックス」と呼ぶようです。
パッチにおいては、出力側が参照する入口側のスロットのインデックスを配列にして使います(パッチマップ)。
一番単純な入力１ユニバース-出力１ユニバースを処理するとして、
入口側の配列が５スロットある場合
input = np.array( [ 11, 22, 30, 44, 50 ] )
とし、
これに対するパッチマップを
map = np.array( [ 0, 3, 4, 2, 2, 3, 1 ] )
とした場合、
patched_values = input[ map ] ※ 内部的には input[ [ 0, 3, 4, 2, 2, 3, 1 ] ] と同意
print( patched_values )
>>> [ 11 44 50 30 30 44 22 ]
インデックスの基底数がゼロなので注意が必要ですが、mapに記載されたインデックスでinputを参照し、配列としてoutputを得られます。
入力のスタック(input_stack)が[ delay, route, address ]の３次元配列の場合は、出力側スロット視点で次の３つの配列をインデックスにします。
delay_index_map：スロットごとのディレイレイヤーのインデックスを表すインデックスの配列 (取り扱いスロット数分・現在のカレントindexからオフセット済み)
※ delay_index_map = ( <ディレイレイヤーのスタック数> + <現在のカレントindex> - delay_map ) % <ディレイレイヤーのスタック数>
in_route_map：入力スロットのルートを表すインデックスの配列 (取り扱いスロット数分)
in_slot_map：入力スロットのアドレスを表すインデックスの配列 (取り扱いスロット数分)
※ in_route_mapとin_slot_mapを合わせてpatch_mapとなる。
とすると、
patched_values = input_stack[ [ delay_index_map, in_route_map, in_slot_map ] ]
patched_values は取り扱いスロット数分の１次元配列です。
ディレイの処理も含めて１行のコマンドで出力値を得られます。素晴らしい。
ここでスロットデータが１次元配列になるので、ここから先、出力ポートに渡すまではスロットを１本の通し番号で扱った方が良さそう。
同様の方法でカーブプロファイル変換も出来ます。
カーブプロファイル(curve_profile_values)を 変換後レベル値[ プロファイルナンバー, 元レベル値 ] 、カーブプロファイルマップ(curve_profile_map)をプロファイルナンバー[ スロットアドレス ]とし、変換した配列を curve_converted_values とすると。
curve_converted_values = curve_profile_values[ curve_profile_map, patched_values ]
※ len( curve_profile_map ) == len( patched_values ) がTrueなこと。
curve_converted_valuesを出力ルートとスロットアドレスの２次元配列にするなら、
output_values = curve_converted_values.reshape( <ルートの本数>, 512 )
※ <ルートの本数> × 512 = 取り扱いスロット総数 であること
コマンドが少ないから処理時間が短いとは限りませんが、少なくともfor文を用いた処理より軽いことは間違いありません。
numpy素晴らしい。
#Python #[Art-Net]