電装工芸日記
- 舞台照明機器の製作とか -
2026年の投稿［14件］
2026年2月 この範囲を時系列順で読む この範囲をファイルに出力する
昨日の午後から自宅のネット回線が不通。
支払いが滞っていたのかもと不安を感じつつ、プロバイダさんやNTTさんに連絡せにゃと思っていたのですが、いつの間にか復旧したみたい。
何が原因だったのかわかりませんが、ONUの光回線パイロットランプが消灯していましたので光回線がどこかで切れていたのでしょう。
まいいか。
#雑談
支払いが滞っていたのかもと不安を感じつつ、プロバイダさんやNTTさんに連絡せにゃと思っていたのですが、いつの間にか復旧したみたい。
何が原因だったのかわかりませんが、ONUの光回線パイロットランプが消灯していましたので光回線がどこかで切れていたのでしょう。
まいいか。
#雑談
Art-Net切替＆パッチマシンは AI/Gemini さんのご協力を得て基本構成が決まりつつあります。
Gemini さんからの情報は鵜吞みにせず自ら検証をするものだと思っていますが、ドキュメントやネット検索から自分でまとめるよりも結論に近い位置から始められていると思います。
基本方針ですが、本機は Art-Net の ArtDMX パケットを受信、加工、送信する装置です。通信スタイルはブロードキャストのみ。ArtDMX 以外のパケットは扱いません (特にRDMは方言が多くて扱いが難しく、ArtDMXだけでも調光操作に支障がないためです)。
ハードウェアの基本構成は次の通り。
１）主装置
RsaspbrryPi-CM4 + CM4-Dual-Eth-Base
２）ネットワーク
1000Base-T × ２ (Art-Net用・スイッチングハブで分岐)
WLAN (製作・メンテナンス用)
３）拡張基板
RaspberryPiのGPIOに搭載する専用基板。
設定保存用 EEPROM (24LC64など,I2C接続)、レガシーDMX受信回路 (LT1785等) + 取り込みマイコン (PIC16(RAM2kB以上),SPI接続)、RS232インターフェース回路 (UARTコンソール用)。
ソフトウェアの基本構成は次の通り。
１）受信モジュール
Art-Net 上の ArtDMX を受信してバッファに保存する。保存する際、検索用のインデックス(クエリ)も作成する。
２）加工モジュール
受信した値を加工する。パッチ、プロファイルカーブ、ディレイ等の処理はここで行う。
３）送信モジュール
加工モジュールから出力された値を送信する。
４）タイムアウト監視モジュール
送信元や受信パケットがタイムアウトしたら(存在しなくなったら)適切に処理する。
５）ユーザーインターフェース(UI)モジュール
画面表示やキーボード操作を司る。
上記(1)-(4)で用いる設定はここで起こす。
これらを /dev/shm 上に作る共有ファイルで結び付けて動作させます。
#ガチ工作 #[Art-Net] #器具の製作
Gemini さんからの情報は鵜吞みにせず自ら検証をするものだと思っていますが、ドキュメントやネット検索から自分でまとめるよりも結論に近い位置から始められていると思います。
基本方針ですが、本機は Art-Net の ArtDMX パケットを受信、加工、送信する装置です。通信スタイルはブロードキャストのみ。ArtDMX 以外のパケットは扱いません (特にRDMは方言が多くて扱いが難しく、ArtDMXだけでも調光操作に支障がないためです)。
ハードウェアの基本構成は次の通り。
１）主装置
RsaspbrryPi-CM4 + CM4-Dual-Eth-Base
２）ネットワーク
1000Base-T × ２ (Art-Net用・スイッチングハブで分岐)
WLAN (製作・メンテナンス用)
３）拡張基板
RaspberryPiのGPIOに搭載する専用基板。
設定保存用 EEPROM (24LC64など,I2C接続)、レガシーDMX受信回路 (LT1785等) + 取り込みマイコン (PIC16(RAM2kB以上),SPI接続)、RS232インターフェース回路 (UARTコンソール用)。
ソフトウェアの基本構成は次の通り。
１）受信モジュール
Art-Net 上の ArtDMX を受信してバッファに保存する。保存する際、検索用のインデックス(クエリ)も作成する。
２）加工モジュール
受信した値を加工する。パッチ、プロファイルカーブ、ディレイ等の処理はここで行う。
３）送信モジュール
加工モジュールから出力された値を送信する。
４）タイムアウト監視モジュール
送信元や受信パケットがタイムアウトしたら(存在しなくなったら)適切に処理する。
５）ユーザーインターフェース(UI)モジュール
画面表示やキーボード操作を司る。
上記(1)-(4)で用いる設定はここで起こす。
これらを /dev/shm 上に作る共有ファイルで結び付けて動作させます。
#ガチ工作 #[Art-Net] #器具の製作
今後、出来上がった物を公開する際はＧＰＬライセンスとします。
ＧＰＬライセンスとはソースコードや回路図を無償で公開するし使用や書き換えは自由だけれどサポートはしませんしバグがあってもトラブっても一切関知しませんってライセンスです。他にも色々ありますので詳細はその筋の情報をご覧ください。ものすごく簡単に言うなら著作権は放棄しないけど自己責任で自由に使ってくださいってのがＧＰＬライセンスです。日本国内の法的にも有効です。
カスタマーサポートはしたくないし、本業の日程によってはサポートは不可能だからです。これまで製品を販売したことはありますが、カスハラ対応は非生産的で無駄。よかれと思って安く提供しても勉強も努力もしない輩に荒らされるのは私に何のメリットもありません。ここしばらく何も販売していなかったのはここにあります。
今作っている Art-Net 切替＆パッチマシンは価値を感じてくれる人が少なからずいると思いますので広く提供する前提で考えていますが、商売として成立する価格にしたら高価になりそうですし、かといって同業者のよしみで安価にしたらサポートで私のメンタルが潰れます。そんならＧＰＬライセンスにしようってことです。話をわかってくれる知人には完成試作品を試してもらいますし、専用基板は「部品」として安価に販売しますけど。RaspberryPiをコマンドラインで使え、gccでコンパイル出来、PICマイコンのIDEが使えて書き込みが出来、専用基板の回路図を読める人には難しくない工作です。
自分が欲しい物を自分のために作るのが前提ですから、購買者は神だと勘違いしたアホのことなど知ったことではありません。こんな悪意と嫌味と皮肉を垂れ流すほどカスハラで嫌な思いをしたのですが、知識と技能を持った人なら組める情報と専用部品を提供するので勘弁してください。
まだ「絵に描いた餅」ですけど(笑
#ガチ工作 #[Art-Net] #器具の製作
ＧＰＬライセンスとはソースコードや回路図を無償で公開するし使用や書き換えは自由だけれどサポートはしませんしバグがあってもトラブっても一切関知しませんってライセンスです。他にも色々ありますので詳細はその筋の情報をご覧ください。ものすごく簡単に言うなら著作権は放棄しないけど自己責任で自由に使ってくださいってのがＧＰＬライセンスです。日本国内の法的にも有効です。
カスタマーサポートはしたくないし、本業の日程によってはサポートは不可能だからです。これまで製品を販売したことはありますが、カスハラ対応は非生産的で無駄。よかれと思って安く提供しても勉強も努力もしない輩に荒らされるのは私に何のメリットもありません。ここしばらく何も販売していなかったのはここにあります。
今作っている Art-Net 切替＆パッチマシンは価値を感じてくれる人が少なからずいると思いますので広く提供する前提で考えていますが、商売として成立する価格にしたら高価になりそうですし、かといって同業者のよしみで安価にしたらサポートで私のメンタルが潰れます。そんならＧＰＬライセンスにしようってことです。話をわかってくれる知人には完成試作品を試してもらいますし、専用基板は「部品」として安価に販売しますけど。RaspberryPiをコマンドラインで使え、gccでコンパイル出来、PICマイコンのIDEが使えて書き込みが出来、専用基板の回路図を読める人には難しくない工作です。
自分が欲しい物を自分のために作るのが前提ですから、購買者は神だと勘違いしたアホのことなど知ったことではありません。こんな悪意と嫌味と皮肉を垂れ流すほどカスハラで嫌な思いをしたのですが、知識と技能を持った人なら組める情報と専用部品を提供するので勘弁してください。
まだ「絵に描いた餅」ですけど(笑
#ガチ工作 #[Art-Net] #器具の製作
DMX の受信処理をするにあたって必要且つ面倒なのがタイムアウト。規格では１秒間更新が無ければ送信がされていないと判断します。
ユニバースが１つのレガシーDMXの装置なら監視するタイムスタンプは一つですからそれほどの負荷ではありませんが、ArtDMX を大量にバッファする機構ではどうするか。
アイデアですが、受信してバッファされている全ての ArtDMX は監視しません。最新値だけ評価すればいいのですからインデックスを覗きます。送信元のインデックスのタイムスタンプでタイムアウトを確認し、登録されている送信元なら無送信のフラグを立てユニバースのインデックスを消去し、登録されていない送信元ならぶら下がるユニバースのインエックスと共に消去します。この後、送信元のチェックで消去されていないユニバースのタイムアウトをチェックします。最後に送信元とユニバースのインデックスをソートします。
タイムアウトは例外処理の一種ですから、どのようなメッセージを出すか、スロットの一覧表示をしていた際にどのような挙動にするか、カレントの送信元としてバスにリレーしていた場合にどうするか、この辺りはあらかじめ決めておいた方がよさそうです。
#[Art-Net]
ユニバースが１つのレガシーDMXの装置なら監視するタイムスタンプは一つですからそれほどの負荷ではありませんが、ArtDMX を大量にバッファする機構ではどうするか。
アイデアですが、受信してバッファされている全ての ArtDMX は監視しません。最新値だけ評価すればいいのですからインデックスを覗きます。送信元のインデックスのタイムスタンプでタイムアウトを確認し、登録されている送信元なら無送信のフラグを立てユニバースのインデックスを消去し、登録されていない送信元ならぶら下がるユニバースのインエックスと共に消去します。この後、送信元のチェックで消去されていないユニバースのタイムアウトをチェックします。最後に送信元とユニバースのインデックスをソートします。
タイムアウトは例外処理の一種ですから、どのようなメッセージを出すか、スロットの一覧表示をしていた際にどのような挙動にするか、カレントの送信元としてバスにリレーしていた場合にどうするか、この辺りはあらかじめ決めておいた方がよさそうです。
#[Art-Net]
現場への移動が長かったので Art-Net 切替＆パッチマシンのアイデアを AI の Gemini さんに投げてみました。
受信は socket で行いますが、受信したデータ(バイナリ)、受信日時、送信元のIPアドレスとMACアドレス、ユニバース番号を mmap を使ったループバッファでとにかく保存します。約２秒分の最大数を構造体配列に保存します。コンソール８台、それぞれユニバース１６(使うのは８ですが、使いたいユニバースを取り溢したくないで多めに監視して１６とします)、２秒分ですから88フレーム、１フレームあたり600バイトくらいとするなら６MBくらいです。PICマイコンなら厳しいですが、RaspberryPi なら楽勝です。ただし、mmap を OS がスワップ領域に移動すると困るので mlock などでメモリに常駐させる設定は必要です。受信順に保存するだけでは後処理で探しにくいのでインテックスも作ります。送信元とそこにぶら下がるユニバースやデータを階層で表し、ループバッファから目的のデータを最短手順で取り出せるようにします。データベース Access のクエリやリレーショナルデータベースの１対ｎ関係などの参照構造を作っておくイメージです。受信データから送信元を、送信元から受信データを参照しやすくするのです。
あとは、受信、送信、エフェクト、表示、操作をプロセスやスレッドで分割するワケですが、これらはそれぞれ勝手に動作するようにします。どこかがどこかへ指示を送って返り値を得る構造ですとタイミングの管理が難しい。設定書を書き換えるだけでコール・アンド・レスポンスは使わないのです。装置はデータを加工しながら一方向に流す機構ですから、それをそのままに素直に形にすればいいのです。ユーザーは流れているデータを覗き見たり流れ方を変更しますが、覗くのは加工の邪魔をしない隙間で読み出すだけですし、設定書は書き換えて適切な場所に置いておけば加工する側が勝手に読むのでいいのです。mmap の読み書きは衝突の可能性がありますが flock をかければ事足りると思われます。
といったことを Gemini さんに投げたのですが「よいんでない？」とのこと。ただ、AI はユーザーを認めて誉める言葉が多い。「だっせーこと言ってんじゃねーよ」的な言葉があってもいいと思う。
#[Art-Net]
受信は socket で行いますが、受信したデータ(バイナリ)、受信日時、送信元のIPアドレスとMACアドレス、ユニバース番号を mmap を使ったループバッファでとにかく保存します。約２秒分の最大数を構造体配列に保存します。コンソール８台、それぞれユニバース１６(使うのは８ですが、使いたいユニバースを取り溢したくないで多めに監視して１６とします)、２秒分ですから88フレーム、１フレームあたり600バイトくらいとするなら６MBくらいです。PICマイコンなら厳しいですが、RaspberryPi なら楽勝です。ただし、mmap を OS がスワップ領域に移動すると困るので mlock などでメモリに常駐させる設定は必要です。受信順に保存するだけでは後処理で探しにくいのでインテックスも作ります。送信元とそこにぶら下がるユニバースやデータを階層で表し、ループバッファから目的のデータを最短手順で取り出せるようにします。データベース Access のクエリやリレーショナルデータベースの１対ｎ関係などの参照構造を作っておくイメージです。受信データから送信元を、送信元から受信データを参照しやすくするのです。
あとは、受信、送信、エフェクト、表示、操作をプロセスやスレッドで分割するワケですが、これらはそれぞれ勝手に動作するようにします。どこかがどこかへ指示を送って返り値を得る構造ですとタイミングの管理が難しい。設定書を書き換えるだけでコール・アンド・レスポンスは使わないのです。装置はデータを加工しながら一方向に流す機構ですから、それをそのままに素直に形にすればいいのです。ユーザーは流れているデータを覗き見たり流れ方を変更しますが、覗くのは加工の邪魔をしない隙間で読み出すだけですし、設定書は書き換えて適切な場所に置いておけば加工する側が勝手に読むのでいいのです。mmap の読み書きは衝突の可能性がありますが flock をかければ事足りると思われます。
といったことを Gemini さんに投げたのですが「よいんでない？」とのこと。ただ、AI はユーザーを認めて誉める言葉が多い。「だっせーこと言ってんじゃねーよ」的な言葉があってもいいと思う。
#[Art-Net]
2026年1月 この範囲を時系列順で読む この範囲をファイルに出力する
Art-Net 切替器もパッチも基本的に同じ物として考えています。
基本構成は受信部と送信部があり、間に値を加工するエフェクターを挟みます。
内部は８ユニバースとし、これらをバスと呼称します。
ミキサーというかマージは一番若いバスのみ一般照明向けとしてHTPで考えています。演出操作用ではなく小型サブ卓による作業灯や非常灯用と割り切り、レガシーDMXの入力を１本だけマージするかもしれません(エキストラマージ)。
受信部はIPアドレスやMACアドレスで送信元を選択し、Art-Net ユニバースをバスに渡します。切替器の実体はここです。
エフェクターとはバスの値を加工します。エキストラマージ、パッチ、プロファイルカーブ、ディレイなどはエフェクターとして扱います。ここで何もしなければ単なる切替器です。
送信部はバスの値を Art-Net で送信します。
RDM には対応しません。
複数のコンソールを設置する環境ならば切替器から見てフィクスチャー側に RDM コンソールを繋いだ方が良いと思うからです。
#[Art-Net]
基本構成は受信部と送信部があり、間に値を加工するエフェクターを挟みます。
内部は８ユニバースとし、これらをバスと呼称します。
ミキサーというかマージは一番若いバスのみ一般照明向けとしてHTPで考えています。演出操作用ではなく小型サブ卓による作業灯や非常灯用と割り切り、レガシーDMXの入力を１本だけマージするかもしれません(エキストラマージ)。
受信部はIPアドレスやMACアドレスで送信元を選択し、Art-Net ユニバースをバスに渡します。切替器の実体はここです。
エフェクターとはバスの値を加工します。エキストラマージ、パッチ、プロファイルカーブ、ディレイなどはエフェクターとして扱います。ここで何もしなければ単なる切替器です。
送信部はバスの値を Art-Net で送信します。
RDM には対応しません。
複数のコンソールを設置する環境ならば切替器から見てフィクスチャー側に RDM コンソールを繋いだ方が良いと思うからです。
#[Art-Net]
現場が早く終わって空き時間。とは言っても中途半端な時間なので Art-Net の算数を少々。
切替器やパッチマシンを作るとしてコンソールは何台まで接続可能なのか？です。
今時の EtherNet の通信スペックは 1Gbps が一般的ですが、ケーブルやハブなどに古い物を使ってしまうと 100Mbps になることもあるでしょうし wi-fi を使うと 20Mbpsくらいまで下がる可能性があります。仮に 20Mbps としてコンソールを何台使えるか考えてみます。
ArtDMXのパケットは530バイトです。EtherNetの諸々のデータが貼り付いても600バイトくらい見ておけばいいかな。
EhterNetは１バイト送るのに10ビット必要です。
DMX512の送信レートは最大で44fpsくらいです。
となると、１ユニバース送るのに１秒間に 264kbps くらいの通信速度が最低必要です。DMX512の 250kbps より少し多いですがこんなもんでしょう。
単純に 20Mbps を 264kpbs で割ると 75.757・・・です。Art-Net上に 75 ユニバース存在可能となります。各コンソールから８ユニバース送り出すならコンソールは９台まで不可能ではないとなります。
今のイメージはコンソール８台、合計 64ユニバースですから収まっています。
あとは RaspberryPi の処理能力が足りるかどうかです。
44fps/64ユニバースなら１パケットあたりに許される処理時間は 355usec(0.000355秒) です。以前試作した際は１パケットの処理に150から250usec程度かかっていましたので一応収まります。
先日 AI の Gemini さんとお話をしていたらCPUコアの割り当てや占有の方法がわかったのですが、上記の時間はOSの処理も含めて１つのCPUコアで処理しての値ですから、Art-Netで占有できるCPUコアを設定出来ればもう少し軽くなるかな？
主な処理を書いて１ユニバースあたりの処理時間を計測して最大コンソール数を決めることにしましょう。現実の現場ではバックアップを入れても仕込まれるコンソールは４台くらいでしょうから大丈夫な気はしています。
つか、８台並べてテストする環境を作るのが大変かな？〇ッシュシステムの〇山さんに相談ですね(笑
#[Art-Net]
切替器やパッチマシンを作るとしてコンソールは何台まで接続可能なのか？です。
今時の EtherNet の通信スペックは 1Gbps が一般的ですが、ケーブルやハブなどに古い物を使ってしまうと 100Mbps になることもあるでしょうし wi-fi を使うと 20Mbpsくらいまで下がる可能性があります。仮に 20Mbps としてコンソールを何台使えるか考えてみます。
ArtDMXのパケットは530バイトです。EtherNetの諸々のデータが貼り付いても600バイトくらい見ておけばいいかな。
EhterNetは１バイト送るのに10ビット必要です。
DMX512の送信レートは最大で44fpsくらいです。
となると、１ユニバース送るのに１秒間に 264kbps くらいの通信速度が最低必要です。DMX512の 250kbps より少し多いですがこんなもんでしょう。
単純に 20Mbps を 264kpbs で割ると 75.757・・・です。Art-Net上に 75 ユニバース存在可能となります。各コンソールから８ユニバース送り出すならコンソールは９台まで不可能ではないとなります。
今のイメージはコンソール８台、合計 64ユニバースですから収まっています。
あとは RaspberryPi の処理能力が足りるかどうかです。
44fps/64ユニバースなら１パケットあたりに許される処理時間は 355usec(0.000355秒) です。以前試作した際は１パケットの処理に150から250usec程度かかっていましたので一応収まります。
先日 AI の Gemini さんとお話をしていたらCPUコアの割り当てや占有の方法がわかったのですが、上記の時間はOSの処理も含めて１つのCPUコアで処理しての値ですから、Art-Netで占有できるCPUコアを設定出来ればもう少し軽くなるかな？
主な処理を書いて１ユニバースあたりの処理時間を計測して最大コンソール数を決めることにしましょう。現実の現場ではバックアップを入れても仕込まれるコンソールは４台くらいでしょうから大丈夫な気はしています。
つか、８台並べてテストする環境を作るのが大変かな？〇ッシュシステムの〇山さんに相談ですね(笑
#[Art-Net]
ちょっと忙しい１月です。
仕事があるのは喜ばしいことですが、妄想は出来ても工作の実作業は出来ません。設計という名の妄想をキッチリやらないといけませんのである意味いいのですけどね。
最近の妄想はGoogle検索よりもAIさんたちに聞くことで進めることが多くなりました。AIさんから結論をもらうというより代わりに検索してもらってレポートを頂戴する感じです。
そんなやりとりの中で「Ｃ言語は高級アセンブリ言語である」という言葉がありました。ハードウェアを隠蔽してサービスに特化するいわゆる高級言語ではなく、ハードウェアに依存しないアセンブラ言語を示すってことらしいです。自分はハードウェアを動かすことに趣向が向いています。自分のベースはPIC16のアセンブラですが、書いているウチに「Ｃ言語はCPUにごとに違うアセンブラを汎用化して書きやすくしたモノだと思えば自分にとって自然だな」と感じていたので妙に納得した言葉です。
何をしたいかによるので「Ｃ言語が絶対正義」とは思いませんが、昨今流行りのプログラム言語の大半はＣ言語を基礎としてして作られていますので原典とも言える存在です。高級言語を書いているとＣ言語が見え隠れしますので、Ｃ言語を知っていた方が理解し易いように思います。今どきの高級言語はＣ言語の方言と言ってもいいのかもしれません。自分はPIC16アセンブラの後にPython3に行ったのですが、むしろPythonだけを見て煮詰まったことがＣ言語を習得することで解決したように思います。高級言語とはＣ言語を楽に使うためのマクロ言語と捉えることが自然な気すらします。FORTRAN・COBOL・BASICなどのＣ言語と同時期に研究・開発された高級言語は少し違う感じがしますが、今主流の開発言語の大半はＣ言語の方言なのでしょう。
私のように「物理的な装置を作ること」に趣向を持つ方は少ないと思いますが、コンピュータはマシンコードで動くのですから、マシンコードを汎用的に表現するＣ言語はハードウェアを直接動かす存在なのでしょう。名前が似通ったＣ＋＋やＣ＃(Ｃ＋＋＋＋)はそれとは違った感じがしますけど。
#Ｃ言語
仕事があるのは喜ばしいことですが、妄想は出来ても工作の実作業は出来ません。設計という名の妄想をキッチリやらないといけませんのである意味いいのですけどね。
最近の妄想はGoogle検索よりもAIさんたちに聞くことで進めることが多くなりました。AIさんから結論をもらうというより代わりに検索してもらってレポートを頂戴する感じです。
そんなやりとりの中で「Ｃ言語は高級アセンブリ言語である」という言葉がありました。ハードウェアを隠蔽してサービスに特化するいわゆる高級言語ではなく、ハードウェアに依存しないアセンブラ言語を示すってことらしいです。自分はハードウェアを動かすことに趣向が向いています。自分のベースはPIC16のアセンブラですが、書いているウチに「Ｃ言語はCPUにごとに違うアセンブラを汎用化して書きやすくしたモノだと思えば自分にとって自然だな」と感じていたので妙に納得した言葉です。
何をしたいかによるので「Ｃ言語が絶対正義」とは思いませんが、昨今流行りのプログラム言語の大半はＣ言語を基礎としてして作られていますので原典とも言える存在です。高級言語を書いているとＣ言語が見え隠れしますので、Ｃ言語を知っていた方が理解し易いように思います。今どきの高級言語はＣ言語の方言と言ってもいいのかもしれません。自分はPIC16アセンブラの後にPython3に行ったのですが、むしろPythonだけを見て煮詰まったことがＣ言語を習得することで解決したように思います。高級言語とはＣ言語を楽に使うためのマクロ言語と捉えることが自然な気すらします。FORTRAN・COBOL・BASICなどのＣ言語と同時期に研究・開発された高級言語は少し違う感じがしますが、今主流の開発言語の大半はＣ言語の方言なのでしょう。
私のように「物理的な装置を作ること」に趣向を持つ方は少ないと思いますが、コンピュータはマシンコードで動くのですから、マシンコードを汎用的に表現するＣ言語はハードウェアを直接動かす存在なのでしょう。名前が似通ったＣ＋＋やＣ＃(Ｃ＋＋＋＋)はそれとは違った感じがしますけど。
#Ｃ言語
不調のムービングライトを検査したところステッピングモーターに電圧がかかっていない様子。ステッピングモーターは電圧がかかっていれば保持力が強く指では回せませんから、それが軽く回るならば電圧がかかっていないと予想できます。基板からモーターまでの配線は正常に導通しており、別なドライバ回路に差し替えると動きますからモーター自体は生きている様子です。となると、制御基板に何か障害があるのでしょう。ドライバICに制御マイコンから間違った信号(ディセーブル信号など)が行っているかドライバICが飛んでいると思われます。これまで動いていたのですからドライバICが飛んでいるのが濃厚でしょう。
ドライバICの検査は大変なので交換してみます。SS8841Tと刻印があり、中華電機にありました。１個200円くらいです。表面実装のICですから外すのも付けるのも難しいのですがなんとかなるっしょ。
ドライバICは今月末の入荷予定です。
#器具の修理
ドライバICの検査は大変なので交換してみます。SS8841Tと刻印があり、中華電機にありました。１個200円くらいです。表面実装のICですから外すのも付けるのも難しいのですがなんとかなるっしょ。
ドライバICは今月末の入荷予定です。
#器具の修理
ホール増員でしたが操作盤の置物でしたので Art-Net の装置を作るための情報整理をやってました。情報量が多いので終わってませんが、これまでに実験したこと、AIさんたちに聞いたことなどです。
ソースコードも大切ですが、今日はOSのセッティングについてです。Art-Net を扱うのに不要なこと、つまりはOSから無駄を省きたいのです。
まずは Art-Net は IPv4 を用いますので IPv6 は不要です。
NIC は Art-Net の IN/OUT と作業用の３つを使いますが、Art-Net の IN/OUT 側は Art-Net 以外の通信をしないようにした方が良さそうです。
これらのセッティングをしてからプログラミングを進める方針です。
また、RaspberryPi の CPU にはコアが４つありますが、このウチの２つか３つを Art-Net にのみ割り振ろうと思います。こんなことが出来るんだと驚きましたが、出来るみたいですね。
土台をキチンと作って処理に「待ち」を持たせないようにしたいものです。
#[Art-Net] #器具の製作
ソースコードも大切ですが、今日はOSのセッティングについてです。Art-Net を扱うのに不要なこと、つまりはOSから無駄を省きたいのです。
まずは Art-Net は IPv4 を用いますので IPv6 は不要です。
NIC は Art-Net の IN/OUT と作業用の３つを使いますが、Art-Net の IN/OUT 側は Art-Net 以外の通信をしないようにした方が良さそうです。
これらのセッティングをしてからプログラミングを進める方針です。
また、RaspberryPi の CPU にはコアが４つありますが、このウチの２つか３つを Art-Net にのみ割り振ろうと思います。こんなことが出来るんだと驚きましたが、出来るみたいですね。
土台をキチンと作って処理に「待ち」を持たせないようにしたいものです。
#[Art-Net] #器具の製作