電装工芸日記
- 舞台照明機器の製作とか -
全年2月14日の投稿［9件］
2025年 この範囲を時系列順で読む この範囲をファイルに出力する
現場が忙しい状況ですのでガラクタイジリは少しお休み。
なのにですよ、最後の最後に Antari F1-FAZER は煙を一切出さなくなりました。
色々考えたのですが、ひょっとすると温度センサが狂っているのではないかと。
煙の出口がブクブク泡立つことがあり、液があるなら煙になれと思っていました。また、発煙口の液だれの焦げが目立ちます。現役の正常な機体では見られないことでもあります。
理屈というより勘ですが、発煙器の温度が低いという前提で洗い直す必要がありそうです。発煙器は冷めているとリキッドもエアも通しませんが暖まると通します。温度で開閉する弁があるのでしょう。正に今は定格温度になる前の閉鎖状態から脱せない感じ。つまり温度が低いのではと。実際発煙口は低い気がする。
発煙器からは温度センサからと思わしきケーブルがあります。当たってみると熱電対っぽい挙動。数mVの電圧があり、電熱器へのリレーの挙動に合わせて上下します。基板を当たりますと熱電対からと思わしきケーブルと直結されたコネクタがあります。たぶんですが、熱電対の電圧を見ながら近くにある半固定抵抗で電熱器のＯＮ／ＯＦＦ条件を調整するのではないかと。正常な機体の熱電対の電圧とリレーの動作を見て設定を調べてみます。
半固定抵抗も怪しい気がする。念のため同等品に交換してみるつもりです。
#器具の修理
なのにですよ、最後の最後に Antari F1-FAZER は煙を一切出さなくなりました。
色々考えたのですが、ひょっとすると温度センサが狂っているのではないかと。
煙の出口がブクブク泡立つことがあり、液があるなら煙になれと思っていました。また、発煙口の液だれの焦げが目立ちます。現役の正常な機体では見られないことでもあります。
理屈というより勘ですが、発煙器の温度が低いという前提で洗い直す必要がありそうです。発煙器は冷めているとリキッドもエアも通しませんが暖まると通します。温度で開閉する弁があるのでしょう。正に今は定格温度になる前の閉鎖状態から脱せない感じ。つまり温度が低いのではと。実際発煙口は低い気がする。
発煙器からは温度センサからと思わしきケーブルがあります。当たってみると熱電対っぽい挙動。数mVの電圧があり、電熱器へのリレーの挙動に合わせて上下します。基板を当たりますと熱電対からと思わしきケーブルと直結されたコネクタがあります。たぶんですが、熱電対の電圧を見ながら近くにある半固定抵抗で電熱器のＯＮ／ＯＦＦ条件を調整するのではないかと。正常な機体の熱電対の電圧とリレーの動作を見て設定を調べてみます。
半固定抵抗も怪しい気がする。念のため同等品に交換してみるつもりです。
#器具の修理
2023年 この範囲を時系列順で読む この範囲をファイルに出力する
故障した中華電機のムービングライトは回復しました。
予想通りRS485のトランシーバーICがダメだったようです。
ただ、治ったのはいいですが、そもそもナゼ壊れたのか。
SN75176系が静電気に弱いのは事実ですが、基板間の通信ですから外部配線にさらされることはありませんし、同様のICを使っている受け側は壊れていいませんので、静電気が原因だとしてもどこから回り込んでナゼこれだけなのか。同じ基板に搭載されている他のICは壊れていませんので、起動時の瞬間的な電圧異常が原因だったとしてもナゼこのICだけなのか。他のICはサージ保護が施されているのかもしれませんけれど。
原因不明なので再発の可能性は十分にあります。他の機体が同様の故障を起こすかもしれません。
RS485トランシーバーICは10個単位の販売でしたので予備はあります。しばらく様子見です。
追記
RS485トランシーバーICはSN75176互換の3.3vSOP-8パッケージの品なら使えそうです。今回は全く同じモノを中華電機から仕入れましたが、秋月さんでも互換品が手に入ります。
静電気にも過電圧にも強いLT1785の姉妹品に3.3vのSOP-8パッケージの物があればいいのですけどね。
実験で電子ライターの火花を与えたことがありますが、SN75176は即死、LT1785は損傷しませんでした。
追伸２
LT1785と同等の耐久性を持つ定格電圧3.0～5.5v品がありました。S8パッケージのLTC2862-2(max250kbps)です。
過電圧耐性±60v、EMI(静電気耐性)1.5kvです。壊そうとしても簡単には壊せないかも。姉妹品のLTC2862-1は高スペックで20Mbpsまで対応しますがオーバースペックです。
パッケージはS8とありますがSOP-8と同等の様です。
ネット検索では国内小売りにもAliExpressにも見当たりません。入手性に難ありです。
#照明器具 #電子工作
予想通りRS485のトランシーバーICがダメだったようです。
ただ、治ったのはいいですが、そもそもナゼ壊れたのか。
SN75176系が静電気に弱いのは事実ですが、基板間の通信ですから外部配線にさらされることはありませんし、同様のICを使っている受け側は壊れていいませんので、静電気が原因だとしてもどこから回り込んでナゼこれだけなのか。同じ基板に搭載されている他のICは壊れていませんので、起動時の瞬間的な電圧異常が原因だったとしてもナゼこのICだけなのか。他のICはサージ保護が施されているのかもしれませんけれど。
原因不明なので再発の可能性は十分にあります。他の機体が同様の故障を起こすかもしれません。
RS485トランシーバーICは10個単位の販売でしたので予備はあります。しばらく様子見です。
追記
RS485トランシーバーICはSN75176互換の3.3vSOP-8パッケージの品なら使えそうです。今回は全く同じモノを中華電機から仕入れましたが、秋月さんでも互換品が手に入ります。
静電気にも過電圧にも強いLT1785の姉妹品に3.3vのSOP-8パッケージの物があればいいのですけどね。
実験で電子ライターの火花を与えたことがありますが、SN75176は即死、LT1785は損傷しませんでした。
追伸２
LT1785と同等の耐久性を持つ定格電圧3.0～5.5v品がありました。S8パッケージのLTC2862-2(max250kbps)です。
過電圧耐性±60v、EMI(静電気耐性)1.5kvです。壊そうとしても簡単には壊せないかも。姉妹品のLTC2862-1は高スペックで20Mbpsまで対応しますがオーバースペックです。
パッケージはS8とありますがSOP-8と同等の様です。
ネット検索では国内小売りにもAliExpressにも見当たりません。入手性に難ありです。
#照明器具 #電子工作
Art-Net製品はほぼ趣味で開発しているのでいいですが、DoctorMXで有名なクワテックさんのラインナップは素晴らしいです。
是非ゴングインターナショナルさんのサイトからご覧になって頂きたいですが、間違いなく世界レベルの製品ばかりです。業界内には国産のDMX関連製品を正しく評価していない気配があるように思いますが、DMX関連品の導入をお考えなら海外製品の前にクワテック製品を検討することをお勧めします。リクエストすると機能を追加してくれたりしますしね。
最近多くなったライトアップに於いても、ショーコントローラーValenciaの導入を検討しています。半仮設用途に向いたDMXも扱えるマルチメディアシーケンサーは他に無いと言ってもよく、なんと言っても特定の日、特定の曜日でショーの実施を設定できるのは強味です。ダスライトの上位機種にも同様のカレンダー機能はありますが、そもそも明かり作りのツールとして個人的には嫌いです。
余談ですが間違っても案件ステマではありません。ゴングさんから購入することは少なくありませんが、クワテックさん程の開発力があったらなぁ～と羨望の気持ちでカタログを眺めているだけですwww
#照明器具
是非ゴングインターナショナルさんのサイトからご覧になって頂きたいですが、間違いなく世界レベルの製品ばかりです。業界内には国産のDMX関連製品を正しく評価していない気配があるように思いますが、DMX関連品の導入をお考えなら海外製品の前にクワテック製品を検討することをお勧めします。リクエストすると機能を追加してくれたりしますしね。
最近多くなったライトアップに於いても、ショーコントローラーValenciaの導入を検討しています。半仮設用途に向いたDMXも扱えるマルチメディアシーケンサーは他に無いと言ってもよく、なんと言っても特定の日、特定の曜日でショーの実施を設定できるのは強味です。ダスライトの上位機種にも同様のカレンダー機能はありますが、そもそも明かり作りのツールとして個人的には嫌いです。
余談ですが間違っても案件ステマではありません。ゴングさんから購入することは少なくありませんが、クワテックさん程の開発力があったらなぁ～と羨望の気持ちでカタログを眺めているだけですwww
#照明器具
ANSIエスケープシーケンスによるテキスト画面表示はやりたいことのやり方が見えてきました。先にも書いた通り、ウィンドウマネージャに近い考え方で関数ライブラリにまとめる方針です。
ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。
#[Art-Net] #Ｃ言語
ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。
#[Art-Net] #Ｃ言語
2022年 この範囲を時系列順で読む この範囲をファイルに出力する
オレメモです。
パッチマップ(出力側ベース)
・フリーフェーダースロット
・ディレイ：<0>ならスルー、<1-255>ならディレイ
・ユニバース(入力参照)
・スロット(入力参照)
・カーブプロファイル：<0>ならスルー、<1-511>なら以下とする
＞カーブプロファイル<1-255>はノンディマーとしてしきい値とする
＞カーブプロファイル<256-511>はカーププロファイルマップを参照する
#[Art-Net]
パッチマップ(出力側ベース)
・フリーフェーダースロット
・ディレイ：<0>ならスルー、<1-255>ならディレイ
・ユニバース(入力参照)
・スロット(入力参照)
・カーブプロファイル：<0>ならスルー、<1-511>なら以下とする
＞カーブプロファイル<1-255>はノンディマーとしてしきい値とする
＞カーブプロファイル<256-511>はカーププロファイルマップを参照する
#[Art-Net]
Art-Netの受信に成功して処理負荷に余裕もあるとなれば落としどころをどうするか！？って話にもなるワケです。最大の望みはディレイ機能とカーブプロファイル機能を持ったパッチマシンですが、欲を出し過ぎたら頓挫します。
さてさて、どこまで行けるのでしょう。
お試しに次ぐお試しでとっ散らかったソースコードを整理整頓し、受信モニタとしてまとめ上げてからの話ですが、受信したArt-Netを送信する試験をしましょう。
ただし、単にリレーするだけでは面白くないし処理負荷の確認にもなりません。受信をデコードし、１対１のパッチ処理をし、エンコードして送信することにします。１対１とはいえマッピングデータ用いた入れ替えをすれば最終形の負荷に近くなると思います。ここまでやれば天井が見えてくるでしょう。
もしRaspberryPiには荷が重いならPCで動かせばいいって話もあります。今のところRaspberryPiというよりDebian上のPython3.7で動く様に作っていますのでPCでも動くと思います。レガシーDMXを搭載せずにいる理由の一つでもあります。
今どきのムービング卓はArt-Netを出しますし、Art-Netのデコーダーは既製品が沢山ありますので、レガシーDMXまで作らなくてもいいかなぁ～なんて思ってます。専用基板を作る初期投資がキツイってのが一番大きいですが・・・
#Python #[Art-Net]
さてさて、どこまで行けるのでしょう。
お試しに次ぐお試しでとっ散らかったソースコードを整理整頓し、受信モニタとしてまとめ上げてからの話ですが、受信したArt-Netを送信する試験をしましょう。
ただし、単にリレーするだけでは面白くないし処理負荷の確認にもなりません。受信をデコードし、１対１のパッチ処理をし、エンコードして送信することにします。１対１とはいえマッピングデータ用いた入れ替えをすれば最終形の負荷に近くなると思います。ここまでやれば天井が見えてくるでしょう。
もしRaspberryPiには荷が重いならPCで動かせばいいって話もあります。今のところRaspberryPiというよりDebian上のPython3.7で動く様に作っていますのでPCでも動くと思います。レガシーDMXを搭載せずにいる理由の一つでもあります。
今どきのムービング卓はArt-Netを出しますし、Art-Netのデコーダーは既製品が沢山ありますので、レガシーDMXまで作らなくてもいいかなぁ～なんて思ってます。専用基板を作る初期投資がキツイってのが一番大きいですが・・・
#Python #[Art-Net]
Art-Netの受信に成功しました。
先達のサンプルコードをコピペしてPort番号を書き換えただけで一発ＯＫ。積年の成果が出て良かったのですが、あまりにも簡単だったので肩透かし。
複数のNICを使い分けるsocketの設定は先達情報に何パターンかありますが、Rasbian上のPythonに合うパターンを見つけるのに少し時間がかかったかもしれません。
今は卓のエフェクトエンジンで出力したデータが画面に流れております。4096chのディマーを256bpmの正弦波で動かしています。アホか。
テストデータはMAdot2からですが、SequenceとPhysicalにデータが出ていました。
Sequenceは単純なインクリメント情報、Physicalは卓内のUnivres番号です。
送信を作るときにはこの流儀を真似しましょう。
ただ、MAdot2はOpCode<0x5000>以外のArt-Netパケットも出しており、socketで受信したバイナリが19バイト以上で頭12バイトがb'Art-Net\x00\x00\x50\x00\x0E'であることを最初にチェックしないといけません。当初はバイト長も見ずにb'Art-Net\x00'だけでチェックしていたのでデコード処理でエラーが頻発でした。OpCodeによってデータ長も内容も違うので当然の結果ですが、マルチキャストなら<0x5000>以外のOpCodeは出さないと先入観で思ってしまったようです。よくないですね。
8ユニバースを受信させています。すべてのユニバースをデコード処理までしていますが、思った以上に軽々動いています。
Sequenceをキーに連続性をチェックしましたが読み飛ばしもしていないようです。
今のところは先日作った画面ではなくすべてのパラメータを表示するチェック用の画面に表示していますが、先日作った画面を同時に動かしてもCPU負荷は45%程度です。最大値は400%(100%×4コア)なのでまだ余裕があります。
#Python #[Art-Net]
先達のサンプルコードをコピペしてPort番号を書き換えただけで一発ＯＫ。積年の成果が出て良かったのですが、あまりにも簡単だったので肩透かし。
複数のNICを使い分けるsocketの設定は先達情報に何パターンかありますが、Rasbian上のPythonに合うパターンを見つけるのに少し時間がかかったかもしれません。
今は卓のエフェクトエンジンで出力したデータが画面に流れております。4096chのディマーを256bpmの正弦波で動かしています。アホか。
テストデータはMAdot2からですが、SequenceとPhysicalにデータが出ていました。
Sequenceは単純なインクリメント情報、Physicalは卓内のUnivres番号です。
送信を作るときにはこの流儀を真似しましょう。
ただ、MAdot2はOpCode<0x5000>以外のArt-Netパケットも出しており、socketで受信したバイナリが19バイト以上で頭12バイトがb'Art-Net\x00\x00\x50\x00\x0E'であることを最初にチェックしないといけません。当初はバイト長も見ずにb'Art-Net\x00'だけでチェックしていたのでデコード処理でエラーが頻発でした。OpCodeによってデータ長も内容も違うので当然の結果ですが、マルチキャストなら<0x5000>以外のOpCodeは出さないと先入観で思ってしまったようです。よくないですね。
8ユニバースを受信させています。すべてのユニバースをデコード処理までしていますが、思った以上に軽々動いています。
Sequenceをキーに連続性をチェックしましたが読み飛ばしもしていないようです。
今のところは先日作った画面ではなくすべてのパラメータを表示するチェック用の画面に表示していますが、先日作った画面を同時に動かしてもCPU負荷は45%程度です。最大値は400%(100%×4コア)なのでまだ余裕があります。
#Python #[Art-Net]
雪に隠れていた縁石に自家用車のタイヤをやられました。
鋭利に割れていたのでサイドウォールがパックリ。雪は滑るだけが危険要素ぢゃないようです。
サイドウォールは修理が出来ないので交換ですが、冬タイヤはトップシーズンのために割高な物しか手に入らず懐も寒くなりました。
運が悪かったと思うしかありませんが、テンション下がるわー。
開発が順調でテンションが上がっているので丁度いいのかもしれませんけど。
#日常
鋭利に割れていたのでサイドウォールがパックリ。雪は滑るだけが危険要素ぢゃないようです。
サイドウォールは修理が出来ないので交換ですが、冬タイヤはトップシーズンのために割高な物しか手に入らず懐も寒くなりました。
運が悪かったと思うしかありませんが、テンション下がるわー。
開発が順調でテンションが上がっているので丁度いいのかもしれませんけど。
#日常
RaspberryPiを触っていて思うのですが、普通のPCにもRaspberryPi並みのGPIOがあればいいなと。
RaspberryPi仕様のGPIOがベストって意味ではありませんが、PCにもローレベルのインターフェースがあったら制御で便利に使えるのになと。
もちろん存在していますが、あまりにニッチ過ぎて情報が少ないために敷居が高いのです。
主にUSB接続ですが、PCI-eボード１枚にI2C、SPI、USART、GPIOが「これでもか！」ってくらい載ってるのがあったら欲しいかも。
#妄想
RaspberryPi仕様のGPIOがベストって意味ではありませんが、PCにもローレベルのインターフェースがあったら制御で便利に使えるのになと。
もちろん存在していますが、あまりにニッチ過ぎて情報が少ないために敷居が高いのです。
主にUSB接続ですが、PCI-eボード１枚にI2C、SPI、USART、GPIOが「これでもか！」ってくらい載ってるのがあったら欲しいかも。
#妄想