電装工芸日記
- 舞台照明機器の製作とか -
全年全月8日の投稿［26件］
2024年4月 この範囲を時系列順で読む この範囲をファイルに出力する
RaspberryPi トランクは基礎機能の実装が終わりました。
今後は仕込品のレイアウトを考えます。ガサガザ突っ込むワケにもいきませんので、何か基本的なマウントを考えたいものです。
#RaspberryPi
今後は仕込品のレイアウトを考えます。ガサガザ突っ込むワケにもいきませんので、何か基本的なマウントを考えたいものです。
#RaspberryPi
2024年2月 この範囲を時系列順で読む この範囲をファイルに出力する
合間を見ては自宅の重清掃を続けています。
次のオフに換気扇にチャレンジしますが、その前の練習を兼ねてオーブントースターの清掃。換気扇程ではありませんが同様の汚れ。油が焼き付いています。キレイにならなきゃ買い替えのつもり。
可能な限り分解し、先端にブラシを付けたスチームクリーナーでゴシゴシ。粉石鹸を溶いた溶液をブラシに付けながらやると案外落ちるものです。
大物の汚れをザックリ落としましたので漬け置きです。お湯で溶いた粉石鹸に漬け込みます。
掃除というよりオーバーホールになってます。
#器具の修理
次のオフに換気扇にチャレンジしますが、その前の練習を兼ねてオーブントースターの清掃。換気扇程ではありませんが同様の汚れ。油が焼き付いています。キレイにならなきゃ買い替えのつもり。
可能な限り分解し、先端にブラシを付けたスチームクリーナーでゴシゴシ。粉石鹸を溶いた溶液をブラシに付けながらやると案外落ちるものです。
大物の汚れをザックリ落としましたので漬け置きです。お湯で溶いた粉石鹸に漬け込みます。
掃除というよりオーバーホールになってます。
#器具の修理
2023年11月 この範囲を時系列順で読む この範囲をファイルに出力する
2023年9月 この範囲を時系列順で読む この範囲をファイルに出力する
FT232RLで一般的なシリアル通信以外のことをするにはドライバを直接叩かないといけないらしい。250kbps 送信と長い長い BreakTime を生成するには ＯＳ のシリアルを叩いても不可能ですからね。
FT232RL のメーカーである FTDI のサイトに D2XX Programmer’s Guide がありました。これが理解出来ればいいのでしょうが全く理解出来ません。
Open DMX USB の Python ライブラリが落ちていました。これなら理解できます。
「PyFtdi」
次の使用例はとてもわかりやすい。
「jlbrogdon/dmx_controller」
細かい例外対策まで仕上げるには PyFtdi の API documentation を熟読しなければなりませんが、本丸が見えればナンとかなりそうな気分になります。
PyFtdi の世代の問題なのか、少し手直しをしないとエラーになります。
・・・注意：READMEを読み返したらコレは RaspberryPi 向けに書いたモノだとか。動かなくても不思議はありません。
Open DMX USB の回路図はこちらがわかりやすい。
「菅工房 Open DMX USB」
汎用の FT232RL 基板を使うならここが参考になります。
「Open DMX USB コントローラによる DMX512制御」
汎用の FT232RL にほんの少し設定を加えるだけで Open DMX UASB として使えます。FT232RL の電気特性は UART なので RS485 に変換する必要はあります。
忘れちゃいけない本家。
「ENTTEC Open DMX USB」
「D2XX Programmer's Guide」
習作ですので急ぐつもりはありませんしアイデアだけで終わるかもしれませんが、Open DMX USB を扱えたら応用の幅がありそうな予感はあります。テンキーでガツガツ打てて、MIDI でクロスフェーダーやサブマスターまで組めたらいいかなと。
ホール卓のPC版ってのもネタとして面白いかも。「KOYATAKU」とでも名付けます？。ホール卓の基本構成をパソコンで構成してフリーウェアにしたらメーカーさんに嫌がられるでしょうけど、10年間違いなく動くのがメーカーさんのクウォリティであって、ここを真似するのは絶対不可能な領域です。
#器具の製作
FT232RL のメーカーである FTDI のサイトに D2XX Programmer’s Guide がありました。これが理解出来ればいいのでしょうが全く理解出来ません。
Open DMX USB の Python ライブラリが落ちていました。これなら理解できます。
「PyFtdi」
次の使用例はとてもわかりやすい。
「jlbrogdon/dmx_controller」
細かい例外対策まで仕上げるには PyFtdi の API documentation を熟読しなければなりませんが、本丸が見えればナンとかなりそうな気分になります。
PyFtdi の世代の問題なのか、少し手直しをしないとエラーになります。
・・・注意：READMEを読み返したらコレは RaspberryPi 向けに書いたモノだとか。動かなくても不思議はありません。
Open DMX USB の回路図はこちらがわかりやすい。
「菅工房 Open DMX USB」
汎用の FT232RL 基板を使うならここが参考になります。
「Open DMX USB コントローラによる DMX512制御」
汎用の FT232RL にほんの少し設定を加えるだけで Open DMX UASB として使えます。FT232RL の電気特性は UART なので RS485 に変換する必要はあります。
忘れちゃいけない本家。
「ENTTEC Open DMX USB」
「D2XX Programmer's Guide」
習作ですので急ぐつもりはありませんしアイデアだけで終わるかもしれませんが、Open DMX USB を扱えたら応用の幅がありそうな予感はあります。テンキーでガツガツ打てて、MIDI でクロスフェーダーやサブマスターまで組めたらいいかなと。
ホール卓のPC版ってのもネタとして面白いかも。「KOYATAKU」とでも名付けます？。ホール卓の基本構成をパソコンで構成してフリーウェアにしたらメーカーさんに嫌がられるでしょうけど、10年間違いなく動くのがメーカーさんのクウォリティであって、ここを真似するのは絶対不可能な領域です。
#器具の製作
2023年8月 この範囲を時系列順で読む この範囲をファイルに出力する
LTC のフレーム値の計算で悩む。
ノンドロップフレームなら簡単ですが、29.97fpsドロップフレームではそうもいきません。実時間とタイムコードの値が合うのは１時間ごと、つまり途中は実時間とズレるのです。タイムコードは映像のフレームに時間形式のナンバリングを与える手法であって実時間を表す物ではありませんので仕方ありません。ズレがあるとしてもフレームナンバーをゼロからカウントするのは何も問題ありませんが、不特定の時間値からカウントされる場合に漠然とした疑問があるワケです。
困っていても仕方がないので条件を整理しましょう。
10分単位で考えてみます。
30fpsなら10分で18,000フレームです。29.97fpsドロップフレームは10分の間に18カウントを落としますので17,982フレームです。フレーム長の伸縮比1.001を掛けますと17,999.92となり、時間差は0.08フレームです。秒に直すと0.0026秒くらいの誤差です。そんなに大きな値ではありませんねぇ。見た目にわかる人は皆無ですからあんまり気にしなくてよくね？
となると、基準点(時毎もしくは10分毎)からのフレーム数を出し、このフレーム数からタイムコード値を得ればいいんでないか？大げさな感じもしますが、時間値で計算すると奇妙な繰り下がりが発生して計算が面倒だからです。30fpsの24時間分のフレーム数は 2,592,000 ですから32bitの整数でも十分管理出来ます。時間からフレームの枚数目を得る関数とフレームの枚数目から時間を得る関数を作っておけばどうにでもなりそう。
ここまでやれば、都度の誤差は人が感知出来ないレベルに収まると思います。
#タイムコード
ノンドロップフレームなら簡単ですが、29.97fpsドロップフレームではそうもいきません。実時間とタイムコードの値が合うのは１時間ごと、つまり途中は実時間とズレるのです。タイムコードは映像のフレームに時間形式のナンバリングを与える手法であって実時間を表す物ではありませんので仕方ありません。ズレがあるとしてもフレームナンバーをゼロからカウントするのは何も問題ありませんが、不特定の時間値からカウントされる場合に漠然とした疑問があるワケです。
困っていても仕方がないので条件を整理しましょう。
10分単位で考えてみます。
30fpsなら10分で18,000フレームです。29.97fpsドロップフレームは10分の間に18カウントを落としますので17,982フレームです。フレーム長の伸縮比1.001を掛けますと17,999.92となり、時間差は0.08フレームです。秒に直すと0.0026秒くらいの誤差です。そんなに大きな値ではありませんねぇ。見た目にわかる人は皆無ですからあんまり気にしなくてよくね？
となると、基準点(時毎もしくは10分毎)からのフレーム数を出し、このフレーム数からタイムコード値を得ればいいんでないか？大げさな感じもしますが、時間値で計算すると奇妙な繰り下がりが発生して計算が面倒だからです。30fpsの24時間分のフレーム数は 2,592,000 ですから32bitの整数でも十分管理出来ます。時間からフレームの枚数目を得る関数とフレームの枚数目から時間を得る関数を作っておけばどうにでもなりそう。
ここまでやれば、都度の誤差は人が感知出来ないレベルに収まると思います。
#タイムコード
2023年6月 この範囲を時系列順で読む この範囲をファイルに出力する
オレメモ
windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew
２回くらいやった方がいい。
#パソコン
windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew
２回くらいやった方がいい。
#パソコン
2023年4月 この範囲を時系列順で読む この範囲をファイルに出力する
Linux上のＣ言語でLTCの波形を起こせたらと思ったのですが、処理能力の総量は余裕タップリなものの、Art-Netエンジンを作った際に感じた挙動ムラから想像するに許容範囲を越える波形ムラが起こりそうです。LinuxはOSそのものや他のモジュールに引っ張られて100～300usecくらい待たされることがあるのですが、LTCの波形を起こすのにこの条件はよろしくありません。RTOSを使わないなら普通のことですけどね。
ならばLTCを起こすところにはPICを使ったらいいかな？適材適所？
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。２～４フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは１フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作
ならばLTCを起こすところにはPICを使ったらいいかな？適材適所？
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。２～４フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは１フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作
ホール管理の増員で操作盤の置物になっているだけなので調べモノをし放題です。
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
2023年1月 この範囲を時系列順で読む この範囲をファイルに出力する
ランチャーに行く前にscoketの基本動作の確認かな？
受信したArt-Netパケットをそのまま送信する実験。
これが求める機能の基本ですから確認せんといかん。
#[Art-Net] #Ｃ言語
受信したArt-Netパケットをそのまま送信する実験。
これが求める機能の基本ですから確認せんといかん。
#[Art-Net] #Ｃ言語
共有メモリの衝突回避ですが、共有メモリの中にハンドシェイク表すフラグを入れたらそれでいいんじゃないかと。
そのフラグが立っていれば極々わずかな時間sleepを繰り返す処理です。
while(flag1 == 1)
{
sleep(0.001);
}
flag2 = 1;
/* 共有メモリ処理 */
flag2 = 0;
みたいなものです。
別プロセスがフラグを0にすればwhileを抜けます。
簡易的なモノですが、フラグを書き換えられるプロセスを一つにしておけばイイんじゃないかと。最も簡単なセマフォはこういうことですし。
子プロセスの停止制御も同様の考え方が使えます。
動作し続けるってことは繰り返し処理です。単なる繰り返しはwhile(1)とかで無限ループすることが多いので、while(flag==1)とかにすればいい。共有メモリ上のフラグが1ならwhileでループし0になったら抜ければいいのです。抜けたら終了処理をしてプロセスを落とすと。子プロセスが完全に終わったことはスタックしておいたプロセスIDを見ればわかります。
この辺りまで決まれば次はランチャーです。
#Ｃ言語
そのフラグが立っていれば極々わずかな時間sleepを繰り返す処理です。
while(flag1 == 1)
{
sleep(0.001);
}
flag2 = 1;
/* 共有メモリ処理 */
flag2 = 0;
みたいなものです。
別プロセスがフラグを0にすればwhileを抜けます。
簡易的なモノですが、フラグを書き換えられるプロセスを一つにしておけばイイんじゃないかと。最も簡単なセマフォはこういうことですし。
子プロセスの停止制御も同様の考え方が使えます。
動作し続けるってことは繰り返し処理です。単なる繰り返しはwhile(1)とかで無限ループすることが多いので、while(flag==1)とかにすればいい。共有メモリ上のフラグが1ならwhileでループし0になったら抜ければいいのです。抜けたら終了処理をしてプロセスを落とすと。子プロセスが完全に終わったことはスタックしておいたプロセスIDを見ればわかります。
この辺りまで決まれば次はランチャーです。
#Ｃ言語