電装工芸日記
- 舞台照明機器の製作とか -
全年全月10日の投稿［25件］
2024年4月 この範囲を時系列順で読む この範囲をファイルに出力する
RaspberryPiトランクへの実装で電源の上に RaspberryPi を取り付けたところ Wi-fi が機能しない。電源から遠ざけると機能する。
電源の直近ですから磁界が強いのだと思いますが、美味しい空きスペースに置けないのは残念。
#RaspberryPi
電源の直近ですから磁界が強いのだと思いますが、美味しい空きスペースに置けないのは残念。
#RaspberryPi
2024年3月 この範囲を時系列順で読む この範囲をファイルに出力する
共有メモリの読み書きのタイミングを考えています。
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は１プロセスで動作します。RaspberryPiでも１プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#Ｃ言語
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は１プロセスで動作します。RaspberryPiでも１プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#Ｃ言語
2024年2月 この範囲を時系列順で読む この範囲をファイルに出力する
修理と言えば PegasysG10 のリペアも進めています。
パッキン施工が甘く水漏れダメージが酷い品が終わり、ネジ穴の位置が旧タイプと違う現行の電源モジュールへの換装手順も確立しましたので、１台あたり２時間程度で進められる様になりました。ケーブルを交換してこのラップタイムなら悪くありません。毎日は出来ませんが、これなら時間が空いた時に１台仕上げることが出来ますので、今月中に全数終わるかなぁ～って気分になってます。つか、今月中に終わりにして次に行きたい・・・。
あとは、１台を人身御供にして最悪環境を想定した漏水チェックをしたいかも。３ヶ月くらい屋外放置することもあるので、今の施工で耐えられるのか確認したいのです。
#器具の修理
パッキン施工が甘く水漏れダメージが酷い品が終わり、ネジ穴の位置が旧タイプと違う現行の電源モジュールへの換装手順も確立しましたので、１台あたり２時間程度で進められる様になりました。ケーブルを交換してこのラップタイムなら悪くありません。毎日は出来ませんが、これなら時間が空いた時に１台仕上げることが出来ますので、今月中に全数終わるかなぁ～って気分になってます。つか、今月中に終わりにして次に行きたい・・・。
あとは、１台を人身御供にして最悪環境を想定した漏水チェックをしたいかも。３ヶ月くらい屋外放置することもあるので、今の施工で耐えられるのか確認したいのです。
#器具の修理
2023年11月 この範囲を時系列順で読む この範囲をファイルに出力する
マルチツールをポチってしまいました！振動工具の一種ですが、専門職の方や工具オタク以外は知らないと思われる電動工具です。
製品はHiKOKIさんのCV12DAです。手持ち電動工具はmakitaさん一強の世の中ですが、父が前身である日立工機を勤め上げた人なので可能な限りHiKOKIを選ぶ様にしています。
ナゼ購入に至ったかというならば、プルボックスにC型30Aコンセントを取り付けるためです。C型30Aコンセントを取り付けるには角穴を空けなければなりませんが、すでに箱になっている物の横っ腹に角穴を空けるのは案外難しい。手元の工具ならPROXXONのフライスマシン、ジグソー、トリマーなどが候補となりますが、どれも平板や角材などの原材の加工には便利なものの箱を相手にするのは苦手です。
マルチツールはその名の通り１台で何役も兼ねる工具ですが、基本の一つであるノコ刃を使えば平面の途中に切れ目を入れることが出来ます。これで四角を描けば角穴になるワケです。フリーハンドで当ててもそれなりに切れるそうですが、ネジ穴との位置関係も重要ですし、ケガく手間も減らせるものなら減らしたいので、ガイド(治具)を作って効率を上げてみましょう。
現物の到着は数日後ですが、同じ頃に箱も入荷しますので試し切りをしてみたいですね。
#ガチ工作 #器具の製作
製品はHiKOKIさんのCV12DAです。手持ち電動工具はmakitaさん一強の世の中ですが、父が前身である日立工機を勤め上げた人なので可能な限りHiKOKIを選ぶ様にしています。
ナゼ購入に至ったかというならば、プルボックスにC型30Aコンセントを取り付けるためです。C型30Aコンセントを取り付けるには角穴を空けなければなりませんが、すでに箱になっている物の横っ腹に角穴を空けるのは案外難しい。手元の工具ならPROXXONのフライスマシン、ジグソー、トリマーなどが候補となりますが、どれも平板や角材などの原材の加工には便利なものの箱を相手にするのは苦手です。
マルチツールはその名の通り１台で何役も兼ねる工具ですが、基本の一つであるノコ刃を使えば平面の途中に切れ目を入れることが出来ます。これで四角を描けば角穴になるワケです。フリーハンドで当ててもそれなりに切れるそうですが、ネジ穴との位置関係も重要ですし、ケガく手間も減らせるものなら減らしたいので、ガイド(治具)を作って効率を上げてみましょう。
現物の到着は数日後ですが、同じ頃に箱も入荷しますので試し切りをしてみたいですね。
#ガチ工作 #器具の製作
2023年9月 この範囲を時系列順で読む この範囲をファイルに出力する
「error: Unable to find vcvarsall.bat」とのエラーで困ったものの解決しました。
以下、オレメモであります。
あえて gcc を使うのは Linux で標準だからです。
VSCode で gcc を使う
2023年9月10日実施
● OS
エディション: Windows11 Pro x64
バージョン: 21H2
● Visual Studio Code
バージョン: 1.74.2 (user setup)
※ ダウンロード量が 1.8GB くらいあるのでネット回線が良好な環境での作業を推奨します。
● gcc をインストールする
・gcc を GitHub からダウンロード
https://github.com/niXman/mingw-builds-b...
「Release of 13.1.0-rt_v11-rev1」の項から Windows64bit版
ダウンロード項目: x86_64-13.1.0-release-win32-seh-msvcrt-rt_v11-rev1.7z
・圧縮ファイルなので解凍する。.7z ファイルは CubeICE で解凍可能。「mingw64」フォルダが出来る。
・「mingw64」フォルダごと任意の位置に配置する。"C:\Program Files"が適当？」
・PATH を通しておく。環境変数のPATHに「mingw64\bin」を追加する。今回は"C:\Program Files\mingw64\bin"とする。
「Windowsメニュー」→「設定」→「システム」→「バージョン情報」
→「関連リンク」の行の「システムの詳細設定」をクリック。
→ ウィンドウ下の方の「環境変数」をクリック。
→ 上段のリスト、PATHの行をクリックし、「編集」をクリック。
→ 表示されたリストに"C:\Program Files\mingw64\bin"を追記する。
→ 追記したら閉じる。
・確認
コマンドプロンプトか Power Shell で次を実行
> gcc -v
もろもろ表示された最後に以下が表示されればOK。
gcc version 13.1.0 (x86_64-win32-seh-rev1, Built by MinGW-Builds project)
● Microsoft C++ Build Tools をインストールする
・microsoft のサイトよりインストーラーをダウンロード
https://visualstudio.microsoft.com/ja/vi...
※「Microsoft C++ Build Tools」で検索しても上記 URL に行きつかない。試行錯誤中、偶然行きついた。
・ブラウザの「Build Tools のダウンロード」をクリックすると「vs_BuildTools.exe」がダウンロードされる
・ダウンロードしたインストーラーを起動する。
・「Visual Studio Installer」と画面が出てファイルのダウンロードが始まる。
・画面が切り替わり、右項目「インストールの詳細」に「MSBuild Tools」が表示されているの確認。
・左項目「C++によるデスクトップ開発」をクリック。右項目「インストールの詳細」に追加されているのを確認。オプションはデフォストのまま。
・右下の「インストール」をクリック。終わるまで待つ。ダウンロード量が 1.7GB ある。かなり時間がかかる。
・終了したら Windows を再起動する。
● VSCode の設定・・・拡張機能をインストール
・C/C++ Extension Pack
・Code Runner
● VSCode の設定・・・拡張機能の設定
・Code Runner
Code-runner: Run In Terminal
→ チェックを入れる
Code-runner: Executor Map
→ settings.json をクリック
→ "c" に -fexec-charset=CP932 を書き加える
- "c" : "cd $dir && gcc $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
+ "c" : "cd $dir && gcc -fexec-charset=CP932 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
次のサイトの例題がコンパイル出来、Python からの呼び出しで動作しました。
「PythonからC言語の関数を呼び出す（基本編）」
Ｃ/Ｃ＋＋のライブラリを Python で呼び出せると製作の幅が広がります。
手始めにしては難しい課題ですが、DoctorMX を Python から使えるようにしてみたいですね。
#Ｃ言語 #Python
以下、オレメモであります。
あえて gcc を使うのは Linux で標準だからです。
VSCode で gcc を使う
2023年9月10日実施
● OS
エディション: Windows11 Pro x64
バージョン: 21H2
● Visual Studio Code
バージョン: 1.74.2 (user setup)
※ ダウンロード量が 1.8GB くらいあるのでネット回線が良好な環境での作業を推奨します。
● gcc をインストールする
・gcc を GitHub からダウンロード
https://github.com/niXman/mingw-builds-b...
「Release of 13.1.0-rt_v11-rev1」の項から Windows64bit版
ダウンロード項目: x86_64-13.1.0-release-win32-seh-msvcrt-rt_v11-rev1.7z
・圧縮ファイルなので解凍する。.7z ファイルは CubeICE で解凍可能。「mingw64」フォルダが出来る。
・「mingw64」フォルダごと任意の位置に配置する。"C:\Program Files"が適当？」
・PATH を通しておく。環境変数のPATHに「mingw64\bin」を追加する。今回は"C:\Program Files\mingw64\bin"とする。
「Windowsメニュー」→「設定」→「システム」→「バージョン情報」
→「関連リンク」の行の「システムの詳細設定」をクリック。
→ ウィンドウ下の方の「環境変数」をクリック。
→ 上段のリスト、PATHの行をクリックし、「編集」をクリック。
→ 表示されたリストに"C:\Program Files\mingw64\bin"を追記する。
→ 追記したら閉じる。
・確認
コマンドプロンプトか Power Shell で次を実行
> gcc -v
もろもろ表示された最後に以下が表示されればOK。
gcc version 13.1.0 (x86_64-win32-seh-rev1, Built by MinGW-Builds project)
● Microsoft C++ Build Tools をインストールする
・microsoft のサイトよりインストーラーをダウンロード
https://visualstudio.microsoft.com/ja/vi...
※「Microsoft C++ Build Tools」で検索しても上記 URL に行きつかない。試行錯誤中、偶然行きついた。
・ブラウザの「Build Tools のダウンロード」をクリックすると「vs_BuildTools.exe」がダウンロードされる
・ダウンロードしたインストーラーを起動する。
・「Visual Studio Installer」と画面が出てファイルのダウンロードが始まる。
・画面が切り替わり、右項目「インストールの詳細」に「MSBuild Tools」が表示されているの確認。
・左項目「C++によるデスクトップ開発」をクリック。右項目「インストールの詳細」に追加されているのを確認。オプションはデフォストのまま。
・右下の「インストール」をクリック。終わるまで待つ。ダウンロード量が 1.7GB ある。かなり時間がかかる。
・終了したら Windows を再起動する。
● VSCode の設定・・・拡張機能をインストール
・C/C++ Extension Pack
・Code Runner
● VSCode の設定・・・拡張機能の設定
・Code Runner
Code-runner: Run In Terminal
→ チェックを入れる
Code-runner: Executor Map
→ settings.json をクリック
→ "c" に -fexec-charset=CP932 を書き加える
- "c" : "cd $dir && gcc $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
+ "c" : "cd $dir && gcc -fexec-charset=CP932 $fileName -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
次のサイトの例題がコンパイル出来、Python からの呼び出しで動作しました。
「PythonからC言語の関数を呼び出す（基本編）」
Ｃ/Ｃ＋＋のライブラリを Python で呼び出せると製作の幅が広がります。
手始めにしては難しい課題ですが、DoctorMX を Python から使えるようにしてみたいですね。
#Ｃ言語 #Python
2023年8月 この範囲を時系列順で読む この範囲をファイルに出力する
29.97fp-NDF の場合、単位時間あたりのフレーム数は 29.97fps で 勘定は 30fps の NDF と同じです。
・・・ってことが頭の中で混乱しました。
29.97fps-NDF はタイムコードの時間勘定が増えるため値の進みが遅くなります。
こういった「増えると減る」みたいな関係は挙動の理解がややこしい。
#タイムコード
・・・ってことが頭の中で混乱しました。
29.97fps-NDF はタイムコードの時間勘定が増えるため値の進みが遅くなります。
こういった「増えると減る」みたいな関係は挙動の理解がややこしい。
#タイムコード
2023年5月 この範囲を時系列順で読む この範囲をファイルに出力する
TRUE1のY分岐とT分岐の試作は繋ぎ目にコーキングを入れて終わりました。
数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでＯＫなら防滴性能があるとしていいでしょう。
#器具の製作
数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでＯＫなら防滴性能があるとしていいでしょう。
#器具の製作
MIDIのビットレートは31,250kbps、8MHzの256分の１です。
ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
これならPICのUARTで誤差無しで扱えます。
送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。
凄くシンプルなMTCジェネレーターならすぐ作れそうです。
#タイムコード
ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
これならPICのUARTで誤差無しで扱えます。
送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。
凄くシンプルなMTCジェネレーターならすぐ作れそうです。
#タイムコード
パソコンの音声再生アプリにはタイムコードを出す物があるらしい。
様々なアプリがあるので一概に言えませんが、タイムコードはLTCではなくMIDI-TimeCode(以下、MTC)ではないかと思われます。というか、それらのアプリの用途を考えたらMTCが自然かと。
LTCのメリットは音声信号であるため配線の選択肢が多いことです。仕込みの効率が良いのでLTCを望んでいるのです。
ですが、既存のアプリが使えるならその流儀を優先させた方が良いかもしれません。LTCを扱える調光卓はMTCも扱えますし、音声再生の視点ではMTCの方が汎用性が高いからです。
LTCのメリットでありMIDIの弱点となるのは音声信号として扱えるかと配線長です。この辺りを対策すれば音声再生側も調光卓側もMTCでいいんじゃないかと。
さて、どうしましょう。
LTCのメリットとMTCのメリットを足して、MTCを音声信号として送れるようにすればよくね？
MIDI全般に対応する気はありませんから、MTCに特化して音声信号(差動バイフェーズ)として送るのです。
参考
MIDIタイムコード規格
MIDIタイムコード(MTC)について調べてみた
有志の方のサイトです。
ここで言うMTCは記事にある「クォーター・フレーム・メッセージ F1 dd」のことです。
MTC(コマンド0xF1)はMIDIの回線をタイムコードで占有しないために２フレーム分の時間を使って送信するようです。
バイト送信のタイミングはMTCを出す側に依存するとしても、１フレームの時間で８バイト送れればいい。MTCに完全特化してコマンド0xF1を省けば４バイトです。
４バイトなら１フレームの時間内で40bit送れればよく、最もビットレートが速い30fpsでも1,200bpsあれば事足ります。差動バイフェーズで音声信号化しても問題無しです。
受信側はバイト受信の度に0xF1を付けた2バイトをMIDIとして送出するだけです。
この方法は僅かな遅れを生じますが、MTCは２フレーム遅れるのが前提の規格ですし、遅れが一定ならば実用上の問題は無いと考えます。
分解能が1/12～1/15秒であることもMTCの前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード
様々なアプリがあるので一概に言えませんが、タイムコードはLTCではなくMIDI-TimeCode(以下、MTC)ではないかと思われます。というか、それらのアプリの用途を考えたらMTCが自然かと。
LTCのメリットは音声信号であるため配線の選択肢が多いことです。仕込みの効率が良いのでLTCを望んでいるのです。
ですが、既存のアプリが使えるならその流儀を優先させた方が良いかもしれません。LTCを扱える調光卓はMTCも扱えますし、音声再生の視点ではMTCの方が汎用性が高いからです。
LTCのメリットでありMIDIの弱点となるのは音声信号として扱えるかと配線長です。この辺りを対策すれば音声再生側も調光卓側もMTCでいいんじゃないかと。
さて、どうしましょう。
LTCのメリットとMTCのメリットを足して、MTCを音声信号として送れるようにすればよくね？
MIDI全般に対応する気はありませんから、MTCに特化して音声信号(差動バイフェーズ)として送るのです。
参考
MIDIタイムコード規格
MIDIタイムコード(MTC)について調べてみた
有志の方のサイトです。
ここで言うMTCは記事にある「クォーター・フレーム・メッセージ F1 dd」のことです。
MTC(コマンド0xF1)はMIDIの回線をタイムコードで占有しないために２フレーム分の時間を使って送信するようです。
バイト送信のタイミングはMTCを出す側に依存するとしても、１フレームの時間で８バイト送れればいい。MTCに完全特化してコマンド0xF1を省けば４バイトです。
４バイトなら１フレームの時間内で40bit送れればよく、最もビットレートが速い30fpsでも1,200bpsあれば事足ります。差動バイフェーズで音声信号化しても問題無しです。
受信側はバイト受信の度に0xF1を付けた2バイトをMIDIとして送出するだけです。
この方法は僅かな遅れを生じますが、MTCは２フレーム遅れるのが前提の規格ですし、遅れが一定ならば実用上の問題は無いと考えます。
分解能が1/12～1/15秒であることもMTCの前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード