https://www.densokogei.jp/tegalog/tegalog.cgi ja Copyright 2026 Tue, 21 Apr 2026 06:51:15 +0900 Powered by てがろぐ Ver 3.4.0 ]]>
１）アプリの起動部で、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値まとめ、Art-Net を出力する「ap_transmitter」
５）データのタイムアウト管理をする「ap_timeout」

　大きなデータは共有メモリ「mmap」と「semaphore」でやりとりし、指示や返答は「queue」で繋げます。自分ナリに得手不得手を検討した結果です。

　タイムアウトを別枠で勝手にやらせる発想が出たら役割分担が楽になりました。
　これが出来るのも共有メモリとセマフォのオカゲです。

　まだまだ決定ではありませんが、タイミングがラフなところはOS に任せてしまえ！って思えたら気が楽になったかも。
　メモリ管理も処理タイミングの管理も OS に頼った方が間違いないのです。
　この役割分担をしたら RaspberryPi でも処理しきれそうな気になってきたかも。

追記
　成り行き任せで後回しにしても構わない処理はプロセスやスレッドを別にして区切りのいいところに短い「sleep」を入れればいい。こうすると OS のジャッジで急ぎと思われるプロセスやスレッドを優先的に処理をしてくれるようです。
　厳密なタイミング管理が必要なら「RTOS」ベースのカーネルを使ってガチガチに管理するのが良いと思いますが、そこまででない処理のため導入の敷居が高い RTOS を使うのはどうかと。

#[Art-Net] #器具の製作 -- Posted by 電装工芸 〔753文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1063 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1063 tegalog Sun, 08 Jun 2025 23:29:13 +0900 　まず、全受信のスタックと受信の次の工程に送るスタックは完全に別物にした方が良さそうです。先日の書き込みと真逆のことですが、Art-Net 全体のモニターをするためのスタックとパッチの前工程のスタックは別物にするってことです。細かい理由は割愛しますが、同じ結果を得られるならメモリを大食いしても処理は軽い方がいい。DMXの処理で使うメモリ量など増えても数KBですから、GBクラスのメモリを持った RaspberryPi で気にするこっちゃありません。また、全受信のスタックを元にすべてを行うと最低でも２秒分の履歴を残さなければなりませんが、モニターするだけなら最新値のスタックだけで済みますし、Delay では深い履歴が必要でもパッチにおけるユニバース数だけあればいいので、想定される入力のすべてを数秒分スタックするほどのメモリは不要です。結果、処理が軽くなってメモリの使用量が減るなら御の字ってことです。あとは、タイムアウトの処理も大きな理由です。パケット毎に受信時刻のチェックをすることになりますが、チェックするパケットの数が減り、モニターならチェック頻度を落としてタイムアウトの実効値が２秒とか３秒でも大丈夫です。
　データをどのように取り込んでスタックして処理するかのイメージを整理して処理時間や工数が最も少ないであろう構成を決めてからソースコードを書こうと思っています。

追記
　上記の考え方にするなら、パッチの前工程の処理をする位置や共有メモリの扱いを明確にしておけばソースを書き始められるかも。完全に Art-Net モニタです。受信の後の各種処理や画面表示を別プロセスにするのでまだまだ考えることはありますけどね。
　今思い付いたのですが、タイムアウトの処理を別プロセスや別スレッドにしたら受信プロセスが凄く簡単になるかも。socket の受信をタイムアウトせずに何かを受信するまでブロックするってことです。シングルプロセスの PIC マイコンに慣れ過ぎて手作業のマルチスレッド処理がアタマの中で前提になっているようです。ブロックすることが一般的な処理をあえてタイムアウトさせてエラー処理するくらいならプロセスを分けてタイムアウトさせずに待たせればいいのです。OSが得意な部分はOSにやってもらえばいいのです。

#[Art-Net] #器具の製作 -- Posted by 電装工芸 〔1019文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1062 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1062 tegalog Sun, 08 Jun 2025 21:53:40 +0900
　実作業を始められるのがいつになるかわかりませんが基本設計は進めます。アタマが空いてる時のヒマ潰しにはちょうどいいですし。

#器具の製作 -- Posted by 電装工芸 〔230文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1061 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1061 tegalog Sun, 08 Jun 2025 13:37:18 +0900
　windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew

　２回くらいやった方がいい。

#パソコン -- Posted by 電装工芸 〔122文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=639 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=639 tegalog Thu, 08 Jun 2023 11:42:10 +0900 　ホール管理の業務が取れたので舞台資料を作ることになりました。
　まだ建築中なので舞台の細かい仕様はわかりませんが、基本図面がCADデータとして手に入ったので、各種資料に使える施設全図をまとめています。

　これがまた手ごわい。

　まずデータのフォーマットで躓く。
　最新のAutoCADのデータの様ですが、VectorWorks2016でも開けず、ネットやフリーウェアでもデータが大きすぎて変換できず。
　困り果てていたのですが、ふと思い出してAutoCAD互換のDraftsightを使ったところすんなり変換完了。最強のフリーCADだったので便利に使っていましたが、最近サブスク化(ようは有料化)してしまいました。されど、30日間は無料で全機能のお試しが出来るので取り急ぎはこれで対応。後日もっと細かいデータが入荷すると思いますが、お試し期間が切れたらサブスク登録するしかありません。一番低いグレードで変換出来るかわかりませんが、AutoCADとの互換性が極めて高いCADが年間１万円(一番安いグレード)ですから文句を言ったらいけません。

　本製作は骨董品のVectorWorks9.5を使います。2016は便利ですが、データが大きすぎるのと、3Dデータのカスで右往左往して反応が遅い。線を描くだけなら9.5が反応が軽くていい。
　そんでも、オブジェクトがグループ化されたりパーツ化されているので丁寧に処理(分解)しなければなりません。最終的にイラストレーターでも読めるDXFで書き出すことも重要です。

#本業 -- Posted by 電装工芸 〔677文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=294 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=294 tegalog Wed, 08 Jun 2022 20:26:05 +0900