電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-net」を含む投稿［125件］（7ページ目）
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]
Art-Netを受信する準備を進めています。
思った以上に面倒だったのはデータの比較です。受信値と期待値を比較して処理を分岐する処理は重要です。文字列ならstrcmp、バイナリならmemcmpを使います。どちらもstring.hの関数です。
どちらにしてもバイナリな感覚を持ち合わせていないと使えませんが、アセンブラに慣れた体にとって違和感はありませんし、ある意味とても明確な処理になるので悪い気はしません。Pythonが如何に簡単に書けるかを感じたりはしましたけどね。
あとはエンディアンの処理です。RaspberryPiはARM系なのでリトルエンディアンです。受信したArt-Netを仕分けて情報にするには2-4バイトのバイナリを数値化しないといけませんが、エンディアンを気にしながらバイナリを並べて処理します。並べたバイナリを数値化するにはカッコとアンパサンドを使った不思議な記述をしますが、理解不能なので定型句と思って使っています。
こんな底辺処理が整理出来たら受信テストですが、これらを先にやっておかないと受信値を人が読める形で表示することが出来ないのです。
#[Art-Net] #Ｃ言語
思った以上に面倒だったのはデータの比較です。受信値と期待値を比較して処理を分岐する処理は重要です。文字列ならstrcmp、バイナリならmemcmpを使います。どちらもstring.hの関数です。
どちらにしてもバイナリな感覚を持ち合わせていないと使えませんが、アセンブラに慣れた体にとって違和感はありませんし、ある意味とても明確な処理になるので悪い気はしません。Pythonが如何に簡単に書けるかを感じたりはしましたけどね。
あとはエンディアンの処理です。RaspberryPiはARM系なのでリトルエンディアンです。受信したArt-Netを仕分けて情報にするには2-4バイトのバイナリを数値化しないといけませんが、エンディアンを気にしながらバイナリを並べて処理します。並べたバイナリを数値化するにはカッコとアンパサンドを使った不思議な記述をしますが、理解不能なので定型句と思って使っています。
こんな底辺処理が整理出来たら受信テストですが、これらを先にやっておかないと受信値を人が読める形で表示することが出来ないのです。
#[Art-Net] #Ｃ言語
ここ数日は本業で手一杯でした。ライトアップの施工があったのですが、建物の窓を光らせたいとのことで専用の行燈を製作してました。
簡単な作りではあったのですが思った以上に時間がかかり、徹夜して間に合わせたのはいいですが、その余波で心身共にキツイここ数日。
８月のお盆明けからの大連チャンでしたが、この後３月中旬までは緩い日程なので、各種製作や開発を進めて行けそうです。
同時にイロイロ進めますが、とにかくArt-Netエンジンを完成させたい。
Art-Netエンジンとは、Art-Netを受信し、Merge、In-Delay、Patch、Out-Curve、Out-Delayを施し、Art-Netとして送信するデバイスドライバの様なモジュールです。ユーザーインターフェースなどは別途製作ですが、これが完成すれば求めることの半分は完成です。
そのためにＣ言語を学習しているワケですが、ポインタ、構造体、共有メモリ、マルチプロセスの基本が見えてきましたので、これからしばらくはArt-Netの要であるscoketを試そうと思います。Ｃ言語でscoketを扱う情報は高位者による高位者向けの高度な物ばかりですが、幸いPythonでの前例がありますので、これをＣ言語に置き換える方向で読み解いていこうと思います。
学習を進めれば進める程「ライブラリの使い方はmanとヘッダーファイルを読めば分かるだろ！」という圧を強く感じますが、この感覚が自分にとっても当たり前になるように精進したいものです。
#Ｃ言語 #本業 #[Art-Net]
簡単な作りではあったのですが思った以上に時間がかかり、徹夜して間に合わせたのはいいですが、その余波で心身共にキツイここ数日。
８月のお盆明けからの大連チャンでしたが、この後３月中旬までは緩い日程なので、各種製作や開発を進めて行けそうです。
同時にイロイロ進めますが、とにかくArt-Netエンジンを完成させたい。
Art-Netエンジンとは、Art-Netを受信し、Merge、In-Delay、Patch、Out-Curve、Out-Delayを施し、Art-Netとして送信するデバイスドライバの様なモジュールです。ユーザーインターフェースなどは別途製作ですが、これが完成すれば求めることの半分は完成です。
そのためにＣ言語を学習しているワケですが、ポインタ、構造体、共有メモリ、マルチプロセスの基本が見えてきましたので、これからしばらくはArt-Netの要であるscoketを試そうと思います。Ｃ言語でscoketを扱う情報は高位者による高位者向けの高度な物ばかりですが、幸いPythonでの前例がありますので、これをＣ言語に置き換える方向で読み解いていこうと思います。
学習を進めれば進める程「ライブラリの使い方はmanとヘッダーファイルを読めば分かるだろ！」という圧を強く感じますが、この感覚が自分にとっても当たり前になるように精進したいものです。
#Ｃ言語 #本業 #[Art-Net]
ランチャーに行く前にscoketの基本動作の確認かな？
受信したArt-Netパケットをそのまま送信する実験。
これが求める機能の基本ですから確認せんといかん。
#[Art-Net] #Ｃ言語
受信したArt-Netパケットをそのまま送信する実験。
これが求める機能の基本ですから確認せんといかん。
#[Art-Net] #Ｃ言語
現場が早く終わったので、開発用のRaspberryPiをノートパソコンのVSCodeと繋いでおきました。ここまでしておけば比較的身軽に開発が出来ます。
本格的に開発を進めましょう。
Ｃ言語でのsocketについて調べてみましたが、PythonのscoketライブラリはＣ言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。
#Ｃ言語 #[Art-Net]
本格的に開発を進めましょう。
Ｃ言語でのsocketについて調べてみましたが、PythonのscoketライブラリはＣ言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。
#Ｃ言語 #[Art-Net]
Art-Netエンジンの構成を整理していますが、そういやプロセス間通信はどうしましょう。
PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。
これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。
#Python #[Art-Net]
PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。
これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。
#Python #[Art-Net]
現場もホール資料の作成も一息つきました。
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
ソフトウェアを書く時間はありませんが、Art-Netパッチのハードウェアの基本方針を考えています。必須事項はEtherNetが独立して２系統あることです。
RaspberryPiには１系統しかありませんので増設が必要です。USBで増設してもいいのですがスッキリしているとは言えません。
そういや、RaspberryPiCM4はPCIeX1を出しています。4BではUSB3.0のアダプタに接続されていて表に出ていませんが、CM4ではUSB3.0が無い代わりに出ています。これにEtherNetアダプタを取り付けたらいいかなと。
通常のPCIeX1コネクタでもいいし、M.2で使われるNGFFコネクタ(M-key)でもいい。汎用性ならPCIeX1で、小型化を考えるならNGFFかな？いずれにしてもMACアドレスの取得を考えるとチップだけ使うより既製品のネットワークカードを使うのがよいでしょう。現実的には通常のPCIeX1ロープロファイルでIntelチップを使うデュアルタイプがよろしいかな？
#[Art-Net] #RaspberryPi
RaspberryPiには１系統しかありませんので増設が必要です。USBで増設してもいいのですがスッキリしているとは言えません。
そういや、RaspberryPiCM4はPCIeX1を出しています。4BではUSB3.0のアダプタに接続されていて表に出ていませんが、CM4ではUSB3.0が無い代わりに出ています。これにEtherNetアダプタを取り付けたらいいかなと。
通常のPCIeX1コネクタでもいいし、M.2で使われるNGFFコネクタ(M-key)でもいい。汎用性ならPCIeX1で、小型化を考えるならNGFFかな？いずれにしてもMACアドレスの取得を考えるとチップだけ使うより既製品のネットワークカードを使うのがよいでしょう。現実的には通常のPCIeX1ロープロファイルでIntelチップを使うデュアルタイプがよろしいかな？
#[Art-Net] #RaspberryPi
Art-Netエンジンが全く進みません。頭を全振り出来るまとまった時間が取れないのです。
#[Art-Net]
#[Art-Net]