全年3月10日の投稿(時系列順)[3件]
2022年 この範囲を新しい順で読む この範囲をファイルに出力する
Art-Netを受信してから一時保存する流れ
● Art-Netの受信・・・タイムアウトしたらすべての受信情報を初期化する
● 受信日時の取得
● 受信したバイナリをデコード
● 対象ユニバースか確認
● ルートIDを取得
● 送信元のIDを取得・新規送信元なら保存し送信元IDを取得
● 送信元の最終受信日時を上書き保存
● 送信元,ルートの最終受信日時を上書き保存
● 送信元,ルートで受信値を上書き保存(必ず512スロットで保存)
タイムアウト処理・・・0.2~0.5秒毎
● 送信元のタイムアウトを確認・・・タイムアウトしていたら送信元からの受信情報を初期化する
● ユニバースのタイムアウトを確認・・・タイムアウトしていたらユニバースをゼロデータにする
次工程からの読み出し要求への返信
● 送信元,ルートで保存した受信値から最大値を取り出す
● 返信
といった感じで、細かいコマンド処理とアルゴリズムが見えてきましたが、本業が忙しくなってソースを書くことが出来ません。
#Python #[Art-Net]
● Art-Netの受信・・・タイムアウトしたらすべての受信情報を初期化する
● 受信日時の取得
● 受信したバイナリをデコード
● 対象ユニバースか確認
● ルートIDを取得
● 送信元のIDを取得・新規送信元なら保存し送信元IDを取得
● 送信元の最終受信日時を上書き保存
● 送信元,ルートの最終受信日時を上書き保存
● 送信元,ルートで受信値を上書き保存(必ず512スロットで保存)
タイムアウト処理・・・0.2~0.5秒毎
● 送信元のタイムアウトを確認・・・タイムアウトしていたら送信元からの受信情報を初期化する
● ユニバースのタイムアウトを確認・・・タイムアウトしていたらユニバースをゼロデータにする
次工程からの読み出し要求への返信
● 送信元,ルートで保存した受信値から最大値を取り出す
● 返信
といった感じで、細かいコマンド処理とアルゴリズムが見えてきましたが、本業が忙しくなってソースを書くことが出来ません。
#Python #[Art-Net]
2023年 この範囲を新しい順で読む この範囲をファイルに出力する
クリアカムのパワーサプライは付属品とする電源ケーブルが入荷したので長時間起動チェックをしました。
実際の使用機器で長時間通電しておくのは重要なチェックの一つです。10時間くらい通電しましたが大丈夫っぽいです。
#電子工作
実際の使用機器で長時間通電しておくのは重要なチェックの一つです。10時間くらい通電しましたが大丈夫っぽいです。
#電子工作
2024年 この範囲を新しい順で読む この範囲をファイルに出力する
共有メモリの読み書きのタイミングを考えています。
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は1プロセスで動作します。RaspberryPiでも1プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#C言語
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は1プロセスで動作します。RaspberryPiでも1プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#C言語