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

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

or 管理画面へ

全年2月6日の投稿[3件]

2023年 この範囲を時系列順で読む この範囲をファイルに出力する

Icon of admin
 本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。

 ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、8ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、8ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。

 現時点での1フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん?。
 作りたい物にはなりそうですが、8ユニバース8卓(64ユニバース入力)は厳しい気がします。これに対応するには1フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は8台ですが、同時に使える(HTPミックスの対象となる)のを3-4台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは40ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
 どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。

 ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。

追記
 調整したところ、1ユニバース受信する1フェーズが平均30usec、例外値が200usec程度になりました。
 同時に8卓使っても1本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
 送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。

#[Art-Net] #C言語
Icon of admin
 本業もやらねばなりませんがArtNet-Engineも進めたい。
 ArtNet-Engineの課題はデータ処理の構成です。

 まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
 送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
 フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
 内部的には8ユニバースのパッチを考えていますが卓も8台想定します。64ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
 当面は送信元の仕分けと64ユニバースを8ユニバースにマージする処理を書きます。

 処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
 Pythonとは違い、for文が速いC言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。C言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。

#[Art-Net] #C言語

2022年 この範囲を時系列順で読む この範囲をファイルに出力する

Icon of admin
 ANSIエスケープシーケンスですが、RaspberryPi上のPythonでは期待する動画が出来ないかもしれません。形にはなるのですがチラつきます。
 開発作業用と画面の試作を兼ねてDMXスロットの値を一覧表示する画面を作っています。値の表示は遅くとも0.1~0.2秒くらいで更新しなければなりませんが、前の表示が完了していないのに次の表示が実行されているような感じで、行単位での一瞬の点滅が不規則に発生します。
 細かいことはともかく、これではダメです。

 動画を表示出来るのですからテキスト画面の更新を0.1秒間隔でやるなど楽勝だろうと思っていたのですが、そもそもテキスト表示の書き換えにこんなレスポンスは不要だと作られているのかもしれません。
 基本的な動作だけに余裕を持って動いてくれないと困ります。

 RaspberryPiの作り的に、ANSIエスケープシーケンスでテキスト画面を構成するより、グラフィカルな画面に今どきの方法で表を書いた方がいいのかもしれません。

#RaspberryPi #Python

■思ってみた

ようやく秋っぽくなりました。
涼しいというか暑くないのは幸い。

編集

■全文検索:

複合検索窓に切り替える

■複合検索:

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

■日付検索:

■カレンダー:

2023年2月
1234
567891011
12131415161718
19202122232425
262728

■カテゴリ:

■最近の投稿:

最終更新日時:
2024年10月29日(火) 17時39分07秒