電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-Net」を含む投稿［93件］（3ページ目）
各所の処理タイミングで難儀しましたが、第１フェーズと呼んでもいい段階は終わりました。
まとまったのは次の通り。
１）Art-Netを受信してデコード。
２）エンコードして送信。
３）受信値を表示。
４）カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
スッキリした画面に値がキレイに表示されると気持ち良いです。
ちなみに、画面表示を除く主処理１フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。
次はデータ処理の本丸です。
Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。
追記
処理タイミングを調整したところ１フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
不思議なのは、受信している８ユニバース中、０ユニバースに比べ７ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは１フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。
#[Art-Net]
まとまったのは次の通り。
１）Art-Netを受信してデコード。
２）エンコードして送信。
３）受信値を表示。
４）カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
スッキリした画面に値がキレイに表示されると気持ち良いです。
ちなみに、画面表示を除く主処理１フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。
次はデータ処理の本丸です。
Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。
追記
処理タイミングを調整したところ１フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
不思議なのは、受信している８ユニバース中、０ユニバースに比べ７ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは１フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。
#[Art-Net]
Art-Netの入口と出口は出来ましたので機能を組みます。Ｃ言語に替えた為に処理能力に余裕が出て複座なプロセス処理を多用しなくても良さそうですが、そもそもの処理をどうするか吟味しないといけません。
搭載予定の機能は、ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)です。スタックフェーダー機能はミキサー機能に含まれます。
さて、どうしようかな。
#[Art-Net] #Ｃ言語
搭載予定の機能は、ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)です。スタックフェーダー機能はミキサー機能に含まれます。
さて、どうしようかな。
#[Art-Net] #Ｃ言語
Art-Netのデコード/エンコードも出来ました。受信した１配列のバイナリデータを分類して構造体に取り込むのがデコード、項目別の構造体から送信用のバイナリデータに変換するのがエンコードです。
実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを１つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
今のところ製作は順調です。３月末までに１日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。
#[Art-Net] #Ｃ言語
実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを１つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
今のところ製作は順調です。３月末までに１日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。
#[Art-Net] #Ｃ言語
Art-Netの送信にも成功しました。
受信値を転送するだけですが、Art-Netデコーダから正常と思われる値が出力されています。
今日は終わりにしますが、大きな課題がクリア出来て大満足です。
ただ、８ユニバースを出力しているdot2が一杯いっぱいの様子。発熱も凄いし画面もコマ送りです。
ちなみにですが、recvfrom()の４番目のパラメータを「MSG_DONTWAIT」にすると受信待ちしません。先達の例では待ちアリの「0」を定義してioctl()に待ち無し(ノンブロッキング)を設定していることが多いのですが、「MSG_DONTWAIT」を使った方がストレスが無い感じ。
で、気付いたのですが、Ｃ言語は速い。速いが故の対策が必要になる始末。受送信テストでは終了のためのキー入力やタイムアウトを入れるのが面倒だったのでfor文による一定回数の繰り返しで試したのですが、受信待ちを無くした後はPythonでの実験の際に使った回数では一瞬で終わってしまいます。プログラムが間違っているのかと思う程でした。てことは、あまりにも無意味な回数recvfrom()を呼んでいることになりますので、受信が無い場合は100～500usecくらい待ちを入れた方がいいみたいです。バッファを読みに行っているだけなので気にしなくていいって話もありますが、ANSIエスケープシーケンスを用いた画面表示も適度な待ちを入れないと画面がフリッカーを起こす程です。数か月かかりましたが、Ｃ言語を勉強して良かったと思います。遅いのを対策するのは大変ですが、速いのを抑え込むのは比較的簡単ですからね。
ここまで速いとマルチプロセスを使わなくてもいいのではないか？って気持ちも芽生えます。使った方が速さ以外に都合が良いこともあるので使いますケド。
基本的な受送信が確認出来ましたので、関数化しつつArt-Net(正しくはArt-DMX)のデコード/エンコードも書きましょう。
#[Art-Net] #Ｃ言語
受信値を転送するだけですが、Art-Netデコーダから正常と思われる値が出力されています。
今日は終わりにしますが、大きな課題がクリア出来て大満足です。
ただ、８ユニバースを出力しているdot2が一杯いっぱいの様子。発熱も凄いし画面もコマ送りです。
ちなみにですが、recvfrom()の４番目のパラメータを「MSG_DONTWAIT」にすると受信待ちしません。先達の例では待ちアリの「0」を定義してioctl()に待ち無し(ノンブロッキング)を設定していることが多いのですが、「MSG_DONTWAIT」を使った方がストレスが無い感じ。
で、気付いたのですが、Ｃ言語は速い。速いが故の対策が必要になる始末。受送信テストでは終了のためのキー入力やタイムアウトを入れるのが面倒だったのでfor文による一定回数の繰り返しで試したのですが、受信待ちを無くした後はPythonでの実験の際に使った回数では一瞬で終わってしまいます。プログラムが間違っているのかと思う程でした。てことは、あまりにも無意味な回数recvfrom()を呼んでいることになりますので、受信が無い場合は100～500usecくらい待ちを入れた方がいいみたいです。バッファを読みに行っているだけなので気にしなくていいって話もありますが、ANSIエスケープシーケンスを用いた画面表示も適度な待ちを入れないと画面がフリッカーを起こす程です。数か月かかりましたが、Ｃ言語を勉強して良かったと思います。遅いのを対策するのは大変ですが、速いのを抑え込むのは比較的簡単ですからね。
ここまで速いとマルチプロセスを使わなくてもいいのではないか？って気持ちも芽生えます。使った方が速さ以外に都合が良いこともあるので使いますケド。
基本的な受送信が確認出来ましたので、関数化しつつArt-Net(正しくはArt-DMX)のデコード/エンコードも書きましょう。
#[Art-Net] #Ｃ言語
Art-Netの受信に成功しました。
先達の情報をいくつか合成しましたが、思った以上に簡単でした。
ネットワークインターフェースの指定も出来ました。
一安心ですが、次は送信しないといけません。
デコード/エンコードをせずに受信値をリレーするだけですが、これが成功しないようでは受信値を加工する努力をしても意味がありません。
#[Art-Net]
先達の情報をいくつか合成しましたが、思った以上に簡単でした。
ネットワークインターフェースの指定も出来ました。
一安心ですが、次は送信しないといけません。
デコード/エンコードをせずに受信値をリレーするだけですが、これが成功しないようでは受信値を加工する努力をしても意味がありません。
#[Art-Net]
てなわけで、socketの実験に入る下準備が整いました。Pythonで出来たことですからＣ言語(gcc)で出来ないことではないでしょう。
Art-Netエンジンを構成するにはFIFOというか循環配列というかリングキャッシュというかQueueも勉強しないとけません。例えば1024個の配列を作ったとして、これがリング状に繋がったイメージで使います。1024で折り返すカウンタを使って配列の基点位置を表すだけですが、カウンタの計算モジュールだけでもライブラリ化しないと面倒かなと。
これはDelayで必要な機能です。一定の時間間隔でDMXのデータを保存し続ければ配列サイズが許す範囲で過去情報を取り出せます。つまりDelayになります。受信毎の保存でないことが肝ですが、往年のテープエコーと要領は同じです。
Ｃ言語はボチボチ書けるようになってきましたし、先達の情報も読み取れるようになってきました。パッチマシンとしての完成は先としても、この閑散期にArt-Netエンジンだけでも完成させたいです。
あとは、コマンド入力と処理の方法も考えないといけません。
ルールマップに基づいた入力制限とか、入力されたコマンドや数値のスタック方法とか、それの表示とかです。入力値はコマンドと数値の文字列で処理関数に渡すつもりですが、それをどの様に解析して実行するかも案外難しい。
#[Art-Net] #Ｃ言語
Art-Netエンジンを構成するにはFIFOというか循環配列というかリングキャッシュというかQueueも勉強しないとけません。例えば1024個の配列を作ったとして、これがリング状に繋がったイメージで使います。1024で折り返すカウンタを使って配列の基点位置を表すだけですが、カウンタの計算モジュールだけでもライブラリ化しないと面倒かなと。
これはDelayで必要な機能です。一定の時間間隔でDMXのデータを保存し続ければ配列サイズが許す範囲で過去情報を取り出せます。つまりDelayになります。受信毎の保存でないことが肝ですが、往年のテープエコーと要領は同じです。
Ｃ言語はボチボチ書けるようになってきましたし、先達の情報も読み取れるようになってきました。パッチマシンとしての完成は先としても、この閑散期にArt-Netエンジンだけでも完成させたいです。
あとは、コマンド入力と処理の方法も考えないといけません。
ルールマップに基づいた入力制限とか、入力されたコマンドや数値のスタック方法とか、それの表示とかです。入力値はコマンドと数値の文字列で処理関数に渡すつもりですが、それをどの様に解析して実行するかも案外難しい。
#[Art-Net] #Ｃ言語
キー入力の処理が出来ましたが、願わくば押し下げと解放も拾いたいところではあります。
ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。
socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
では、得たASCIIテキストをどう処理するかです。
入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな？
#[Art-Net] #Ｃ言語
ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。
socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
では、得たASCIIテキストをどう処理するかです。
入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな？
#[Art-Net] #Ｃ言語
オレメモであります。
参考になりそうな先達のページ
● UDP/IP通信全体の参考
UDP / IP でパケットの送受信を行う
● broadcast通信の参考
UDPブロードキャスト送信サンプル
● ネットワークデバイスを指定した通信の参考
Ethernetインターフェース(eth0, eth1)を指定してソケットを作成する (Linux, C, Raspberry Pi)
● 受信タイムアウトの参考
selectを使用してタイムアウト付き受信を実現する <= recvもrecvfromも受信があるまでひたすら待ち続けるので、タイムアウトさせることは必須。
UDP通信におけるselectの使い方。 <= recvの例が多い中、recvfromの書式を確認出来る。recvfromを使う理由は送信元アドレスを取得したいから。
● 時間の扱い方
時間情報の取得方法と扱い方 <= これの５ページ目の「POSIX環境」が結構大事。DelayをするにもDMXのタイムアウトをするにもこれが必要。
● ターミナルの行長と行数を取得する
ターミナルのサイズを取得する
ターミナルの幅と高さを得る
● ANSIエスケープシーケンス
ANSIエスケープシーケンス チートシート
この辺りを参考にすれば「ネットワークデバイスを指定してbroadcastで通信する」が出来そうな気がします。
ただし、１行々々読み込んで使われている構造体をよく把握することが大切です。構造体の中に必要な情報が隠れていることが多いからです。構造体の中に構造体があったりもするので、十分に読み込まないといけません。
実験は受信が当面の課題となり、
１）ネットワークデバイスを指定せずArt-Netを受信する。<= とにかく受信する
２）ネットワークデバイスを指定してArt-Netを受信する。<= ネットワークデバイスを制限して受信する。
３）送信元IPアドレスを取得し、IPアドレスをもとに受信値を振り分ける。<= 複数の送信元(卓)がある場合の不確実性排除とミックス処理のためには不可欠。
といった手順で進めることになろうかと思います。
受信値を確認するため、習作を兼ね、バイナリをダンプ表示をするライブラリも作ってみましょう。
#Ｃ言語 #[Art-Net]
参考になりそうな先達のページ
● UDP/IP通信全体の参考
UDP / IP でパケットの送受信を行う
● broadcast通信の参考
UDPブロードキャスト送信サンプル
● ネットワークデバイスを指定した通信の参考
Ethernetインターフェース(eth0, eth1)を指定してソケットを作成する (Linux, C, Raspberry Pi)
● 受信タイムアウトの参考
selectを使用してタイムアウト付き受信を実現する <= recvもrecvfromも受信があるまでひたすら待ち続けるので、タイムアウトさせることは必須。
UDP通信におけるselectの使い方。 <= recvの例が多い中、recvfromの書式を確認出来る。recvfromを使う理由は送信元アドレスを取得したいから。
● 時間の扱い方
時間情報の取得方法と扱い方 <= これの５ページ目の「POSIX環境」が結構大事。DelayをするにもDMXのタイムアウトをするにもこれが必要。
● ターミナルの行長と行数を取得する
ターミナルのサイズを取得する
ターミナルの幅と高さを得る
● ANSIエスケープシーケンス
ANSIエスケープシーケンス チートシート
この辺りを参考にすれば「ネットワークデバイスを指定してbroadcastで通信する」が出来そうな気がします。
ただし、１行々々読み込んで使われている構造体をよく把握することが大切です。構造体の中に必要な情報が隠れていることが多いからです。構造体の中に構造体があったりもするので、十分に読み込まないといけません。
実験は受信が当面の課題となり、
１）ネットワークデバイスを指定せずArt-Netを受信する。<= とにかく受信する
２）ネットワークデバイスを指定してArt-Netを受信する。<= ネットワークデバイスを制限して受信する。
３）送信元IPアドレスを取得し、IPアドレスをもとに受信値を振り分ける。<= 複数の送信元(卓)がある場合の不確実性排除とミックス処理のためには不可欠。
といった手順で進めることになろうかと思います。
受信値を確認するため、習作を兼ね、バイナリをダンプ表示をするライブラリも作ってみましょう。
#Ｃ言語 #[Art-Net]
RTCを装着したRaspberryPiは正常のようです。
今後製作する装置にもRTCを装着したいのですが、電池切れをどうやって拾うか思案中です。
socketの実験は連休中に時間が取れず未対応です。
Art-Netの受信と送信を１台でこなすにはIPアドレス的には同じゾーンで装置は別という変な構成になります。その上、broadcastで受けてbroadcastで送るというこれもまた変な構成です。ですので、コピペで使える先例がありそうでありません。
RaspberryPiのPythonでは成功していることですから可能だと思いますが、Ｃ言語のsocketの方が設定すべきパラメータが多いため、Pythonには無かった設定をどうするかが難問なのです。難しいというより、「ネットワークデバイスを指定してbroadcastで通信する」という前提の先例が少なく、沢山のデータシートを継ぎハギしないと見えないことが多いために苦心しているところです。
#RaspberryPi #Ｃ言語 #[Art-Net]
今後製作する装置にもRTCを装着したいのですが、電池切れをどうやって拾うか思案中です。
socketの実験は連休中に時間が取れず未対応です。
Art-Netの受信と送信を１台でこなすにはIPアドレス的には同じゾーンで装置は別という変な構成になります。その上、broadcastで受けてbroadcastで送るというこれもまた変な構成です。ですので、コピペで使える先例がありそうでありません。
RaspberryPiのPythonでは成功していることですから可能だと思いますが、Ｃ言語のsocketの方が設定すべきパラメータが多いため、Pythonには無かった設定をどうするかが難問なのです。難しいというより、「ネットワークデバイスを指定してbroadcastで通信する」という前提の先例が少なく、沢山のデータシートを継ぎハギしないと見えないことが多いために苦心しているところです。
#RaspberryPi #Ｃ言語 #[Art-Net]
珍しく明日から３連休。すべてを自由に使えるワケではありませんがscocketのテストが出来そう。
Art-Netを扱える卓に繋いで実験しなければなりませんので場所が限られるのです。
#[Art-Net]
Art-Netを扱える卓に繋いで実験しなければなりませんので場所が限られるのです。
#[Art-Net]