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

能登半島地震で被災された方々にお見舞い申し上げます。

or 管理画面へ

2022年3月5日の投稿[4件]

Icon of admin
 オレメモ

 ● Art-Netの受信の準備でするべきこと。

  ・受信のタイムアウトを定義し、タイムアウトを例外としてキチンと処理する。

 ● Art-Netを受信したらするべきこと。

  ・受信した「Art-Netのバイナリデータ」に「いつ」「どこからか(送信元)」を絡めて受信データとする。
  ・ユニバースと内部ルートの対照データを基に、データの参照キーを「ユニバース」から「ルート」に変換してキャッシュする。
  ・「いつ」をキーに送信元からの送信が無くなったと見なせるならキャッシュも含め送信元情報を消去する。
  ・「いつ」をキーにキャッシュの有効期限が切れたならキャッシュのレベル値をすべてゼロにする。
  ・送信元ごとのキャッシュをルートで丸めて一意のキャッシュにする。

#[Art-Net]
Icon of admin
 実機を離れて考えを進めると抜けが見えてきます。
 一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
 その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。

 受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
 パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。

 ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
 ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
 この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。

#Python #[Art-Net]
Icon of admin
 オレメモ

 Pythonのsocket.recvfromでタイムアウト処理をする。

 socketのインスタンスをsockとした場合、sock.recvfromの前に

 sock.settimeout(<タイムアウトの秒数>)

 とする。

 sock.recvfrom(<バッファ数>) を try: で実行し、except socket.timeout: でタイムアウトエラーを拾う。

#Python
Icon of admin
 本日は久しぶりの現地照明。現場って感じでホッとします。

 実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
 Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
 socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
 ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。

#[Art-Net]

■当面の課題

桜のライトアップの季節です。花粉症の季節でもあります。
自分は平気ですが、花粉症の部下は死にそうな顔をしています。

編集

■全文検索:

複合検索窓に切り替える

■複合検索:

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

■日付検索:

■カレンダー:

2022年3月
12345
6789101112
13141516171819
20212223242526
2728293031

■カテゴリ:

■最近の投稿:

最終更新日時:
2024年4月28日(日) 10時15分49秒