2023年1月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 新年あけましておめでとうございます
 本年もよろしくお願い申し上げます

 さて、さかのぼること大晦日の夕方、実家に顔を出そうと思ったのですがどうも熱っぽい。計ると37.2度。
 ダルさは若干あるものの、抜けきっていない疲れなのか、流行り病の前兆なのかわかりません。
 大事を取って自宅に引きこもり。
 暇なんでRaspberryPiをC言語で開発する環境についてアレコレ調べています。
 大晦日に何してんの?って突っ込みは正しいと思いますが、外出出来ないのだから仕方ない。

 PythonはTeraTermでSSH接続してRaspberryPi上のViとかnanoとかで書いていました。debianに標準搭載のテキストエディタです。Windows上で操作すればコピペも出来るので特に不自由はありませんが、色々調べるウチにVSCodeが便利そうで使いたくなりました。C言語はカッコや行末のセミコロンを忘れてコンパイルエラーになることが多いのですが、これを防止する為だけに使っても意味があります。
 世の中進歩するというか便利なツールを作ってくれる貴兄がおりまして、VSCodeはプラグインを入れるとSSHで完全にリモート操作が出来る。コーディングはもちろんのこと、コンパイルもデバッグも出来るとのこと。すばらしい。
Visual Studio Codeを使ったC言語リモートコンパイルからリモートデバッグまで
 ゼロから設定するなら本文中にあるリンク「参考にした解説」も読む必要があります。
Visual Studio CodeでLinux ホストリモート開発
 ちょっと面倒ですが、SSHでリモート開発したいなんて考える人ならそれほど苦にならないでしょう。

 VSCodeは様々な言語をサポートしてくれる超絶強力なコーディングエディタです。

#C言語
Icon of admin
 Windows上のVSCodeからSSHでRaspberryPiに接続してコードを編集・コンパイル・実行してみました。
 コードは俗に言う「Hello, World」。コンソールに簡単な文字列を表示するだけのモノです。
 VSCodeはユーザーインターフェースのデザイン更新が頻繁なのか、ネットの解説は出来るだけ新しいモノを参考にしないと見た目が違います。
 インストールと設定は次の通り。

 まずはRaspberryPi側から。sshでつながることを前提とする。
1)対象となるRaspberryPiをアップデート
 $ sudo apt update
 $ sudo apt upgrade
2)build-essentialをインストール。
 $ sudo apt install build-essential
 デバッカーのgdbが必要になる、上記で入らなかったらインストール
 $ sudo apt install gdb

 Windows(11)側
1)VSCodeをダウンロード
 https://code.visualstudio.comってのが本家みたい。
 環境に合わせてインストーラーをダウンロード
2)インストール
 ダウンロードしたインストーラーを起動して初期設定のまま進めてインストール。選択項目がある場合はよくわからんけど一番上を選択。
3)起動後、機能拡張の日本語パックを入れる(参考ページは呆れるほどあります)
 機能拡張のメニューから「Japanese Language Pack for Visual Studio Code」をインストール
 インストール後、アプリを再起動すると大半のメニューが日本語になっています。
4)同じく機能拡張の「Remote Development」を入れる
 他に必要な機能拡張は自動的に入ります。
5)ssh接続してみる
 以下を参考にすれば繋がると思います。
 「Visual Studio Codeを使ったC言語リモートコンパイルからリモートデバッグまで」
6)初回接続ではRaspberryPi側にも色々入れるようで少し時間がかかります。
7)この他にも自動的に入った機能拡張がありますが、よくわからんのでここには書きません。

 Windows上のVSCodeでコーディング、コンパイル、デバッグ、実行が出来ました。
 ブレークポイントありのデバッカーまで使えるのですから、Turbo-CのトラウマでC言語を敬遠していた時間が勿体ないと思える程に便利です。

#C言語
Icon of admin
 VSCodeのSSH環境作りは予想外に簡単でした。
 自宅でファイルサーバーになっているRaspberryPiに接続してC言語の実習をしております。
 まずは基本であり多用するであろうポインタによる関数の呼び出し方です。ポインタはその昔挫折した要素でありますが、どうも勘違いのままアタマに刷り込まれてしまったようで、わかっているつもりなのに間違った組み立てが浮かんできます。これは正しい組み方を刷り込み直すしかありませんので、自分なりの課題で実験を繰り返すしかありません。
 つい先ほど整理出来たのですが、ポインタ変数は定義した直後はnull値であって特定のアドレスは持っていません。int *num では実体の変数は定義されないということがわかったのですが、正にこういった点がその昔の勘違いなんですよね。「ポインタは実体変数の扱いを補助するための機能」という前提がアタマに入ったのでスッキリしました。「実体ではない」ということが明確になっただけでも私の中では大革命です。

 あと、インクリメントとデクリメントについてメモ。
 C言語では++numと書かないと期待値になりません。雰囲気的にnum++と書いてしまいがちですが、エラーにならんのにインクリメントされんのです。
 デクリメントも--numとしないといけません。
 計算記号が行頭にあっていいのかって疑問が湧きますが、慣用句として覚えておきましょう。

 それにしてもVSCode+SSH+gcc+gdb環境は便利ですねぇ。
 コンパイルから実行までの手数や所要時間が画期的に短い。エラーも丁寧に教えてくれるし、メモリがマネージされているからヘタなモノ書いてもシステムが飛ぶこともない。スクリプト言語をチョイチョイ書いているのと大差ありません。
 デバッカーのお世話になるレベルになるにはまだまだかかりそうですが、こんなに簡単にC言語が扱えるなんて私の中では画期的過ぎです。25年前と一緒にすんなって話ですけどね。

#C言語
Icon of admin
 C言語はプロセスの管理方法を調査中です。
 直近の課題はAr-Netパッチです。この機構は大きく分けて、(1)Art-Netエンジン(受信、パッチ、送信)、(2)DMXの状況モニタ表示、(3)ユーザーからのコマンド操作となります。
 C言語で書けば主な機能をスレッドに分ければいいような気もしますが、スレッドを分けるのもプロセスを分けるのも手間は大差ないので、プロセスを分けておけばいいかなと。

 先日も書きましたが、ランチャー的な親プロセスから各機能を子プロセスとして起動しようと思っています。これなら親プロセスで共有メモリを定義して子プロセスにポインタを渡すことが簡単だからです。また、子プロセスとして起動するなら親プロセスがプロセスIDを確実に把握出来ますので管理上のメリットもあります。
 まだわからない調査中のことは、子プロセスの終了のさせ方です。killコマンドでプロセスを消す方法はありますが、後処理(設定の現在値の保存など)をしてから子プロセスを終了したいので、有無言わさずプロセスを消すkillコマンドはよろしくありません。望ましいのは、親プロセスからコマンドを送って子プロセス自身で終了させることです。Python的に考えるなら、親プロセスからの指示で子プロセスに何かしらの例外が発生してwhileをbreakで抜け出すような処理です。共有メモリでコマンドをやり取りするのが現実的だと思いますが、出来るだけシンプルで汎用的な方法を構築したいところです。

 いずれにしても、親プロセスから子プロセスを起動し、プロセス間で通信(変数の共有)をし、親プロセスから子プロセスを終了させる方法の定型化です。

 もう少し学習が進んでからになりますが、共有メモリの挙動も調査しないといけません。
 共有メモリは複数のプロセスから読み書きできるメモリ空間ですが、マネジメントされていませんので衝突(読み書きの処理タイミングが被ること)による不整合が起きる可能性があります。これを回避する手段としてセマフォなどの機能があるのですが、出来るだけシンプルな方法を見つけたいと思っています。
 調査したいのは、共有メモリに書き込み出来るプロセスを唯一とし、他のプロセスは読み出しのみとした場合にどうかという点です。機能的に共有メモリの読み書きは頻繁に行われますので出来るだけ手数を少なくしたいのですが、結果的に書き込みのタイミングをマネジメントしなくていいなら手数は最小だし、何かが必要だとしてもどこまでやるのかを知りたいワケです。

#C言語
Icon of admin
 現場が早く終わったので、開発用のRaspberryPiをノートパソコンのVSCodeと繋いでおきました。ここまでしておけば比較的身軽に開発が出来ます。
 本格的に開発を進めましょう。

 C言語でのsocketについて調べてみましたが、PythonのscoketライブラリはC言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。

#C言語 #[Art-Net]
Icon of admin
 C言語の基本的な書き方は整理がついてきました。
 次はライブラリの理解と使い方となるのですが、ネットで検索しても情報があるっちゃあるけどイマイチ感。
 基本に立ち戻れば、ライブラリのman(公式のマニュアルファイル)とヘッダーファイルを読めとなります。以前からそうするのが王道とは思ってはいましたが、何が書いてあるのかサッパリでした。
 それが少しわかるようになってきました。我ながら大進歩。
 manはLinux系のOSなら本体にも必ず入っているものの英文が多いのですが、ネットで検索すると日本語版がすぐに見つかるのでこちらを読んだ方がいいかも。
 かといってman読めばいいかと言えばそうでもない。前触れもなく突然出現する用語やパラメータが多い。
 ようやくわかったのですが、ライブラリのmanはヘッダーファイルを補足しているに過ぎないらしい。つまり、ライブラリを理解するための主役はmanではなくヘッダーファイルということ。
 変数の型定義、構造体の定義、プロトタイプ宣言などが書かれているヘッダーファイルは定義書であり解説書でもありますので、これを読み解けない人がC言語でプログラムを書けるワケないでしょう・・・という熟練者たちのご意見はその通りです。
 どこを読むべきか、何を理解するべきかが見えて来ただけでも今日のところはいいんじゃないかと。

 早速、socketのライブラリである sys/scoket.h を読んでみようと /usr/include を覗いたのですがありません。
 google様に教えてもらい、次のコマンドで在処を検索できました。
 $ sudo dpkg --search sys/socket.h
 結果は /usr/include/arm-linux-gnueabihf/sys/socket.h とのことでした。
 パッと見ではサッパリわかりませんが、半分くらいはわかるので、全体を理解出来る様に頑張ってみましょう。

#C言語
Icon of admin
 屋外で開催される成人式関連のイベントで電源出しです。
 起動してしまえばやることはありません。
 本日の課題は共有メモリのテストです。

 次のページにあるソースをそのまま使って挙動を確認です。
 プロセス間でのメモリ共有

 親プロセス「ShareMemTest1」を起動した後、待機時間(20秒)のうちにコンソールで「ShareMemTest2」に共有メモリのIDを与えて起動するというもの。一貫したプログラムではありませんが、やりたいことはプロセス間でのメモリ共有ですからむしろわかりやすい。
 ちなみに、コンソールでプログラムを起動する際、末尾に「&」を付けると新規プロセスで実行します。

 ここサンプルを使うなら、

 <親プロセスを起動>
$ ./ShareMemTest1 &

 <起動後表示>
nShareMemID = 23 /* IDは都度変わります */
process1 : nVar1 = 1, nVar2 = 2
・・・ここで20秒Sleepしてます・・・

 <子プロセスを起動>
$ ./ShareMemTest2 23 &

 <起動後表示>
nShareMemID = 23
process2 : nVar1 = 1, nVar2 = 2
process2 : nVar1 = 2, nVar2 = 2
・・・子プロセスはここで終了・・・

・・・20秒後、親プロセスが再開・・・
process2 : nVar1 = 2, nVar2 = 2
・・・親プロセスも終了・・・

 となります。
 正に記述にある通り。

$ ipcs -m
 や
$ free
 を用いるとSharedメモリの状況がわかります。

 実際のテストではgetpid()を用いてプロセスIDも表示しながら確認しましたが、確かに別プロセスでした。
 共有メモリの容量は、無意味に8MBくらい設定してみましたが何の問題も無し。

 親側の設定は、typedefで構造体を定義し、構造体のポインタ変数を作り、構造体のメモリサイズ(sizeof()で取得)をもとに共有メモリを作り、構造体のポインタ変数に共有メモリを割り当てる、といった流れでしょうか。
 子側は、typedefで構造体を定義し、構造体のポインタ変数を作り、親から取得したIDから構造体のポインタ変数に共有メモリを割り当てる、といった流れ?
 共有メモリ上に変数(構造体)を構築した後は共有メモリを意識する必要は無いと思います。もちろん、衝突回避は常に考えないといけませんけど。

 勘違いしていた点ですが、共有メモリのIDは管理用の通し番号であってポインタに設定するアドレスではないことです。C言語では何かにつけてポインタ渡しなのでこれもそうかと思ってしまいました。

 共有メモリに構造体を配置することが次の課題ですが、構造体についてもう少し勉強してからです。

#C言語
Icon of admin
 共有メモリに構造体を配置してみましたが、割と簡単でした。
 構造体のタグ(ひな形)をヘッダーファイルに作り、親プロセスと子プロセスにinclude。共有メモリのサイズは構造体のタグから得て設定。共有メモリ上に置く変数を独立したポインタにするとオフセットをそれぞれ計算して与えないといけませんが、構造体なら一括設定出来て便利です。
 構造体をポインタにすると表記が独特になりますが、意味合いが明示的となって読みやすいかもしれません。
 この辺りには、本文中に出来るだけ定数を直書きしないという方針にも繋がってきます。

 次は共有メモリの衝突回避を調べないといけません。

#C言語
Icon of admin
 共有メモリの衝突回避ですが、共有メモリの中にハンドシェイク表すフラグを入れたらそれでいいんじゃないかと。
 そのフラグが立っていれば極々わずかな時間sleepを繰り返す処理です。

while(flag1 == 1)
{
 sleep(0.001);
}
flag2 = 1;
/* 共有メモリ処理 */
flag2 = 0;


 みたいなものです。
 別プロセスがフラグを0にすればwhileを抜けます。
 簡易的なモノですが、フラグを書き換えられるプロセスを一つにしておけばイイんじゃないかと。最も簡単なセマフォはこういうことですし。

 子プロセスの停止制御も同様の考え方が使えます。
 動作し続けるってことは繰り返し処理です。単なる繰り返しはwhile(1)とかで無限ループすることが多いので、while(flag==1)とかにすればいい。共有メモリ上のフラグが1ならwhileでループし0になったら抜ければいいのです。抜けたら終了処理をしてプロセスを落とすと。子プロセスが完全に終わったことはスタックしておいたプロセスIDを見ればわかります。

 この辺りまで決まれば次はランチャーです。

#C言語
Icon of admin
 ランチャーに行く前にscoketの基本動作の確認かな?
 受信したArt-Netパケットをそのまま送信する実験。
 これが求める機能の基本ですから確認せんといかん。

#[Art-Net] #C言語
Icon of admin
 C言語の教科書を幾つか読んでいます。
 熟知した人でないと書けないことですが、熟知した人は初心者の気持ちを忘れた人たちです。どんなに優しく書こうとしても初心者向けの説明など書けません。部分的に初心者の理解を助けてくれる文章があるので複数読んだ方がいいのです。
 お勧めというか、理解しやすかった教科書を2つご紹介します。

「新・明解C言語 入門編」
 初心者が挫折しやすい変数の型、ポインタ、構造体を後回しにして書いているのでC言語の全体像が見えやすい。変数の型、ポインタ、構造体で悩みたくないなら他の言語を使うべきですが、冒頭から「変数の型がぁ~」「ポインタがぁ~」と書かれた解説書は挫折率が高い(俺評価)のでよろしくありません。簡単とは言いませんが、これは挫折し難い内容です。

「苦しんで覚えるC言語」
 書籍にもなっていますが、webでも読める解説書です。途中息切れを感じるところはありますが、これはこれでわかりやすい。

 あと、以前ご紹介した「改訂第3版(5版) ANSI C 対応 はじめてのC」は和文規格書かもしれません。わかりやすい記述も多いのですが、誰もが悩むポインタは触るだけだったりと、誰もが躓くところほど流している傾向があります。すでに習得している人の参考書としてなら悪くありませんケド。

 ただ、総じて言えることですが、C言語はこの時代に初めてプログラムを書く人が使う言語ではありません。画面とキーボード、マウスで完結するシステムならPythonなどの高度にマネージされた言語を使うべきです。なぜなら、CPUのレジスタとかフラグ、メモリの概念が体に染み込んでいないと書式の意味を理解することが難しいからです。私の課題は対象がハードウェアですからPythonよりもC言語の方が適切ってだけです。

#C言語
Icon of admin
 ここ数日は本業で手一杯でした。ライトアップの施工があったのですが、建物の窓を光らせたいとのことで専用の行燈を製作してました。
 簡単な作りではあったのですが思った以上に時間がかかり、徹夜して間に合わせたのはいいですが、その余波で心身共にキツイここ数日。
 8月のお盆明けからの大連チャンでしたが、この後3月中旬までは緩い日程なので、各種製作や開発を進めて行けそうです。

 同時にイロイロ進めますが、とにかくArt-Netエンジンを完成させたい。
 Art-Netエンジンとは、Art-Netを受信し、Merge、In-Delay、Patch、Out-Curve、Out-Delayを施し、Art-Netとして送信するデバイスドライバの様なモジュールです。ユーザーインターフェースなどは別途製作ですが、これが完成すれば求めることの半分は完成です。
 そのためにC言語を学習しているワケですが、ポインタ、構造体、共有メモリ、マルチプロセスの基本が見えてきましたので、これからしばらくはArt-Netの要であるscoketを試そうと思います。C言語でscoketを扱う情報は高位者による高位者向けの高度な物ばかりですが、幸いPythonでの前例がありますので、これをC言語に置き換える方向で読み解いていこうと思います。
 学習を進めれば進める程「ライブラリの使い方はmanとヘッダーファイルを読めば分かるだろ!」という圧を強く感じますが、この感覚が自分にとっても当たり前になるように精進したいものです。

#C言語 #本業 #[Art-Net]
Icon of admin
 RaspberryPiをアップデートしたらネットワーク関連が動かなくなった。
 起動パレードを見ると「Failed to start DHCP Client Daemon.」と出る。

 このサイトの通り手直ししたら治った。

 抜粋すると次の通り。

$ sudo nano /etc/systemd/system/dhcpcd.service.d/wait.conf

Change from:
[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

To:
[Service]
ExecStart=
ExecStart=/usr/sbin/dhcpcd -q -w


 wait.confを訂正するってことです。

#RaspberryPi
Icon of admin
 Art-Netを受信する準備を進めています。
 思った以上に面倒だったのはデータの比較です。受信値と期待値を比較して処理を分岐する処理は重要です。文字列ならstrcmp、バイナリならmemcmpを使います。どちらもstring.hの関数です。
 どちらにしてもバイナリな感覚を持ち合わせていないと使えませんが、アセンブラに慣れた体にとって違和感はありませんし、ある意味とても明確な処理になるので悪い気はしません。Pythonが如何に簡単に書けるかを感じたりはしましたけどね。
 あとはエンディアンの処理です。RaspberryPiはARM系なのでリトルエンディアンです。受信したArt-Netを仕分けて情報にするには2-4バイトのバイナリを数値化しないといけませんが、エンディアンを気にしながらバイナリを並べて処理します。並べたバイナリを数値化するにはカッコとアンパサンドを使った不思議な記述をしますが、理解不能なので定型句と思って使っています。
 こんな底辺処理が整理出来たら受信テストですが、これらを先にやっておかないと受信値を人が読める形で表示することが出来ないのです。

#[Art-Net] #C言語
Icon of admin
 本業が落ち着いたので所属会社の作業部屋を片付けをしています。
 コンセプトマシンで使うオンジナオイルの20Lの空き缶2個の処分で悩む。捨てようと思えば捨てられますが、一般家庭ゴミでは出せませんので面倒。
 ならば、イスにしてしまいましょう。
 上面に丸く切ったコンパネを貼り、床を傷つけないように底面の縁にゴムのエッジ材を取り回しました。すべて余り材とジャンク品で済んだので目先のお金はゼロ。
 しばらくは作業部屋とジャンク材の片付けです。キレイ好きとは真逆ですが、次の作業のためにもやっておかないといけません。

#本業
Icon of admin
 秋月電子通商さんでRaspberryPi4Bが販売されていました。
 特需ですぐに無くなってしまう?
 お金は辛いですが、とりあえず3個発注しました。

#RaspberryPi
Icon of admin
 RaspberryPiにRTC(リアルタイムクロック)を入れているのに起動の度に時間がずれる。
 チェックしたところRTCモジュールの電池がダメになっています。定格3.3vのところ0.6vしかない。
 RTCのチップはDS3231ですが、電池には充電タイプのLIR2032(LRではなくLIR)を使えばいいらしい。
 amazonにあったのでポチる。先ほど届いたので取り付けたところRTCの機能が回復。
 Art-Netエンジンのテストプログラムを書いていて気持ち悪かったのでスッキリしました。

追記
 時刻合わせは
$ sudo ntpdate ntp.nict.jp
 ネットワーク経由で現在時を取得し、
$ sudo hwclock -w
 DS3231に書き込みます。
 この手順をした後、電源を完全に切ってから起動すると時刻が合っているハズです。
 時刻が初期化されてしまうならDS3231の電池がNGかと。

#RaspberryPi
Icon of admin
 珍しく明日から3連休。すべてを自由に使えるワケではありませんがscocketのテストが出来そう。
 Art-Netを扱える卓に繋いで実験しなければなりませんので場所が限られるのです。

#[Art-Net]
 
Icon of admin
 RTCを装着したRaspberryPiは正常のようです。
 今後製作する装置にもRTCを装着したいのですが、電池切れをどうやって拾うか思案中です。

 socketの実験は連休中に時間が取れず未対応です。
 Art-Netの受信と送信を1台でこなすにはIPアドレス的には同じゾーンで装置は別という変な構成になります。その上、broadcastで受けてbroadcastで送るというこれもまた変な構成です。ですので、コピペで使える先例がありそうでありません。
 RaspberryPiのPythonでは成功していることですから可能だと思いますが、C言語のsocketの方が設定すべきパラメータが多いため、Pythonには無かった設定をどうするかが難問なのです。難しいというより、「ネットワークデバイスを指定してbroadcastで通信する」という前提の先例が少なく、沢山のデータシートを継ぎハギしないと見えないことが多いために苦心しているところです。

#RaspberryPi #C言語 #[Art-Net]
Icon of admin
 オレメモであります。
 参考になりそうな先達のページ

● UDP/IP通信全体の参考
UDP / IP でパケットの送受信を行う
● broadcast通信の参考
UDPブロードキャスト送信サンプル
● ネットワークデバイスを指定した通信の参考
Ethernetインターフェース(eth0, eth1)を指定してソケットを作成する (Linux, C, Raspberry Pi)
● 受信タイムアウトの参考
selectを使用してタイムアウト付き受信を実現する <= recvもrecvfromも受信があるまでひたすら待ち続けるので、タイムアウトさせることは必須。
UDP通信におけるselectの使い方。 <= recvの例が多い中、recvfromの書式を確認出来る。recvfromを使う理由は送信元アドレスを取得したいから。
● 時間の扱い方
時間情報の取得方法と扱い方 <= これの5ページ目の「POSIX環境」が結構大事。DelayをするにもDMXのタイムアウトをするにもこれが必要。
● ターミナルの行長と行数を取得する
ターミナルのサイズを取得する
ターミナルの幅と高さを得る
● ANSIエスケープシーケンス
ANSIエスケープシーケンス チートシート

 この辺りを参考にすれば「ネットワークデバイスを指定してbroadcastで通信する」が出来そうな気がします。
 ただし、1行々々読み込んで使われている構造体をよく把握することが大切です。構造体の中に必要な情報が隠れていることが多いからです。構造体の中に構造体があったりもするので、十分に読み込まないといけません。

 実験は受信が当面の課題となり、
1)ネットワークデバイスを指定せずArt-Netを受信する。<= とにかく受信する
2)ネットワークデバイスを指定してArt-Netを受信する。<= ネットワークデバイスを制限して受信する。
3)送信元IPアドレスを取得し、IPアドレスをもとに受信値を振り分ける。<= 複数の送信元(卓)がある場合の不確実性排除とミックス処理のためには不可欠。
 といった手順で進めることになろうかと思います。
 受信値を確認するため、習作を兼ね、バイナリをダンプ表示をするライブラリも作ってみましょう。

#C言語 #[Art-Net]
Icon of admin
 本業では社内のサーバーやパソコンのメンテをしていますが、処理の待ち時間でC言語のお勉強。
 時間についてです。
 DMXを扱うには無受信1秒でタイムアウトしなければなりませんし、Delayを構成するには1/30~1/50秒程度のインターバルタイムで受信値をスタックしなければなりません。
 ですので、msec(1/1000)クラスの時間評価が必要です。

 システムが持つ時間情報を扱うには<time.h>を用い、エポック秒やPOSIX時間などと呼ばれる基準日時(1970年1月1日0時0分0秒(UTC))からの経過時間(secとnsec)を使うのがよいと思います。有効な精度は10usec程度の様ですが、今現在書いている処理では十分です。これを処理の節目でスタックして経過時間を評価するのですが、年月日時でパラメータが分かれているよりもトータル秒数の方が扱いが簡単です。23時59分59秒の1秒後に0時0分0秒にならないタイマで継続した時間評価をしたいのでこの方がいいと思います。
 ただ、スタックする変数のバイト長には気を付けないといけません。secもnsecもそれぞれ4バイト数なので評価をするには8バイト数で考えないといけないからです。64bitOSならint型でも8バイト数なことが多いので問題ありませんが、私はRaspberryPiで32bitOSを使っているのでint型は4バイト数になります。対策には8バイト数である「(unsigned) long long int」型を使います。ちょっとクセがある型なので計算やprintfで注意しないといけませんケドね。

#C言語
Icon of admin
 ダンプ表示のライブラリは出来ました。何の変哲もない16進数のカラム表示です。
 データ配列のポインタ、表示データ数、列数、行数、最上行値のポインタなどを引数にして関数を呼ぶと表示します。
 地味ですが、こういったライブラリがあると開発の効率が良くなるのでは?という想いで作ってみました。後でDMXデータを表示する画面を作る際にも同様のことをするので習作でもあります。

 以下オレメモです。
 ANSIエスケープシーケンスにおいてパラメータに変数を用いたい場合。

 // カーソルをx=10,y=5にして文字列を表示する
#define ESC 0x1B
int main(void) {
 int x = 10 ;
 int y = 5 ;
 printf("%c[%d:%dHカーソルを指定の位置に", ESC, x, y ) ;
 return 0 ;
}

 ※ このブログシステムでは#や[が機能文字扱いなので、上記ではこれらを全角文字で書いています。

 などとします。大昔のN-BASICの「LOCATE + PRINT」みたいなことをしています。
 printfの文字列中のエスケープを\eと直で書くと後に続く%dが機能しませんが、#defineで定義したESC(0x1B)を%cで読み込めば機能します。
 もちろん、printfのESCの位置に0x1Bと直書きしてもいいのですが、#defineした方が読みやすいと思います。

 C言語ではこういった不思議な記述が多いです。正規表現的でもありますが、バイナリ的な指向が各所に出てきます。
 アセンブラに慣れた身に違和感はありませんが、理解に苦しむ要素かもしれません。

#C言語
Icon of admin
 棚上げしていた本業に取り組んでおりますが、ここ10日ほどは残業することも精神的に追われることもない日常を送っているので心身共に回復しております。

 VSCodeのオカゲですが、Pythonと同じ感覚でC言語を使えています。覚えなきゃならないことはまだまだ沢山ありますが、実行ファイルの完成まで1クリックですし、コンパイルエラーの説明がとても丁寧でわかりやすいし、コンパイルの時間もPythonのインタプリタ翻訳と大差ありませんので、方言違いのPythonを書いている様な使い勝手です。相当昔の記憶によりますが、リンカーの処理を勝手にやってくれるだけでも楽ってもんです。
 C言語の取り扱いにはローレベルのコンピュータの知識と摩訶不思議な記述の習得が不可欠ですが、慣れてくるとPythonよりも書いてて楽しいですね。コンピュータを動かしているって実感がPICのアセンブラ並に強いからでしょうか。何をしているかも所要時間もわからない便利なだけのコマンドでハードウェアの制御をするとすべてが遠くに思えて面白くありません。この感覚が変人たる所以かもしれませんが、私の基本はハードウェアを直に動かすPICのアセンブラなんだと改めて思います。

 この先数日は棚上げしていた本業(某劇場の舞台資料)の仕上げをせねばなりませんが、これが終われば半月くらいは自由研究に没頭できそうです。新規のご相談も頂いているので進捗次第ではわかりませんが。。。
 もちろん、息抜きにC言語の学習と試作はしますよ。

#C言語
Icon of admin
 ANSI-CというかLinuxのC言語ではキー入力は「待ち」が基本です。何かキーが入力されるとか、Enterを押されるまで処理が一時停止します。それでも構わないこともありますが、ダメな時もあります。
 WindowsならDxLib.hを使って様々な入力を直に得ることが出来ますが、ANSI-Cの標準ライブラリには同様の物がありません。
 そこで、キー入力があれば受け付け、無いなら飛ばして次に行く処理を作ってみました。キー入力はOSがバッファしているので、これを覗く形です。

Raspberry Pi 4B / Rasbian11_32bit(blueseye) / OS標準gcc
/* ---------------------------------
  リアルタイムにキー入力をチェックする
  --------------------------------- */
/* getcharはキー入力のキャッシュが空だと入力があるまで待つ。
  キャッシュが無いなら無いでそのまま抜けたいが、タイムアウトを設定しても
  抜けない。環境に寄るのかもしれないが、ioctl.hを用いることで
  タイムアウトが実現できた。
*/

/* ライブラリ読み込み */
#include <stdio.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <unistd.h>

/* 定数設定 */
#define SET 1        // ioctl.readのモードをRawにするフラグ
#define RESET 0       // ipctl.readのモードをCanonicalに戻すフラグ

/* プロトタイプ宣言 */
int get_inkey( char *get_char ) ;  // キー入力を取得する関数
  // char *get_char  取得したキーコードを返すポインタ
int set_inkey( int mode_flag ) ;  // キー入力のモードを設定する関数
  // int mode_flag  モードの設定フラグ 1(SET)=Rawモードにする / 0(CLR)=モードを戻す

/* テスト用main */
int main(void) {
  char in_char = 0 ;   // 入力されたキーコードを保存する変数
  int ret_inkey = 0 ;   // get_inkeyからの戻り値を保存する変数
  /* コンソールの設定を初期化 */
  set_inkey( SET ) ;
  /* 無限ループで入力したキーを表示する */
  for(;;) {
    // get_inkeyから1文字取得
    in_char = 0x00 ;          // 事前初期化
    ret_inkey = get_inkey( &in_char ) ; // キー取得
    /* get_inkeyの戻り値を処理 */
    // 戻り値が-1ならエラーなのでループから抜けて終了
    if( ret_inkey == -1 ) {
      break ;
    // エンターキーが押されたならループを抜けて終了
    } else if( in_char == 0x0A ) {
      break ;
    // 入力された文字を出力する・・・表示可能な文字
    } else if( in_char >= 0x20 && in_char <= 0x7F ) {
      printf( " %c<%02X>", in_char, in_char ) ;
    // 入力された文字を出力する・・・表示不可能な文字
    } else if( in_char > 0x00 && in_char <= 0xFF ) {
      printf( " <%02X>", in_char ) ;
    }
    fflush( stdout ) ; // 画面表示のスタックを吐き出す   
  }
  /* 正常終了 */
  printf( "\n" ) ;    // 念のための改行
  set_inkey( RESET ) ;  // コンソールの設定を元に戻す
  return 0 ;
}

/* キー入力を取得する */
int get_inkey( char *get_char) {
  char in_char = 0 ;     // 入力されたキーを保持
  char read_length = 0 ;   // 読み込んだバイト数

  // readを使って標準入力から1文字取得
  read_length = read( 0, &in_char, 1 ) ;
  // read_lengthが-1ならエラー、それ以外なら正常
  if( read_length != -1 ) {  // 正常なので取得値を返す
    *get_char = in_char ;
  } else {          // エラーなので以上通知
    *get_char = 0x00 ;
    set_inkey( RESET ) ;
    return -1 ;
  }
  return 0;
}

/* キー入力のモードを設定する */
int set_inkey( int mode_flag ) {
  static struct termio tty_backup;    // 変更前の設定を保持
  static struct termio tty_change;    // 変更後の設定を保持
  // モードを設定する
  if( mode_flag == SET ) {
    // 現在の設定をスタック
    ioctl(0, TCGETA, &tty_backup);
    tty_change = tty_backup;
    // 設定を変更
    tty_change.c_lflag &= ~( ECHO | ICANON ) ;   // エコーを止め、RAW モードへ変更
    tty_change.c_cc[VMIN]= 0 ;          // 0文字入力された時点で入力を受け取る
    tty_change.c_cc[VTIME] = 0.01 ;        // 何も入力がなくても1msec待つ (1 = 1/10sec)
    ioctl( 0, TCSETAF, &tty_change ) ;       // ここで設定を反映
  // モードを戻す
  } else if( mode_flag == 0 ) {
    // スタックしていた設定に戻す
    ioctl( 0, TCSETAF, &tty_backup ) ;
  }
  return 0;
}


 同じ感じでgetcharを使ってもいいような情報が多かったのですが、RaspberryPiのblueseyeではこの方法でないとキー入力があるまで一時停止してしまいます。
 Pythonでも同様の処理を書いたことがありますが、C言語の方が圧倒的にレスポンスがいいです。
 矢印キーがANSIエスケープシーケンスのコードで取得できたことには驚きましたが、ファンクションキーも含め、getcharでは取得できないこともあるキーも取得出来て満足。
 ただし、シフトキーなどの装飾キーを単体で取得することは出来ません。

#C言語
Icon of admin
 キー入力の処理が出来ましたが、願わくば押し下げと解放も拾いたいところではあります。
 ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。

 socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
 入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
 では、得たASCIIテキストをどう処理するかです。
 入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
 せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな?

#[Art-Net] #C言語
Icon of admin
 キー入力はファンクションキーや矢印キーが複数バイトのデータなので、先のプログラムではこれらを正しく判別出来ません。0x1Bを得てもESCキーなのか矢印キーなのか区別できないからです。
 これらのデータが一度にキャッシュに入って連続した読み出しとなる(タイムアウト無しに連続して読み出せる)ならいいですが、そうでないと面倒です。いずれにしてもこの辺りの挙動をチェックする必要があります。今は1バイトのcharとして処理していますが、8バイトくらいのchar配列、つまり文字列として処理することになりそうです。

#C言語
Icon of admin
 本業は当面の課題を一通りやっつけました。
 追われる感じが無いって幸せ。

 そんぢゃ今夜はC言語の勉強!!、といきたいところですが、ここ数日、朝から晩まで10時間以上図面書きをやりますと帰宅してからヤル気はおきません。今夜は脳味噌を休ませてアタマを切替えます。
 明日と明後日は急ぎの要件が無いので、キー入力の実験、これまでに実験したネタの整理、socketによるArt-Net処理の実験に手を付けましょう。

 キー入力はioctl.hとtermios.hを用いて設定しread()で読み込む方法を用いていますが、これってデバイスドライバを書く基本なんだそうです。
 宛先を設定し、read()で取り込み、write()で送り出すという極めてシンプルな構成ですが、合理主義者の神達がローレベルの制御に対し案件毎に違ったやり方を定義するとは思えませんので納得です。
 肝心なところは先達のサンプルプログラムをコピペしただけなので何が何だかよくわかりませんが、デバイスドライバが書けたら守備範囲が広くなりそうです。

#C言語
Icon of admin
 キー入力の処理を書き直してみました。
 ファンクションキーやカーソルキーなどの複数バイトでキーコードを出すキーも扱えます。shiftやAltなどの装飾キーは拾えませんケド。
 入力の待ち時間はありません。get_inkey()はすぐ戻ってきます。戻り値はキーコードの長さを表しますが、0なら入力が無かったと判別出来ます。
 得られるのは標準入力からのASCIIコードです。read()はキャッシュを読むだけでタイミング次第では取得値に複数のキーコードが混じることがありますが、これをキー単体のコードとして仕分けています。キャッシュの一番前のキーコードだけを取り出す単純な仕分けで、想定外のキーコードは読み飛ばしていますが十分でした。
 キーコードで何かをするにはswitch文やif文でそのコードを仕分ける必要があります。
 正常に動かすなら、100msec(1/10秒)毎以下でget_inkey()を読みに行く必要があります。
 定数設定とプロトタイプ宣言をヘッダーファイルに書けばincludeしてライブラリとして使えます。mainはコメント化して使った方がいいですけど。

Raspberry Pi 4B / Rasbian11_32bit(blueseye) / OS標準gcc
/* ---------------------------------
  リアルタイムにキー入力をチェックする
  --------------------------------- */
/* getcharはキー入力のキャッシュが空だと入力があるまで待つ。
  キャッシュが無いなら無いでそのまま抜けたいが、タイムアウトを設定しても
  抜けない。環境に寄るのかもしれないが、ioctl.hを用いることで
  タイムアウトが実現できた。
  get_inkeyの呼び出しは100msec(1/10秒)毎以下で繰り返し行うこと。短い方がいい。
*/

/* ライブラリ読み込み */
#include <stdio.h>
#include <sys/ioctl.h>
#include <termios.h>
#include <unistd.h>
#include <time.h>

/* 定数設定 */
#define SET 1        // ioctl.readのモードをRawにするフラグ
#define RESET 0       // ipctl.readのモードをCanonicalに戻すフラグ
#define LENGTH_STACK 32   // キー入力のスタック長 状況によるが、長めにしないと取り出しが半端になる
#define ESC 0x1B      // ASCIIコード ESC
#define BRACKET 0x5B    // ASCIIコード [

/* プロトタイプ宣言 */
int get_inkey( char *get_char ) ;    // キー入力を取得する関数
  // 戻り値              // -1=エラー、0>=取得したキーコードの長さ
  // char *get_char          // 取得したキーコードを返すポインタ
int set_inkey( int mode_flag ) ;    // キー入力のモードを設定する関数
  // int mode_flag          // モードの設定フラグ 1(SET)=Rawモードにする / 0(CLR)=モードを戻す

/* テスト用main */
int main(void) {
  int i ;               // for文用カウンタ
  char get_char[ LENGTH_STACK ] ;   // 入力されたキーコードを保存する変数
  int ret_inkey ;          // get_inkeyからの戻り値を保存する変数
  /* コンソールの設定を初期化 */
  set_inkey( SET ) ;
  /* 無限ループで入力したキーを表示する */
  for(;;) {
    usleep( 1e5 ) ;
    ret_inkey = get_inkey( get_char ) ;     // get_inkeyから文字取得
    /* get_inkeyの戻り値を処理 */
    if( ret_inkey == -1 ) break ;        // 戻り値が-1ならエラーなのでループから抜けて終了
    if( get_char[0] == 0x0A ) break ;      // エンターキーが押されたならループを抜けて終了
    /* 入力された文字を出力する */
    if( ret_inkey > 0) {
      for( i = 0; i < ret_inkey; i++ ) {
        if( get_char[i] >= 0x20 && get_char[i] <= 0x7E ) {     // 入力された文字を出力する・・・表示可能な文字
          printf( " %c<%02X>", get_char[i], get_char[i] ) ;
        } else if( get_char[i] >= 0x00 && get_char[i] <= 0xFF ) {  // 入力された文字を出力する・・・表示不可能な文字
          printf( " <%02X>", get_char[i] ) ;
        }
      }
      printf( "\n" ) ;
    }
    fflush( stdout ) ; // 画面表示のスタックを吐き出す   
  }
  /* 正常終了 */
  printf( "\n" ) ;    // 念のための改行
  set_inkey( RESET ) ;  // コンソールの設定を元に戻す
  return 0 ;
}

/* キー入力を取得する */
int get_inkey( char *get_char) {
  // char *get_char                  // キーコードを返すためのchar配列のポインタ
  int i ;                       // for用変数
  char in_char[ LENGTH_STACK ] = { 0x00 };      // 入力されたキーを取得
  int read_length ;                  // read()戻り値 キーコードのバイト数
  int put_length = 0 ;                // 戻り値 キーコードのバイト数

  /* get_charの初期化 */
  for( i = 0; i < LENGTH_STACK; i++ ) {        // すべての値を0x00にする
    get_char[ i ] = 0x00 ;
  }
  /* キー入力を読み取る */
  read_length = read( 0, &in_char, LENGTH_STACK ) ;  // read_lengthに取得バイト数、in_charにキーコードを得る

  /* 取得値の仕分け */
  if( read_length < 0 ) {               // 取得エラーなのでエラーを返して終了
    return -1 ;
  } else if( read_length == 0 ) {           // キーコードを得られなかったのでゼロを返す
    return 0 ;
  } else if( read_length == 1             // 取得が1バイトか先頭バイトがESC(0x1B)以外なら先頭バイトを返す
       || in_char[ 0 ] != ESC ) {
    get_char[ 0 ] = in_char[ 0 ] ;         // 値コピー
    return 1 ;
  } else if( read_length > 2             // 3バイト以上で先頭2バイトが0x1B(ESC)、0x5B([)なら
       && in_char[ 0 ] == ESC          // ファンクションキーまたはカーソルキー
       && in_char[ 1 ] == BRACKET ) {
    get_char[ 0 ] = ESC ;              // 0バイト目
    get_char[ 1 ] = BRACKET ;            // 1バイト目
    put_length = 2;                 // 戻り値設定
    for( i = 2; i < read_length; i++ ) {      // 2バイト目以降をコピー
      if( in_char[ i ] == ESC ) break ;      // 末尾にESCがあれば終了
        get_char[ i ] = in_char[ i ] ;     // 値コピー
        put_length++ ;             // 戻り値インクリメント
    }
    return put_length ;               // 戻り値送って終了
  }
  return 0 ;
}

/* キー入力のモードを設定する */
int set_inkey( int mode_flag ) {
  static struct termio tty_backup ;        // 変更前の設定を保持
  static struct termio tty_change ;        // 変更後の設定を保持
  /* モードを設定する */
  if( mode_flag == SET ) {
    ioctl( 0, TCGETA, &tty_backup ) ;      // 現在の設定を読み出し
    tty_change = tty_backup ;          // 現在設定のスタック
    tty_change.c_lflag &= ~( ECHO | ICANON ) ; // エコーを止め、RAW モードへ変更
    tty_change.c_cc[ VMIN ]= 0 ;        // 0文字入力された時点で入力を受け取る
    tty_change.c_cc[ VTIME ] = 0.01 ;      // 何も入力がない場合、1msec待つ (1 = 1/10sec)
    ioctl( 0, TCSETAF, &tty_change ) ;     // ここで設定を反映
  /* モードを戻す */
  } else if( mode_flag == 0 ) {
    ioctl( 0, TCSETAF, &tty_backup ) ;     // スタックしていた設定に戻す
  }
  return 0;
}

 ※ このブログシステムでは#や[が機能文字扱いなので、上記ではこれらを全角文字で書いています。

#C言語
Icon of admin
 てなわけで、socketの実験に入る下準備が整いました。Pythonで出来たことですからC言語(gcc)で出来ないことではないでしょう。
 Art-Netエンジンを構成するにはFIFOというか循環配列というかリングキャッシュというかQueueも勉強しないとけません。例えば1024個の配列を作ったとして、これがリング状に繋がったイメージで使います。1024で折り返すカウンタを使って配列の基点位置を表すだけですが、カウンタの計算モジュールだけでもライブラリ化しないと面倒かなと。
 これはDelayで必要な機能です。一定の時間間隔でDMXのデータを保存し続ければ配列サイズが許す範囲で過去情報を取り出せます。つまりDelayになります。受信毎の保存でないことが肝ですが、往年のテープエコーと要領は同じです。
 C言語はボチボチ書けるようになってきましたし、先達の情報も読み取れるようになってきました。パッチマシンとしての完成は先としても、この閑散期にArt-Netエンジンだけでも完成させたいです。

 あとは、コマンド入力と処理の方法も考えないといけません。
 ルールマップに基づいた入力制限とか、入力されたコマンドや数値のスタック方法とか、それの表示とかです。入力値はコマンドと数値の文字列で処理関数に渡すつもりですが、それをどの様に解析して実行するかも案外難しい。

#[Art-Net] #C言語

2023年2月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 自作のライブラリをincludeしてコンパイルするには少し面倒があります。
 例えば、
 製作するアプリケーションファイル test_inkey
 メインのソースファイル test_inkey.c
 ライブラリのソースファイル std_inkey.c
 とした場合、
$ gcc -Wall -lm -o test_inkey -I ./ test_inkey.c std_inkey.c
 などとコンソールからコマンドを打たないといけません。
 Cのソースファイルが一つならVSCodeからショートカットで一発なんですけどね。

 この場合、makefileを作っておけばmakeコマンドで一発です。
 次がわかりやすい。
 Makefile の書き方 (C 言語)
 makeコマンドの使い方も丁寧に説明してくれています。

#C言語
Icon of admin
 Art-Netの受信に成功しました。
 先達の情報をいくつか合成しましたが、思った以上に簡単でした。
 ネットワークインターフェースの指定も出来ました。
 一安心ですが、次は送信しないといけません。
 デコード/エンコードをせずに受信値をリレーするだけですが、これが成功しないようでは受信値を加工する努力をしても意味がありません。

#[Art-Net]
Icon of admin
 Art-Netの送信にも成功しました。
 受信値を転送するだけですが、Art-Netデコーダから正常と思われる値が出力されています。
 今日は終わりにしますが、大きな課題がクリア出来て大満足です。
 ただ、8ユニバースを出力しているdot2が一杯いっぱいの様子。発熱も凄いし画面もコマ送りです。

 ちなみにですが、recvfrom()の4番目のパラメータを「MSG_DONTWAIT」にすると受信待ちしません。先達の例では待ちアリの「0」を定義してioctl()に待ち無し(ノンブロッキング)を設定していることが多いのですが、「MSG_DONTWAIT」を使った方がストレスが無い感じ。
 で、気付いたのですが、C言語は速い。速いが故の対策が必要になる始末。受送信テストでは終了のためのキー入力やタイムアウトを入れるのが面倒だったのでfor文による一定回数の繰り返しで試したのですが、受信待ちを無くした後はPythonでの実験の際に使った回数では一瞬で終わってしまいます。プログラムが間違っているのかと思う程でした。てことは、あまりにも無意味な回数recvfrom()を呼んでいることになりますので、受信が無い場合は100~500usecくらい待ちを入れた方がいいみたいです。バッファを読みに行っているだけなので気にしなくていいって話もありますが、ANSIエスケープシーケンスを用いた画面表示も適度な待ちを入れないと画面がフリッカーを起こす程です。数か月かかりましたが、C言語を勉強して良かったと思います。遅いのを対策するのは大変ですが、速いのを抑え込むのは比較的簡単ですからね。
 ここまで速いとマルチプロセスを使わなくてもいいのではないか?って気持ちも芽生えます。使った方が速さ以外に都合が良いこともあるので使いますケド。

 基本的な受送信が確認出来ましたので、関数化しつつArt-Net(正しくはArt-DMX)のデコード/エンコードも書きましょう。

#[Art-Net] #C言語
Icon of admin
 Art-Netのデコード/エンコードも出来ました。受信した1配列のバイナリデータを分類して構造体に取り込むのがデコード、項目別の構造体から送信用のバイナリデータに変換するのがエンコードです。
 実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
 topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを1つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
 今のところ製作は順調です。3月末までに1日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。

#[Art-Net] #C言語
Icon of admin
 Art-Netの入口と出口は出来ましたので機能を組みます。C言語に替えた為に処理能力に余裕が出て複座なプロセス処理を多用しなくても良さそうですが、そもそもの処理をどうするか吟味しないといけません。
 搭載予定の機能は、ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)です。スタックフェーダー機能はミキサー機能に含まれます。
 さて、どうしようかな。

#[Art-Net] #C言語
Icon of admin
 諸々イイ感じに書き進められていますが、処理タイミングという一見簡単そうで実は面倒なことに取り組んでいます。
 先日作ったキー入力処理とArt-Net処理を混ぜているのですが、それぞれに合った時間間隔で実行しないといけません。キー入力は100msec、Art-Netは100usecです。求められる処理間隔が3桁も違うので同じ時間間隔ではどちらかが破綻します。それぞれをそれぞれの時間間隔で実行するにはどうするか。他の処理を止めること無く処理を続けるにはどうするか。
 基本は前回処理の日時と現在日時の差から経過時間を評価する方法です。一定の時間間隔で処理を呼ぶのではなく、呼ばれても経過時間が要求未満なら何もしない方法です。signal()を用いて一定時間間隔で関数を実行させるのが王道でしょうが、singal()ですと終わっているべき他処理のチェックが必要になるのでどっちもどっちです。私の書き方が悪いのかもしれませんが、signal()を多用するとバグの原因になりやすいようです。
 なんにしても前回処理からの経過時間で対策してみます。そのために必要なのは現在日時の取得です。POSIX時間と呼ばれる1970年1月1日0時0分0秒からの経過秒数を取得出来るのでこれを用います。50マイクロ秒くらいの分解能が欲しいので秒単位では不足しますが、精度はともかく1ナノ秒単位で値を得られますから十分です。
 下記はその値を取得するテストプログラムです。
 秒とナノ秒が別々の変数で得られるので、評価を簡単にするためにひとまとめにします。ただし、int型は4バイト長(OSが32bitの場合)のためデータ長が不足しますので、8バイト長(OSが32bitの場合)の unsigned long long int型を用います。2038年問題はとりあえず気にしない。。。

Raspberry Pi 4B / Rasbian11_32bit(blueseye) / コンパイラ:OS標準gcc
#include <stdio.h>
#include <time.h>

int main( int argc, char *argv[] ) {
  struct timespec now ;
  unsigned long long int now_nsec ;
  // 現在POSIX時を取得
  clock_gettime( CLOCK_REALTIME, &now ) ;            // 現在POSIX時間値を取得
  now_nsec = ( unsigned long long int )now.tv_sec * 1e9     // unsigned long long int型(8バイト長int)変数に
        + now.tv_nsec ;                   // 取得値をひとまとめにする(nsec)
  // 確認表示
  printf( "%11ld.%09ld sec.\n", now.tv_sec, now.tv_nsec ) ;   // 取得値を表示
  printf( "%21lld nsec.\n", now_nsec ) ;             // ひとまとめにした数値を表示
  // 終了
  return 0 ;
}

※ このブログシステムでは#や[が機能文字扱いなので、上記ではこれらを全角文字で書いています。空白も全角です。
◆ 参考
 時間情報の取得方法と扱い方


 取得に必要なのは「// 現在POSIX時を取得」以下の2行(表記は3行)です。
 実際の処理では、取得した秒とナノ秒を合わせた数値がnow_nsec入りますので現在日時値とし、同じ方法で前回の処理で取得した値との差で経過時間を評価します。単位がnsecなら1秒は1000000000(1e9)ですから、100msecは100000000(1e8)、100usecは100000(1e5)です。良い意味で処理が速いC言語では多用すべき手法です。
 関数化・ライブラリ化するとソースは美しいですが、2行で出来ることなので都度の直書きでもいいかなと。将来、2038年問題に対策しやすくしておくならライブラリ化しといた方がいいけど。
 PICのアセンブラでも近いことをしていますが、それがPICで様々なことを実現出来ている要因だったりします。処理タイミングの管理はとても重要です。

#C言語
Icon of admin
 各所の処理タイミングで難儀しましたが、第1フェーズと呼んでもいい段階は終わりました。
 まとまったのは次の通り。
1)Art-Netを受信してデコード。
2)エンコードして送信。
3)受信値を表示。
4)カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
 この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
 スッキリした画面に値がキレイに表示されると気持ち良いです。

 ちなみに、画面表示を除く主処理1フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
 今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。

 次はデータ処理の本丸です。
 Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。

追記
 処理タイミングを調整したところ1フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
 不思議なのは、受信している8ユニバース中、0ユニバースに比べ7ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは1フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。

#[Art-Net]
Icon of admin
 オレメモ

 ANSIエスケープシーケンスにおいてカーソルの表示/非表示を定義。
RaspberryPi 4B / Rasbian11_32bit / コンパイラ:OS標準gcc
\e[?25h カーソルの表示
\e[?25l カーソルの非表示


 相変わらずの不思議な呪文。

#C言語
Icon of admin
 本業もやらねばなりませんがArtNet-Engineも進めたい。
 ArtNet-Engineの課題はデータ処理の構成です。

 まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
 送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
 フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
 内部的には8ユニバースのパッチを考えていますが卓も8台想定します。64ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
 当面は送信元の仕分けと64ユニバースを8ユニバースにマージする処理を書きます。

 処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
 Pythonとは違い、for文が速いC言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。C言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。

#[Art-Net] #C言語
Icon of admin
 本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。

 ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、8ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、8ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。

 現時点での1フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん?。
 作りたい物にはなりそうですが、8ユニバース8卓(64ユニバース入力)は厳しい気がします。これに対応するには1フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は8台ですが、同時に使える(HTPミックスの対象となる)のを3-4台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは40ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
 どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。

 ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。

追記
 調整したところ、1ユニバース受信する1フェーズが平均30usec、例外値が200usec程度になりました。
 同時に8卓使っても1本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
 送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。

#[Art-Net] #C言語
Icon of admin
 ArtNet-Engineの入口出口キー操作は触るたびに問題点が見えてきます。なかなか次に進めません。
 次の課題は受信スタックです。これは得たデータをレーンと呼ぶ内部的な経路と送信元毎に仕分けしたモノです。8レーン8送信元、64ユニバースの一時保存です。一見データ量が多いようですが32kBです。映像画像に比べたらわずかな量です。
 受信毎に本処理まですればいい気もしますが、送信元から送られるデータは時間的に一定ではありませんので、受信の都度本処理までするとややこしくて重くなるのです。
 ならば、一定の規則で受信データを整頓し、送信元×レーン毎の入れ子に最新値という形で一時保存してから本処理を行えばシンプルな処理になります。
 こんなややこしいことをしてもDMX規格の最大速の1フレーム程度にレイテンシーを抑えようとしています。
 もちろんタイムアウトも必要です。DMXはデータが1秒間更新されなければ送信が無くなったと判断する規格ですから受信日時を見て判断します。これは優先度が低い処理ですから優先度が高い処理が実行されない空き時間を用います。極端な話、タイムアウトは1秒が基本でも5秒かかったところで実用上の問題は無いと考えます。そんなにかかることは無いと思いますが、2秒くらいで処理されれば実用だと思います。それ以前にDMXのタイムアウトが1秒ってことを知る人が少ないのですから気にしない。

#[Art-Net]
Icon of admin
 RaspberryPi4Bが正価で入手出来たと先日書きました。国内はまだの様ですが、中国からRaspberryPiCM4も正価で入手出来ました。
 CM4は組込み用途に特化し過ぎているために単体では何も出来ませんが、用途に合わせてインターフェースボードを作ればコンパクトでスッキリしたハードウェアを構成出来ます。
 いずれオリジナルのインターフェースを作ってみたいと思っていますが、とりあえずはEtherNetが2口付いた既製品と共にCM4をオーダー。
 ArtNet-PatchはCM4を用いて作りたいのです。プログラミングには4Bを使っていますが、製品にするにはちょっと違うので。

#RaspberryPi #[Art-Net]
Icon of admin
 コレ、欲しいかも。

 公道は走れませんけどね。

#雑談
Icon of admin
 そういや中華電機のムービングが故障しました。
 調光以外、起動後の初期化は正常にするけど卓の信号を受け付けない。画面やキー操作は正常。
 製品によりますが、ムービングライトは調光、PAN/TILT、その他の機能が別々の脳味噌で制御されていることが多いようです。タコみたいですね。
 内部を見ますと、DMXを受信している基板から調光ドライバにPWM信号が出ていて、PAN/TILTとその他の機能の脳味噌に向けて1本のRS485の信号が出ています。
 起動後の初期化が正常に出来て一部の機能だけ卓から操作が出来ないとなればRS485信号がPAN/TILTとその他の機能の脳味噌に届いていないとしか思えません。
 回転軸を通っているケーブルが断線するのはよくあることですが末端まで正常に導通しています。受信側の脳味噌基板は3枚ですが、初期化動作が正常なのに3枚とも壊れているとは考えにくい。
 DMXを受信して中向けのRS485を出している基板が怪しいとなるのですが、この基板上のRS485ドライバICをテスターで当たるとおかしい。3.3v仕様のSN75176互換品みたいですが、SN75176の故障でありがちな症状を示しています。SN75176は静電気にとても弱いので珍しいことではありませんケドね。
 このICを交換してみようと思いますが、レア品ではないものの日本国内では1000個単位でしか手に入らない製品なので中華電機に発注。2/15着ですからしばらく待ちです。

#照明器具 #電子工作
Icon of admin
 車で20分くらいのところに水族館があります。
 知り合いの職員さんに呼ばれて打ち合わせに行ったのですが、大きな水槽に「イワシ」が群舞。
 職人が磨き込んだ銀箔のごとき魚体に思わず、「美味そう!!」と口から零れる。
 「・・・やっちまった!」と焦るも、水族館さんにとっては嬉しい誉め言葉だそうな。
 飼育担当の方と仲良くなりました。

#雑談
Icon of admin
 追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。

 ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
 ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
 罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
 不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ?という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。

 ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
 試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。

#C言語 #RaspberryPi
Icon of admin
 ANSIエスケープシーケンスによるテキスト画面表示はやりたいことのやり方が見えてきました。先にも書いた通り、ウィンドウマネージャに近い考え方で関数ライブラリにまとめる方針です。
 ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
 平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
 ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。

#[Art-Net] #C言語
Icon of admin
 Art-Net製品はほぼ趣味で開発しているのでいいですが、DoctorMXで有名なクワテックさんのラインナップは素晴らしいです。
 是非ゴングインターナショナルさんのサイトからご覧になって頂きたいですが、間違いなく世界レベルの製品ばかりです。業界内には国産のDMX関連製品を正しく評価していない気配があるように思いますが、DMX関連品の導入をお考えなら海外製品の前にクワテック製品を検討することをお勧めします。リクエストすると機能を追加してくれたりしますしね。
 最近多くなったライトアップに於いても、ショーコントローラーValenciaの導入を検討しています。半仮設用途に向いたDMXも扱えるマルチメディアシーケンサーは他に無いと言ってもよく、なんと言っても特定の日、特定の曜日でショーの実施を設定できるのは強味です。ダスライトの上位機種にも同様のカレンダー機能はありますが、そもそも明かり作りのツールとして個人的には嫌いです。
 余談ですが間違っても案件ステマではありません。ゴングさんから購入することは少なくありませんが、クワテックさん程の開発力があったらなぁ~と羨望の気持ちでカタログを眺めているだけですwww

#照明器具
Icon of admin
 故障した中華電機のムービングライトは回復しました。
 予想通りRS485のトランシーバーICがダメだったようです。
 ただ、治ったのはいいですが、そもそもナゼ壊れたのか。
 SN75176系が静電気に弱いのは事実ですが、基板間の通信ですから外部配線にさらされることはありませんし、同様のICを使っている受け側は壊れていいませんので、静電気が原因だとしてもどこから回り込んでナゼこれだけなのか。同じ基板に搭載されている他のICは壊れていませんので、起動時の瞬間的な電圧異常が原因だったとしてもナゼこのICだけなのか。他のICはサージ保護が施されているのかもしれませんけれど。
 原因不明なので再発の可能性は十分にあります。他の機体が同様の故障を起こすかもしれません。
 RS485トランシーバーICは10個単位の販売でしたので予備はあります。しばらく様子見です。

追記
 RS485トランシーバーICはSN75176互換の3.3vSOP-8パッケージの品なら使えそうです。今回は全く同じモノを中華電機から仕入れましたが、秋月さんでも互換品が手に入ります。
 静電気にも過電圧にも強いLT1785の姉妹品に3.3vのSOP-8パッケージの物があればいいのですけどね。
 実験で電子ライターの火花を与えたことがありますが、SN75176は即死、LT1785は損傷しませんでした。

追伸2
 LT1785と同等の耐久性を持つ定格電圧3.0~5.5v品がありました。S8パッケージのLTC2862-2(max250kbps)です。
 過電圧耐性±60v、EMI(静電気耐性)1.5kvです。壊そうとしても簡単には壊せないかも。姉妹品のLTC2862-1は高スペックで20Mbpsまで対応しますがオーバースペックです。
 パッケージはS8とありますがSOP-8と同等の様です。
 ネット検索では国内小売りにもAliExpressにも見当たりません。入手性に難ありです。

#照明器具 #電子工作
Icon of admin
 別な中華電機のムービングを修理しました。
 先日のはプロファイル系で明るさも芸もある中規模の機体ですが、今日のはPAR球1個と同程度の価格でお茶濁しとして使っている小型ビームライトです。
 MacAura1台の費用で30台以上買えますので使い方によっては費用対効果が高いのです。私は12台とか16台をエフェクトエンジン頼りでグループ使いしますが、思った以上にボリューム感のある照明が作れます。Auraは素晴らしい機体ですが1台で何が出来る?って話です。
 もちろん、Auraに比べたら極悪に精度が悪く光が貧相で、細いビームをブン回すしか能がありませんが、往年の応用工学スピナーが向きと色を制御出来ると思えば悪くありません。

 主な故障は4色のLEDのウチ1色が点かないというものです。
 基板を当たりますと点かない物はドライバICのハンダ付けが甘いようで、ハンダをし直すと回復するケースが大半です。中華電機がどうのではなく、価格相応といったところでしょうか。
 ハンダをし直しても治らない物はセンシング抵抗を着け直すと治ります。LEDに流れる電流を検出する回路の抵抗ですが過熱で抵抗値が狂うようです。この抵抗は1wクラスの様ですが3wに交換すると症状が出なくなるようです。中華電機の器具は設計に余裕がないのかこういった故障はよくあります。
 他には電源モジュールのスイッチングトランジスタが飛ぶケースです。これも設計がギリギリのようで、元のトランジスタよりも大きな定格を持つトランジスタに交換すると落ち着きます。電源の入力部の保護回路がダメな物もありましたが、バリスタを交換して落ち着きました。作った側は200v環境で開発しているためか、中華電機の製品を100vで使うとこんなこともあるのでしょう。
 日本国内の感覚では無償即対応の不良ですが、相手が中華ですし価格も価格ですから自力でナンボです。対策すれば使えるのですから、大陸的な感覚で扱いましょう。中華電機の照明器具は半完成のキットなんですよ。内部を探ってエラーを見つけて直すのも趣味的には楽しいしwww

 ですが、ハンダが甘い基板が多数見つかったので全数チェックしなければなりません。これがアベレージかもしれませんので。。。
 未チェック品が30台近くあるので、全ての基板をチェックして動作もチェックするにはそれなりの手間と時間がかかります。

#照明器具 #電子工作
Icon of admin
 中華電機の小型ムービングライトで現場に出ていないのをチェックしましたが1台が変。
 主要部品のハンダを当て直して抵抗を替えると点くっちゃ点くのですが、しばらく休ませて再起動すると点かなかったりします。叩くと点いたりするので始末が悪い。必ずしも点かないワケではないので原因が絞れません。
 基板を外して裏側のパターンやハンダを見ても不審な点は見当たらないのですが、この際関係してそうな配線のハンダをすべて当て直してみました。
 すると、平滑コイルを着けるハンダからブクブク泡が出てきます。見た目は着いているのですが、天ぷらハンダ(ハンダの中に気泡が入っている状態)の一例です。気泡が入っているため、テスターで導通しても電流が多いと機能しなかったりします。コイルの導線のエナメル被覆がキチンと剥かれていない感じもしますけどね。
 放熱板が電源端子になっているスイッチングICは基板のパターンと放熱板の間からフラックスの泡が出てきます。これはハンダのフラックで着いているだけでハンダで着いていない可能性が高い症状です。一見動いても、過熱してくるとフラックスの気泡が膨らみ隙間を広げて接点が甘くなることもあるようです。昭和の白黒テレビが「叩けば映る」とされた原因でもあるようです。
 ハンダはどう見ても鉛入りで質は酷く、施工はヘタクソです。安いってこういうことだよねぇ~とか思いながら手直ししましたがお粗末です。
 これらの対策が功を奏したのか偶然なのかわかりませんが、不審な挙動は無くなり安定して点く様になりました。
 一晩冷まして明日再チェックです。

#照明器具 #電子工作
Icon of admin
 照明器具のメンテナンスでは製作中のArtNet-Engineを通してDMX信号を送っています。
 入力をデコードして一時スタックし、それをエンコードして送るだけの状態ですが、目に付く遅れもなく不審な挙動もなく何の芸もなく普通に動きます。
 今のところ遅れても1フレームなので、このレスポンスでまとまれば御の字かなと。当たり前が当たり前に出来ればそれでいいのです。

 ボチボチ現場対応も増えつつあり、部下の仮打ちが終わって作業スペースを確保出来たので本業の道具もメンテナンスしなければなりません。ArtNet-Engineなど趣味の開発はペースダウンです。

#[Art-Net] #電子工作
Icon of admin
 ここ最近、中華電機からのお届け物が速い。
 これまでは「お届け予定日」から数日以内に届けば良い方で、下手すりゃ数週間遅れることも珍しくありませんでした。
 何がどう変わったのかわかりませんが、最近は予定日よりも早い。
 数日前に届いた物は予定より半月も早い。好印象を持たせるためのふかした予定日だったとしても、DHLなどを使わずに1週間で届いたのですから間違いなく速い。

 てなわけで、RaspberryPiCM4が入荷しました。小さいとは聞いていましたが、思った以上に小さい。
 半導体不足で入手難でしたから現物を見るは初めてです。箱を見た瞬間、あまりの小ささにRaspberryPiのロゴが入ったノベルティが送られてきたのか?、やられたのか?と思ったくらいです。
 灯を入れてチェックする時間はしばらく取れそうにありませんが、想像が広がる楽しい一品です。

#RaspberryPi #中華電機
Icon of admin
 RaspberryPiCM4は単体では動きません。なんらかのインターフェースボードが必要です。
 ArtNet-Routerに使うのであればEtherポートが2個、HDMI、USB3.0が付いている物が良いなぁ~くらいの気持ちで買ったボードには「SIMカードスロット」が付いています。
20230217134603-admin.jpg
 お目当てではなかったのですが、どうせならLTEモデムも実験してみようかと。出先でIoT的に使うならネット回線も繋いでおきたいと思っていました。ネットに繋がりさえすればVPNでどうにもでもなります。
 ちなみに、3割程安いすごく似たボードがありますが、こちらにはSIMカードスロットがありません。M.2スロットも安い方がEキーで今回のはBキーです。どちらが良いというより目的が違います。
 モデムカードは「L850-GL」をオーダー。日本国内のプラチナバンドにも対応する数少ないM.2モデムです。価格は約3,500円(2023年2月現在)ですが、プラチナバンドに対応した外付けのwifiルーターよりも安価です。ドライバはOS標準に無いそうですが、チップメーカー純正のドライバがGitHubにあります。
 設定は先達の情報を継ぎ接ぎしてどうにかしましょう。

#RaspberryPi
Icon of admin
 思った以上に本業が忙しくなってしまいましたが、アルゴリズムの検討はしています。
 今はキー入力からコマンドを起こす処理です。これも思った以上に難しい。
 入力されたコマンドを実行する際に処理が出来なければエラーを吐く方法もアリですが、入力する途中で制限をかけた方がコマンド実行に負担をかけないのでいいかなと。
 また、コマンドの入力中でも一部の機能は実行したい。例えばランプチェックなどです。入力中に状況を確認して最終決定が出来れば操作性が良くなるからです。コマンド入力が確定せずともそれをチェックし、構文確認や一部の機能を実行出来る様にしたいのです。
 とまぁ、言うのは簡単ですが、これをどう処理したものか。ケースバイケースでベタ処理を書くのは無駄が多いので、出来る限りリソースを汎用化することでメンテナンス性も良くしておきたい。プログラム書きの基本だと思っていますが、同じ処理は一つしか書かないってことです。

#C言語
Icon of admin
 写真を喋っているように加工するAIだそうです。

 突っ込みどころはあれど凄いですね。
 シンギュラリティ(人工知能(AI)が人類の知能を超える転換点(技術的特異点)、または、それにより人間の生活に大きな変化が起こるという概念のこと。)が近々やってくると言われていますが、現在の加速度的な進歩から想像するに、私が人であるウチにやってくるのは間違いないかと。
 こんな調子で照明プラン・オペをやってくれるAIも出現しませんかね。技術的に可能でも商業的にありえないかな?
 ちなみに、サムネの女性に瓜二つな知人がいますwww

#雑談
Icon of admin
 JAXAのH-3が打ち上らなかったことが「失敗」か「中止」かで騒いでいる方々がいます。
 期待通りに衛星を軌道投入出来なかったことは事実ですが、発射事業としては「失敗」であり、機体運用としては「中止」なだけではないかと。立場が違えば観点と言葉が違うってだけなんじゃないすかね。「成功」か「失敗」かと聞かれたら「失敗」だし、「完了」か「中止」かと聞かれたら「中止」なだけとも言えます。ただ、私がJAXA推しで規模は小さくても物作りをしているからですが、無能を印象付けるために「失敗」の言葉を使うような記事には嫌悪を感じてしまうのです。
 今回の件は、高価な衛星と機体を失うことなく「安全に中止出来た」という意味で「成功」だと私は考えます。発射0.4秒前に不具合を検知して停止出来たことがどれだけ凄い事か。飛ばなかったことは明らかなマイナスポイントで誉められたもんぢゃありませんが、資産としての機材を保全する点から見れば衛星の持ち主や保険会社に有益な輸送システムであることを証明したとも言えます。
 H-3は、高い信頼性と豊富な成功実績を持つH-2を単に大きくしたシステムではなく、主エンジンLE-9を代表とする新機軸を多く取り入れたシステムです。しかも、費用を抑えて輸送能力を大幅に向上させるという無茶振り事業です。これが初回で大成功を収められなかったからってダメの烙印を押すのはどうかと思います。成せなかったことに寛容になれとは言いませんが、人のために責任ある仕事をしたことのない人によくある反応なので読んでて溜息。どうしてもJAXAやH-3に烙印を捺したいなら、将来H-3によって実現出来たサービスを使っちゃいけません。ま、そういう仁義を持てない人ほど「失敗」という言葉を使ってマウントを取りたがるのでしょうけど。
 今時のネット言葉ごとく「おわりだよ」的な発言をするのは簡単です。少なくない税金を使った事業は計画通りに成果を出すことが当然であり、その成否を世間に知らせることも大切なことですが、その事業の達成が長期的に有益で望ましいことなら今後どうするべきかを論ずることも同様に大切なことです。将来のための思考も提案も行動もせず目先の結果をあげつらう愚民には沈黙を求めたいものです。せめて居酒屋トークに留めておけと。
 何にしても、1ヶ月後の再実施が成功することを祈るばかりです。

#雑談
Icon of admin
 Art-Net関連は脳裏に湧いたアイデアを一通り吐き出したら次の壁が見えてしまいました。
 Pythonでは思うように作れなかったことがC言語によって解決出来たことは成果ですが、最後の壁を攻略したと思ったのに次の壁が霧の先に見えています。登る方法や降りる方法、はたまたトンネルを掘る方法を地道に探さんといけません。登るべきか掘るべきかルートを変えるべきかも壁の先が見えないのでわからんのですけど、壁が間近に見えるところまで行って一服すかね。
 壁と書きましたが、その筋の専門家にとっては小さな水溜りかな?

 四の五のと言葉を積んでも出来んことは出来んので、一服ついでに棚上げになってるネタに手を付けています。
 「後は組むだけ」で放置してあるネタが幾つかあるのでそれをヤリ切ってしまいましょう。
 児童公園の築山を攻略してガッツポーズする50代も格好悪すぎてワルくないwww

#雑談
Icon of admin
 先日、「同じ処理は一つしか書かない」ってことを書きましたが、これを突き詰めるとオブジェクト指向なんだなと。
 私にとってPythonで学習した最大の成果ですが、C言語でコレを成すのはC++です。
 残念ながら「オブジェクト指向ってなんぞや!?」を説明できる知識も文才も私にはありません。Pythonでは感覚的に便利に使っていましたが、煮詰まった今、神達の凄さを垣間見られた気分になっています。悪夢から逃げたくて光明を得た夢を見ているだけかもしれませんがwww

 「神達」ってのは私の勝手な呼び方です。UNIXを始め現代の社会基盤に無くてはならないシステムの礎を構築した特別な先人のことです。残念ながら社会性に乏しく商売で成功した方は少ないのですが、彼らの成果には驚きが満ちています。論理性ではなくその閃きに「神」を感じるのです。ぶっちゃけ、「天才とナンとかは紙一重」で「こいつらの頭の中おかしくね??」ってことなんですけど。
 こういった「ちょっとおかしな人たちの成果」を社会に普及させたって意味でビル・ゲイツさんの存在は大きいと思います。一部からはMS-DOSの一件で「有史以来、最大の詐欺師」と呼ばれているようですが、「ちょっとおかしな人たち」には絶対不可能な「ちょっとおかしな人たちの成果」を巨大なマーケットにしたのは彼です。エンジニアとしては凡才な彼は商人としては非凡だったんすかね。
 かのスティーブ・ジョブスさんも同類の詐欺師ですが、私は勝手に「電気で夢を見るピカソ」と彼を呼んでいます。この人もエンジニアとしては凡才だと思いますが、誰にも見えてない世界を夢に見られる天才デザイナーだったと思うのです。私たちが使っているガジェットの幾つかは彼によって世に根付きました。突き詰めれば彼がゼロから発想した物は思い当たりませんが、「これをこうしたら面白いのだ!!」を押し通した身勝手さには距離を置いて尊敬を感じます。彼がAppleⅡを皮切りにLisa、Macintosh、NeXT、iPod、iPhoneを世の中に欲しがらせたことは紛れもない事実です。商売が巧いというより、彼が欲しいモノを作ったら未来を手に出来た消費者が勝手に盛り上がってしまったという凄く不思議な展開を感じます。「ちょっとおかしな人たちから見てもすごくおかしな人」だったそうですけど、その時代の非常識を押し通さないと次の時代の常識は作れないのかなぁ~なんて思ったり。
 思い出しましたが、TRON(トロン)が発展して普及してたらなぁ~って思います。1998年にはイングラムが警らをする日本だったかもしれません。提唱者である坂村教授が開発初期に執筆された本を読み直しましたが「この方は預言者か?」と思うことばかり。預言者の最高峰は神の中の神であるアラン・ケイ老師であり、TRONもそのアイデアに触発されたプロジェクトの一つでしかないのですが、今や当たり前となっている事の具体的な方法論と開発フローが40年前の本に書かれています。しかも、現実の歴史と酷似する内容。すげー。当時の中坊は頑張って読んで理解不能ながらも感銘を受けた。Art-Netでナニかしようとしている今の自分にはTRONの血が少しだけ入っていると思い込んでいますwww

 毎度のワケわからんことを書きましたが、非凡な先人のことを妄想したら凡人にも閃きが落ちてこないかなぁ~。

#雑談
Icon of admin
 中華電機ムービングの筐体が割れています。アッパーボックスの樹脂パネルです。これを修理します。
 樹脂の補修は材質を把握するのが第一歩です。材質によって治し方が違うからです。
 材質の判断は匂いで見当を付けて溶剤もしくは接着剤で溶解具合いを見るのが基本です。今回のはABSでした。

 ABSどうしの接着ならコレが基本でしょう。セメダインの「ABS用」です。
 接着には様々な方法がありますが、これは「溶着」です。材を溶かして結合させます。
 面積のあるABSどうしの接着ならコレを両側に塗って貼り合わせればほとんど場合十分です。
20230227200529-admin.jpg
 今回のブツは肉薄なので肉盛りして補強した方がいいみたいです。破断面がキチンと嚙み合いませんので歪みというか応力がかなり残っているようです。今回の破損も衝撃が引き金だとしても応力のために割れやすくなっていたとも思われます。加熱して応力を取ることも出来るそうですが、職人技なので私には無理です。
 こういう時にはプラリペアです。樹脂材全般に使えますが、ABSとは相性が良いので裏側に盛って補強にします。
20230227201504-admin.jpg
 ただ、単にプラリペアを盛るより接合面に谷を掘って盛るのがお勧めです。
 こんな時、ミニルーターが便利です。私はPROXXONのミニルーターを使っています。
20230227204722-admin.jpg

 ABS用で形を戻し、裏側の目立たないところにプラリペアを盛って補強します。

#器具の修理
Icon of admin
 中華電機の小さなムービングライトが全数戻ってきたので修理をしています。これまでの修理で確認すべき点が出ているので全台予防修理です。
 作業は主にハンダ付けの確認です。正常に動く機体でもハンダコテを当てると故障機体と同じ症状が見られますのでやっておいた方がいいでしょう。1年生部下でもここまでヘタには出来ないよねってくらい酷い施工なので念には念をです。
 一度にやりきれない台数ですからヒマを見てボチボチと。

#器具の修理

2023年3月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 商売柄CDを大量に焼くことがあります。
 今となっては選挙委員会からの依頼がメインですが、外注するには少ないけど手焼きするにはそこそこという枚数です。
 これをやるにはデュプリケーターを使うのが王道ですが、ドライブを限界まで搭載したパソコンを使う手もあります。所属会社ではデュプリケーターがとても高価だった時代の名残りでそういうパソコンを使っています。
 ところがです、このパソコンがどうも不調。動くには動くけれどエラーで頻繁に止まる。あまりに頻発するので改めてチェックしたところメモリーが不良。正しくはマザーボードのDIMMスロットの一つがダメのようです。
 メモリの搭載量は減るものの、不良と思われるスロットを使わないセッティングにして回復。
 改めてメモリーチェックをしていますがエラーは出ていません。動作も快調です。

 必ずしもではありますが、不調のパソコンはメモリーチェックをした方がいいですね。
 不調ならメモリを交換するか機体の入れ替えとなりますが、原因を特定するには良い方法です。
 WindowsならOSの機能にありますし、重チェックをしたいならMemtest86というフリーウェアがお勧めです。

#パソコン
 
Icon of admin
 国策企業と言ってもいい半導体メーカーのRapidus株式会社(ラピダス)が半導体の高度技術者を月給27万円で募集しているとかいないとか。そこそこ企業の正社員ならお荷物人材すらもらっていそうな金額ですが、未来の最先端半導体を作れるキーマンに提示して恥ずかしくない金額なの?
 アメリカの資本も入っていますから週給の間違えか?とも思いましたが、それでも年に1,431万円です。年俸27万USドルならアリかもしれませんが、求める成果を考えたら安すぎます。世界の覇権を手にしようともくろむ国策企業が恥じることなくこんな提示をするのは日本国民として恥ずかしい。

 偉いだけの役員様が不要とは言わないけど、その企業の価値を高める高度技術者を募集するなら役員様と同等の報酬を提示するのが最低限ぢゃね?。プロスポーツに例えるなら超一流のスター選手を求めるようなお話ですから、革新的な成果を出せる技術者には会長や社長以上の年俸を支払ってもアリだと思うのです。技術者を優遇しろってことではなく、平凡な技術者には平凡な報酬、神クラスの技術者には神クラスの報酬ぢゃないかと。
 つか、何の取柄も無い人すら手に出来る27万円で神クラスの人材が集まると本気で思っているなら腐れ神すら寄り付かないのでは?

 神クラスの経営者も管理職も居ないから27万円なんでしょうけど、このまま「月給27万円」を押し通すなら「成果を出したらボーナス100億円!!」くらい付け加えて欲しいものです。
 一度にそんなボーナス出したら所得税で大半を持って行かれそうだけどwww

#雑談
Icon of admin
 ムービングライトの予防修理と平行して棚上げネタを進めています。今はクリアカムのパワーサプライです。

 クリアカムはDC12v~30vのスイッチング電源とターミネーターがあれば動きます。
 電源は中華電機のDC24v/9Aを用いています。ベルトパックの電源電流は1台あたり150mA勘定です(カタログスペックはもっと少ないのですが経験則から余力を持たせてます)から20台くらいは動くかな?。
 ターミネーターは抵抗220Ω(2w)x1、抵抗4.7kΩ(1/2w)x1、電解コンデンサ10uF/35vx1です。このあたりは過去記事No.371に書いています。
 専用基板にターミネーターを実装し、XLR3Pを4口搭載し、4口同系統と2口2系統に切り替えられるようにしています。

 組んでて困ったのは、DC24vのスイッチング電源の入出力ターミナルが小さいことです。M3ネジですが、壁(フェンス)の間隔5.2mmしかありません。0.75スケアに対応した圧着端子の幅は最小でも5.6mm。ほんのわずかの違いですが入りません。削ればいいけど面倒です。0.3~0.5スケアに対応した圧着端子なら幅5.2mmなのでギリギリ入りますが、近所の電材屋さんやホームセンターさんでは在庫していなかったのでポチりました。額面9A出力でこんな小さなターミナルはどうかと思います。性能は悪くないだけに不思議です。
 ちなみに、中華電機のスイッチング電源に表示される最大電流値は絶対最大定格(これ以上使ったら壊れる値)と思うのがいいみたいです。国内感覚の定格(安定して使い続けられる最大値)は半分くらいのようです(今回の場合は4.5A)。

 本体ページにクリアカムについてまとめるのがいいのかな?
 XLRのピンアサイン、簡易パワーサプライの作り方、音声信号の割り込ませ方、音声信号への変換の仕方、製作の注意点などです。

#電子工作
Icon of admin
 JAXAのH-3が失敗したようです。2段目のエンジンが着火しなかったため遠隔操作で自爆させたそうです。今回ばかりは衛星を含めた機材を失っていますので中止・中断とは言えません。
 かとって、あげつらってJAXAはダメだぁ~三菱はダメだぁ~とするのも短絡過ぎます。1段目は正常に機能し分離まで成功したのですから、H-3最大の売りである新機軸満載のLE-9は正常に機能したと言えます。これはこれで正しく評価するべきです。事業としては言い訳の余地がない失敗ですが、LE-9の何がこれまでと違うのか、何が凄いのか、この辺りを抜きに今回を語るのは避けていただきたいものです。
 超難題のLE-9を機能させたのに2段目のエンジンが着火しなかったことは「脇が甘い」と言われても致し方ありませんが。

#雑談
Icon of admin
 クリアカムのピンアサインは「音響・映像・電気設備が好き」さんの「Clear-Com(クリアカム)のヘッドセット・ピンアサイン」がわかりやすい。XLRは品番によってピン配置が違う点も解説されているのでとても良い情報です。

#電子工作
Icon of admin
 インターカムのパワーサプライは3台完成。出来る限り見た目も良くしたのでそれっぽく見えます(自画自賛)。
 本業も忙しいのですが、この調子で棚上げ課題を済ませたいところです。

 次は「裸族のパイ」です。
 HDDケースの「裸族のカプセルホテル」の中にRaspberryPiを入れてサーバー機にするものです。
 筐体の改造などは終わっていて、RaspberryPiのACT信号によるUSB電源の制御を残すだけなのでそれほど難しくないハズです。
 「裸族のパイ」は自宅サーバーの省電力化のためにも必要なので速やかに進めたいところです。

追記
 せっかくなのでパワーサプライの記念撮影
20230309080952-admin.jpg 202303090809522-admin.jpg 202303090809521-admin.jpg
 ケーブルに隠れていますが、3枚目の写真の右側にターミネーターを実装した分岐基板があります。
 以前から使っているパワーサプライはXLRコネクタの内側端子にターミネータの部品を直接ハンダ付けしていますが、見た目も悪いし機械強度も不安なので、この基板に換装しようと思います。

#電子工作
Icon of admin
 RaspberryPi4BのACT-LEDをGPIOに出力してみました。
 /boot/config.txtに設定を追加します。
 以下はGPIO24(18番ピン)に出力する設定です。他のピンでも動くと思います。

$ sudo vi /boot/config.txt
# 末尾[all]の後に次を加えます。
dtparam=act_led_gpio=24


 再起動すると基板上の緑のLEDの挙動がGPIO24に出ます。

 やりたいことはUSB電源の制御で、カーネルが読み込まれたらONにし、カーネルが落ちたらOFFにしたいのです。再起動においてUSBデバイスをリセットするためにUSB電源を一度落とすことが目的です。
 更に設定を追加してACT-LEDを常時点灯にすると求める動作を得られるようです。

$ sudo vi /boot/config.txt
dtparam=act_led_gpio=24,act_led_trigger=default-on,act_led=on


 起動後にカーネルが読み込まれるとGPIOがHになり、シャットダウンもしくは再起動でカーネルが落ちるとLになります。それぞれのタイミングも良さそうです。
 今日はLEDで出力を見ただけですが、実際にリレーを動かすならプルダウンした上にトランジスタ等でバッファする必要があるでしょう。

 RaspberryPiのUSB電源はスクリプトで制御可能ですし、リレーを動かすだけならGPIOを操作すればいいのですが、各種モジュールが読み込まれる前に電源を投入し、各種モジュールが落ちてから電源を切りたいので意味が違います。
 カーネルが落ちたらUSB電源も落ちればいいのですが、RaspberryPiのUSB電源はPWR-LEDの標準動作と同じ挙動っぽいので、今回はACT-LEDを用いることにします。

#RaspberryPi
Icon of admin
 クリアカムのパワーサプライは付属品とする電源ケーブルが入荷したので長時間起動チェックをしました。
 実際の使用機器で長時間通電しておくのは重要なチェックの一つです。10時間くらい通電しましたが大丈夫っぽいです。

#電子工作
Icon of admin
 RaspberryPiのGPIOでリレーを動かす回路です。
 今回はUSB電源を制御するので諸々名称はそれに合わせています。
20230315121152-admin.jpg
 リレーのB接点はオープンでもいいと思うのですが、放電経路と見なし、抵抗を介してGNDに落としています。

#電子工作 #RaspberryPi
Icon of admin
 GPIOに出力したACT信号でリレーが動いたのですが、実装する基板をどうするか。
 汎用基板でチマチマ結線するは面倒ですし耐久性に不安もあります。
 KiCADで回路図描いたのだから基板もデザインして中華基板にオーダーしますかぁ。
 まずは実装寸法を測ってみましょう。

#電子工作 #RaspberryPi
Icon of admin
 ライトアップの架台を作っています。

 道路の分離帯みたいなところに生えている桜をライトアップするのですが条件が厳しい。
1)桜の根が傷むから地面にアンカー類は打たないこと。
2)(1)と同じ理由で土壌に加重を掛けないこと。
3)桜の幹に縛り付けるような取り付けをしないこと。
4)歩道、道路にはみ出さないこと。
5)アスファルトやコンクリート、縁石に穴を空けないこと。
6)現状復帰は厳重にすること。
 桜の保全を優先するなら真っ当なご指示なんですが、灯具を宙に浮かすのかい?って話です。

 唯一可能なのは、分離帯を囲む縁石に金具をクランプして荷重を掛けつつ固定する方法。
 しかし、土壌は縁石の上面ギリギリまで攻めており、縁石自体傾いたりしています。
 方針は、
1)縁石と土壌の間に薄い鉄板を打ち込む特殊なコの字クランプを構成する。
2)クランプから架台本体への繋がりには2軸の自在関節を入れる。
 となります。
 言うのは簡単ですが、私が出来る加工と予算の範囲でこんな物を作れるのかいな?
20230314162931-admin.jpg
 仕方ないから作ってます。

#ガチ工作
Icon of admin
 ここ数日ライトアップの架台を作っていますが、部品点数が多く作業工程も多いのでナカナカ終わりません。もちろんデスクワークもあるでの終日とはいきません。
 今日はガチの溶接作業をしましたが、立ったり屈んだりの繰り返しだったので全身筋肉痛。
 それにしては力尽きた感じは無く即日筋肉痛ですから年齢を考えれば悪くないのかな?アドレナリン・ハイなだけで明朝は起動出来ないかも?
 日が暮れると細かい作業が難しいので午前様までやらずに上がり。ワークが見えないのですから目は年齢ナリかな?
 残り作業はあと6時間くらいですが先が見えてきたので何とかしましょう。現地設置は3日後ですが、溶接作業と細かい作業が無ければ遅くまでやれます。現場やデスクワークもありますけどね・・・。

#ガチ工作
Icon of admin
 工作の軍資金の一部は株で得ています。
 博才がゼロなのか大儲けはできませんし損切りで負けることもありますが、年利換算で10%くらい取れているのでヨシとしています。銀行に預けても実質目減りするだけですしね。
 原資の額は秘密ですが、信用を使わず現物のみなので、儲けは少ないけど大負けすることもありません。倒産に引っかかったこともありましたが、夜逃げでもされない限り公開買い付けになるので溶けて無くなることもありません。
 倒産の可能性が低い企業の株を平均株価が下がった時に買い、平均株価が上がった時に売るだけです。ここしばらくの平均株価は2-4ヶ月で大きく上下しているのでわかりやすいと思います。目先の僅かな増減に一喜一憂せず、数か月スパンで見るとストレスもありません。現物なら何年持っていても単なる株主なだけで、配当が無かったとしても取られることはありません。もちろん、配当目的でもいいと思います。配当の利回りが銀行の金利より安いことは滅多にありません。
 所詮博打ですから利益は約束されておりませんのでお勧めはしませんが、稼ぐって意味ではパチンコやスロットより確実な気がします。

#雑談
Icon of admin
 リノリュームを敷いてバラすだけなので、ヒマ潰しでC言語の勉強をしてます。
 youtubeの「C言語入門」がナカナカ良いです。
 初心者向けと言えば初心者向けですが、他の言語をある程度書けるC言語初心者さんとか、初心者は卒業したかな?って人が基本を再確認するのに良い内容だと思います。私もその1人です。
 プログラム初心者さんがC言語から始めるのはオススメしませんけどね。

追記
 気を抜いてyoutubeを見ていたら「照明オペしてくれませんか!?」との依頼。ホールさんが仕込んてくれた地明とホリゾントで主催者操作の予定でしたが色々あって人手不足とのこと。暇ツブシを考えていたので問題ナシ。
 ホールの卓は松村電機さんのF151。私は好きな卓です。悪く言えば無芸ですが、欠点もありません。自分の主義ですが、ホール卓は基本的な機能を少ない手数で迷わず使えるのが望ましい。操作に一貫性があるシンプル・イズ・ベストってことです。F151は正にそんな卓です。作られた時期的に搭載されていないだけですが、JASCII(ASCII)の読み書きとパッチアウト(インパッチ??)が出来たらホール卓として丁度いいと思います。残念ながら今は廃番です。
 イチイチご機嫌を伺わないといけない某M社の卓は嫌いです。

#C言語
Icon of admin
 持込卓のパッチをホール卓で行うことを現場の人は「パッチアウト」と呼び、メーカーの人は「インパッチ」と呼びます。「カレーライス」と「ライスカレー」みたいな話しですが、個人的には「インパッチ」が意味に合っている気がします。どちらも他の事柄と被ってはいませんし、方言と思えばそれまでですケド。

#照明器具
Icon of admin
 ライトアップの架台を現地設置してきました。
 取り回したパイプに灯具を取り付けます。
202303221949371-admin.jpg 20230322195311-admin.jpg
 縁石に取り付けたクランプはこんな物。
20230322195432-admin.jpg 20230322194937-admin.jpg 20230322195229-admin.jpg
 金具とパイプの加工は予想の3倍の作業量でした。
 図面で所要時間が見えないのは所詮素人だなと。

#ガチ工作
Icon of admin
 ライトアップを終わらせました。
20230324211358-admin.jpg
 架台と照明の作業比は9:1くらいでした。照明はなんちゃことなかったのですが、架台は部品製作から現地設置まで丸一週間かかりましたので。
 電源コネクタはTRUE1です。対候性能はIP65ですから、水没しない条件で全天候対応です。屋内でも普通に使えますから、直電源ケーブルは全てコレにしたい。
 純正品は高価ですが、中華電機で互換品(もといパチモン)が手に入ります。全身黒もあります。
 中華電機には色々なセラーがいますが「R Conector Store」は良心的なパチモンを扱っていると思います。
 良心的なパチモンとはコレ如何にだけど、下請け工場が5時から仕事で作っている感じですから中身はホンモノかなと。ちなみに「5時から仕事」とはホンモノを作っているところが横流し品を作ることを言います。

#本業
Icon of admin
 このところ本業が忙しい。
 落としどころは見えても道筋が見えない物件が多いので悩み多きオッサンであります。

 さて、息抜きには自分が作りたいモノを妄想するか作るのが一番です。TRUE1の分岐ボックスの試作を進めています。防水のブンキーはありますが、20Aクラスになるとお高いので。
 防水のためにはオスコネクタからケーブルを2本引き出すヤッツケ分岐はダメです。ブンキーみたいなモノにケーブルを生やすか、豆腐サイズのボックスにレセプタクルを埋め込むかの二択です。
 当初は3Dプリンタで樹脂製ブンキーを作ろうかと思ったのですが、積層が50mmを越えると割れが入ってしまい水が浸入します。PLAなら100mm積層しても大丈夫ですが真夏の倉庫の温度に耐えられません。ABSは丈夫で耐熱もいいのですが、積層が高くなると割れるのが欠点です。積層を低くしてハメ合わせにする手もありますが、防水性を得られる精度で嚙合わせられるかは運次第。樹脂製ブンキーは無理かなと。
 豆腐サイズのボックスを試作中です。アルミ角パイプの両端に3Dプリンタで作ったTRUE1を取り付けるフタをします。3Dプリンタの積層を低く抑えられるので割れませんし、仕上がり寸法がラフでも何とかなります。ただ、TRUE1のサイズ的に40x80x2.0tの角パイプが望みですが丁度よい切り売りが見つからず。仕方ないのでモノタロウさんで定尺4mのを購入。単価的には安いのですが、この長さではそれなりの金額。ヘタをすれば1個作って不要になりかねない試作でこの量と金額はどうしたものか悩みました。
 取り急ぎカットしてモックアップを組んだところイイ感じ。アルミパイプとABS製のフタの接合方法は検討中ですが、肝心の部分が見えれば何とかなるっしょ。
 この手の接合は接着や横ネジ止めが一般的ですが、アルミもABSも接着は苦手、横ネジは3Dプリンタの積層方向的に強度不足。
 となると、防水を兼ねて接着剤を併用しつつ、両側のフタを六角支柱(スペーサー)を介してネジ止めするのがいいかなと。
 六角支柱(スペーサー)は廣杉計器さんで様々なサイズが少量から安く買えます。M3-L100があるのでこれかな?

#ガチ工作

2023年4月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 現場が続いております。
 難易度は低い物件ばかりですが、連日はナカナカ重いです。

 そんな渦中、「靴屋の小人」もとい3Dプリンタさんが試作品を作ってくれてます。
 プリントには小物でも数時間かかりますから、出掛ける前や寝る前にセットすると丁度いいです。プリント不良が出るのは1層目が大半ですから、最低限それは見送りますケドね。

 これまで結構な量をプリントしてきましたが、必ずしもCADデータの通りにプリントされないのが難しい。樹脂成型は金型を使ってもそういうモノらしいので仕方ありません。
 私が使っているプリンタの場合、例えば平プレートに穴が空いているモノを作るとして、プレートの外形はCADデータの寸法がほぼ出るのですが、穴径は0.5〜1.0mmくらい小さくなります。特に小さな穴ではCAD段階で大きくしておかないといけません。どんな形状を作るとしても、テストプリントの実測から重要寸法の調整は必要です。

#3Dプリンタ
Icon of admin
 3Dプリンタが不調です。
 起動直後は正常ですが、しばらくするとプラットホームの温度が0度を示すかエラーを吐いてプリントが止まります。以前は極稀な現象でしたが、徐々に頻度が増えてきて、昨日今日は毎回発生してプリントが終わらなくなりました。
 原因は不明ですが、プラットホームの温度を測るサーミスタ(温度抵抗)が寿命かもしれません。サーミスタに寿命あるとは思ってもいませんでしたが、先達の書き込みによると連続運転での寿命は1~3年とのこと。購入したのは5年くらい前ですから使用頻度を考えればそんなもんかなと。
 プリンタの買い替えも視野に入れていますが、その前にサーミスタを交換してみます。定格は不明ですが、壊れかけながらも正常な値を示しているであろう室温で98kΩ前後を示しますので100kΩの物と思われます。形状とサイズは表面実装3216(JIS)サイズですが、基板のパターンは2012(JIS)サイズでも取り付けられそうです。表面実装タイプは最大でも100kΩなので、定格を間違っても壊れることは無いと思います。

追記
 国内で探したところ1608(JIS)サイズばかりです。さすがに小さすぎて基板のパターンに合いません。
 中華電機に3216(JIS)サイズの100kがありましたので発注。最小単位50個です。送料含めて1,000円以下なので許容範囲ですが、この数をどうしろと・・・。安いのは有難いことですが、中華電機で部品を求めると数が多くて困ることが少なくありません。サーミスタのハンダ付けは温度条件が厳しいので、失敗しても構わないと思えばいいのかもしれませんけどね。
 配送予定は4/20です。このところ配送が早い中華電機に期待しますが、3Dプリンタ作業はしばらく中断です。

追記
 4/20到着予定のサーミスタが4/10に届きました。
 早い!
 

#3Dプリンタ
Icon of admin

 「オジサンの休日」はツボです。
 最近はアップの頻度が月に2-3回に減ったのが残念ですが、専業youtuberさんではない家族持ちの本業持ちのお方がここまでやるのは尊敬します。
 その昔はサザエさんを観ると月曜日が怖くなったものですが、オジサンのチャンネルを観る様になってからは日曜日が待ち遠しくなってます。

#雑談
Icon of admin
 お陰様で本業が忙しい今日この頃です。
 部下が照明の空打ちをしていた時に話していたのですが、CUEの送りを曲に合わせて自動化出来ないかとのこと。
 ストリートダンス系の仕事が頻繁にあるのですが、打ち込みはいいとしても本番オペが案外大変。照明のリクエストをしてくるのが振付をしている指導者ですから要望が年々細かくなってきているのです。さらに、多いと60曲はある長い本番を最後まで集中し続けるのは現実的ではありません。
 1曲あたりのリクエスト数を制限する手もありますし、リクエストに100%応えているワケでもありませんが、空打ちの際にタイミングもプログラム出来たらってことです。
 音源に則したタイムコードを得ることが王道でしょうか。音源をモノラルにしてタイムコードも録音するのが常套手段としても、誰がその編集をすんだって話。
 ようやく本題ですが、mp3プレーヤーからタイムコード(SMPTE12M-LTC)が出ないかなと思った次第。
 そんなアプリがあればいいのですが、RaspberryPiで作れのでしょうかね。mp3やWAVファイルの再生は可能ですし、タイムコードを吐き出すことも可能です。可能なモノをミックスすればいいのでプログラムは作れると思われます。

#本業 #RaspberryPi
Icon of admin
 試してはいませんが、Linux系で音源を再生するのは簡単っぽいです。
 モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
 ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
 ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな?。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
 合間に調べを進めましょう。

 目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。

#C言語 #RaspberryPi
Icon of admin
 PythonでVLCライブラリを使えば映像や音声に関して今やりたいことは全て出来そうです。
 VLCは映像や音声の類は何でも再生出来る便利なアプリですが、コマンドラインでも使えるし、プログラムを書くためのライブラリとしても機能します。Windowsはもちろん、MacでもLinuxでも動きます。
 懸案の再生時間の取得ですが、再生のためにはファイルをVLCモジュールに読み込んでインスタンスにするのですが、インスタンスからget_time()を取ると現在の再生ポジションをmsecの値で得られるようです。得た値の扱いはよく考えねばなければなりませんが、途中から再生しても適切なタイムコードを出せそうです。
 ついでにTASCAM系のプレイバックも協調動作させますか。比較的単純なシリアル信号で動きますから、CDなどを同時スタート出来ればバックアップになります。
 もちろん、PythonのライブラリがあるならC言語のライブラリもあると思われます。Pythonで書いとけばプラットホームを選ばないので、このツールはC言語で書くよりいいのかもしれないけど。
 開発する時間がないので当面棚上げですが、ノンビリ研究していきましょう。

追記
 C言語のライブラリーはlibvlc、includeは<vlc/vlc.h>だそうです。
 映像を表示せず音声だけの出力も明示的に指示出来るようです。

#タイムコード
Icon of admin
 PythonならVLCを簡単に扱えそうですが、C言語で扱うのはちょっと難しそうです。
 ネットには先達の情報が少なく、VLCライブラリのヘッダーファイルを読んでも理解不能。ヘッダーファイルには更なるヘッダーファイルが記述してあり、そのヘッダーファイルの中にも更なるヘッダーファイルがあります。どこまで深いのかわからんくらいです。プロトタイプ宣言と思わしき記述もゴリゴリのC++なので何がどうなっているのか追いかけられません。高度で大きなアプリケーションですから簡単ではないのです。
 当面はPythonでの実装を目指し、C言語での実装を夢見るってところでしょうか。

 となると、Pythonでタイムコードの生成をするのがカギになるかもしれません。
 Pythonで安定したLTCの波形を生成するのは厳しそうなのでMIDI-TimeCodeにするのが現実的でしょうか。MIDIは9600bpsのUARTですからPythonでも余裕を持って作れます。ただ、音源操作と照明操作の場所が離れているとMIDIでは接続が難しいので、音声信号として送れるLTCが望みです。MIDIをRS485に変換すればいいって話もありますけどね。
 C言語でLTC生成のPythonライブラリを作るのがいいのでしょうか。PythonライブラリをC言語で書いたことはありませんが、C言語のライブラリとして成立していれば比較的簡単な記述でPythonライブラリが作れるそうです。

#タイムコード
Icon of admin
 ホール管理の増員で操作盤の置物になっているだけなので調べモノをし放題です。

 PythonのライブラリをC言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。

 製作手順を大まかに書き出すと、

1)関数ライブラリを用意する。
 C言語で#includeして使える関数なら汎用でも自作でも何でもいい。
2)「ラッパー関数」を用意する。
 C言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をC言語で記述します。
3)セットアップファイルを用意する。
 セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
4)ビルドする。
 セットアップファイルを使ってビルドする。
5)インストールする。
 セットアップファイルを使ってインストールする(動作の実際はPythonパッケージ管理のpipへの登録)。

 と、なります。
 ラッパー関数はC言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。

#C言語 #Python
Icon of admin
 Linux上のC言語でLTCの波形を起こせたらと思ったのですが、処理能力の総量は余裕タップリなものの、Art-Netエンジンを作った際に感じた挙動ムラから想像するに許容範囲を越える波形ムラが起こりそうです。LinuxはOSそのものや他のモジュールに引っ張られて100~300usecくらい待たされることがあるのですが、LTCの波形を起こすのにこの条件はよろしくありません。RTOSを使わないなら普通のことですけどね。

 ならばLTCを起こすところにはPICを使ったらいいかな?適材適所?
 LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。2~4フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
 差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは1フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
 求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。

 書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。

#タイムコード #PIC #電子工作
Icon of admin
 3Dプリンタを直すための部品(サーミスタ)が予定よりも早く届きました。
 4/20到着予定が4/10です。印象操作を感じなくもないですが、土日を挟んで6日間ですから十分に早いでしょう。
 これで治るといいですが、どうなることでしょう。

 そういやムービングライトが1台動作しません。先日も同様の不良が出たので修理を試みたのですが、原因を探ろうとしたところ動いてしまい原因を追えなかった機体です。
 ウォッシュタイプですが、PAN/TILTは動くのにLAMP周り(LEDとズーム)が動きません。PAN/TILTとLAMPは制御基板が別々なので、LAMP側の基板が動作していないことになります。
 動作しないと言っても基板の故障とは限りません。電源のパイロットランプは点灯するし、要所には定格の電圧が来ています。正常な機体で試してみたのですが、サーマルセンサからと思われるケーブルを抜くと同じことになりますので、たぶんこのケーブルの先に故障があるのでしょう。サーマルセンサか、ケーブルか、間に入っている回路か、ジックリ確認しましょう。
 サーマルセンサが不良の場合、今回買った物が使えるなら楽なんですけどね。50個も買ってしまったし。

#3Dプリンタ #照明器具
Icon of admin
 3Dプリンタは治ったようです。ただ、主原因はサーミスタ(温度センサ素子)ではなくコネクタピンでした。
 サーミスタを交換しても完全に治らないので、改めてテスターで当たりまくるとプラットホームのコネクタピンの一部が根元は導通するのに先端は導通しないのを発見。ピンを取り外して確認しましたが、変色などまったく無く見た目はキレイでコジっても折れず。不良とは到底思えないのに導通がありません。しかも、そんなのが2本。同じ銘柄のコネクタからピンを取って交換したところ正常に戻った次第です。
 不良コネクタピンの1本は複数あるGNDの1本でしたが、ヒーター電源の通りが良くなったのかセンサーの反応が良くなったのか、プラットホームの温度がこれまでになく安定しています。取り外したサーミスタはよく見るとコゲっぽい色になっていたので交換時期と思って間違い無さそうですが、よもやコネクタピンが不良の主原因とは思いもよらず。コネクタの不良はメスコンタクトが緩んで接触不良になることが多いのですが、オスコンタクト(ピン)の中折れは初めてです。ユーザーのナニのナニとシンクロしたのか!?
 オヤジ小ネタはともかく、キツネに抓まれたような気分です。何がなんだか・・・。毎年初詣に行く稲荷神社に行かなかったのでお狐様が意地悪しに来たのでしょうか??腑に落ちないとはこのことですが、わからんもんはわからんので、プリンタを買い直さずに済んだことを素直に喜ぶしかありません。
 試作品の製作を再開しました。喜ぶのはこのジョブが最後まで終わったのを見届けてからかな?ジョブを開始して1時間、今のところ安定して動いています。
 明日から浜松まで出向いて2日程現場なので、プリントの品質が良くなることを祈りつつ今夜は寝ます。

#3Dプリンタ
Icon of admin
 プリントが終わったので仮組み。
 寸法の修正はありますが一応形になりました。あと2-3回やれば条件が出るでしょう。
 実際はアルミ角パイプの中にコレを入れます。
20230411082906-admin.jpg 202304110829061-admin.jpg
 3Dプリンタは復活したようです。

#3Dプリンタ
Icon of admin
 先日ユニクロに行ったのですが、会計方法に驚いた。
 いわゆるセルフレジの部類ですが、買い物カゴごと所定の場所に置くと一瞬で合計金額が出てきます。
 正直「何が起こった!?」「前の人の会計ぢゃね??」パニクリましたよ。
 商品のタグをよく見たら「IC-Tag」と書いてあります。なるほどねぇ~と思いつつ、「IC-Tagってホントに安くなったんだ」とか「人件費考えたら割に合うだろうなぁ」とか「万引き防止にもなるねぇ」とか考えてしまう自分。
 IC-Tagは簡単に言うなら小さい小さいwi-fiマイコンです。厳密にはwi-fiとは違うのですが、無線でデータをやりとりするって意味で捉えてください。不思議なのは電源を持っていないのに動くのです。なんでだろ!?
 細かい事はわからないのですが、少し調べてみてもいいですね。
 そこまでする価値があるかは別にして、機材に付けておけば数のチェックが一瞬です。時間に追われるツアーとか大量の機材を扱うところではいいかもしれません。

#雑談
Icon of admin
 3Dプリンタの条件が出たようです。
 六角スペーサーを差し込む穴の寸法で難儀してました。M3の六角は5.5mmですから5.6mmくらいの仕上がりにしたいのですが、CAD上で5.6mmとしても仕上がりは5.6mmになりません。今回は5.9mmにして仕上がり5.6mm強でした。ぢゃ0.3mmふかすのが定数かというとそうでもなく、内形か外形かでも違いますし、周囲の肉厚によっても違います。目安にはなるものの試作を繰り返して追い込まなければなりません。
 FDM式の3Dプリンタは溶かした樹脂でプロッタように線を描いていくのですが、描画した樹脂の幅には±0.2mm程度の誤差があるようです。内形寸法では対角で合わせて倍の誤差になりますので、今回の狙い寸法に対しては比率的に大きい値です。ただ幸いなのは、プリントの度に寸法が違うことはほとんど無いことです。誤差ではなく、プリンタとフィラメントの組み合わせによる特性と呼ぶのが正しいのかもしれません。補正設定がCAMにあるかもしれませんので調べてみましょう。

#3Dプリンタ
Icon of admin
 教科書に反する使い方なのでツッコミ所はありますが、アイデアがあるなら実験は大事です。
 ビデオカメラのフリッカーは蛍光灯より酷そうだけど・・・。

 調光器が壊れる可能性はありますが、SCRでスイッチングしたらどうなるか試してみたいですねぇ~。
 ダイオードブリッジと大型コンデンサでAC100vから起こしたDC141vを使ったらどうなるんでしょうね。200vの大型コンデンサが余っているので、リップルは気にせず爆発覚悟で試したいかも。
 つか、DC141vをパワーMOS-FETでスイッチングしたら調光できんぢゃね?電源が暴走して400vくらい出すかもだけどwww

 この使い方はLED素子のポテンシャルを100%引き出せませんが、100%でなくてもいいんですよ。費用対効果が成り立って安全が確保出来て十分に明かるければソレでいいのです。
 考えようです。

#LED
Icon of admin
 トラブルは続くんすね。3Dプリンタさんはフィラメントを飲み込めなくなりました。
 これまでに何度もあったことですが、フィラメントを送るローラーにフィラメントのカスが詰まって滑るのです。ローラーは歯車状のギザギザにフィラメントを引っ掛けて送るので、カスが出て目詰まりするのです。
 対策は分解清掃です。ギザギザが見えるところまで部品を外し、千枚通しでギザギザの詰まりを取り除きます。少し面倒ですが、ローラーを取り外した方が詰まりが見えやすく掃除もしやすいかな?
 分解を前提に作られておりませんので部品の位置やアタリに気を付けながら組み直します。作業は20分くらい。目に見えてプリントの質が良くなります。

#3Dプリンタ
Icon of admin
 3Dプリンタさんは「靴屋の小人」として復活。
 朝起きると綺麗にプリントされてました。
 次はケーブルの配線を決めましょう。

#3Dプリンタ
Icon of admin
 「靴屋の小人」さんは完全復活です。
 追加で2セット作りましたが、途中で落ちることもなく仕上がりも綺麗です。
 現場続きだったので配線の検討はこれからですが、筐体は十分な仕上がりでしょう。
 まだ決めていないのは目地止めです。コーキング剤に何を使いましょう。アルミもABSも接着は苦手な素材です。求めるのは強度ではありませんが、十分な水漏れ対策となりつつ、修理でバラせなければいけません。バスコークが安価で無難な気もしますが、黒っぽいのが無いので仕上げが難しくなります。シリコン系コーキング剤は安価ですがはABSと相性が悪い様子。ダークグレーでブチルゴムに特性が近い変成シリコン系でしょうか。「変成シリコンコークQ」ならフライトケースのウレタンが外れた時の補修にも使っているので常備しています。

#3Dプリンタ #工具や資材
Icon of admin
 3Dプリンタはイイ感じですが、そもそもCADデータの通りプリント出来ないのはよろしくありません。
 当面の課題はクリアしたので、CAMの設定でどこまで追い込めるか実験を始めました。
 まずは、内形もある簡単な形状でテストプリントです。どの方向にどれだけ寸法がズレるかサンプルを取るのです。
 CAMのどの設定項目が影響するのかを見つけるのにかなりの回数プリントすることになりそうですが、都度の調整作業が減るなら価値はあります。トータル時間はかかりますが、拘束時間は大したことありませんしね。
 室温やフィラメントの質にも左右されそうですが、樹脂成型はそういうものらしいので、季節の変わり目やフィラメントの入れ替え時に確認するのもありでしょう。
 ということで、靴屋の小人さんには今夜も頑張ってもらいます。

#3Dプリンタ
Icon of admin
 3Dプリンタの条件を出すのはナカナカ難しい。
 試しに最新のCAM(スライサ)を使ってみたのですが、プリントそのものはキレイですが、プリント位置がズレてしまいます。デュアルノズルですが、1番ノズルは良いものの、2番ノズルの位置が補正されません。メーカーに問い合わせたところ「そのプリンタはとても古いので、最新のスライサは対応してません」とのこと。機種選択もプリントも出来るのですけどね・・・。サポートを得られない、すなわち対策を教えてもらえないのでは太刀打ち出来ないのでCAM(スライサ)を古いヴァージョンに戻しました。
 位置のズレはあるものの最新のCAM(スライサ)ではキレイにプリントされたので、その設定値を参考に手直ししたところかなり改善されました。パラメータの解説が無いので手探りが続いていましたが、機能が不明だったパラメータの意味が以前よりわかってきたので試すべき方向性が見えてきました。
 プリント結果からCADデータを修正するのではなく、期待値で書いたCADデータを用いてCAM(スライサ)の修正を続けてみます。

#3Dプリンタ
Icon of admin
 オレメモです。

 プリンタ:QIDI Tech I(デュアルノズル)
 CAM(スライサ):QidiPrint ver5.6.12
 フィラメント:ABS

 期待値のままのCADデータを用いる。
 CAM(スライサ)で全体伸縮を100.2%にしてプリント。
 プリント物を実測すると外形寸法は3軸ともほぼ出る。内形寸法は直線なら線間が-0.3mm、丸穴なら直径が-0.6mm(半径で見れば-0.3mm)となる。

 CAMでの補正はこれ以上難しい様子だが、実測から推測するに、CADにおける内形の補正は定数を用いて良いと思われる。

 以下、CAD上で行った修正項目。なお、CAMでの伸縮は100.2%。
 M3六角は5.5mmだが、製品公差と接着隙間を考慮して期待値を5.7mmとし、プリント公差0.3mmを加えて6.0mmの六角とする。
 M3用のΦ3.2の丸穴はプリント公差0.6mmを加えてΦ3.8mmとする。
 TRUE1本体を差し込む丸穴もプリント公差0.6mm加える。
 ・・・現在プリント中。

#3Dプリンタ
Icon of admin
 3Dプリンタは良くなってきました。
 その場しのぎで寸法を出すのではなく一発で寸法を出したいのですが、その方法論を得られそうな感じです。
 本業は現場の本数は落ち着いているものの先の準備で忙しいのですが、朝夕に靴屋の小人さんのお仕事をチェックさせて頂くだけですから、忙しくても息抜き程度の時間で進められています。
 今のネタは程々の精度で良い製品なので仕上がりと所要時間のバランスを求めていますが、このプリンタの最大精度も探ってみたいものです。

#3Dプリンタ
Icon of admin
 汎用マイコンであるArduinoがCPUをarmに変更するらしい。チップは日本のルネサス製を使うとのこと。
 ArduinoはRaspberryPiと同類の製品ですが、中身というか考え方は別物です。どちらが作りたい物に適しているかが重要で、どちらが優れているかを議論するのは無駄ですケドね。
 現行のArduinoはATmega系を使っています。優秀なマイコンですが8bitです。RaspbrryPiはarmの64bitですから比較に意味がないとしても、流石にパワーアップを考え始めたのでしょう。
 Arduinoは単機能のデバイスを作るにはとても効率的です。開発環境のArduino-IDEはとても使いやすく、ほぼC言語なArduino言語で記述するのですが、純C言語の難解な部分を触らずに書けるようデザインされているので取り組み易いと思います。ATmega単体で使う場合は開発環境の構築すら難解でしたが、Arduinoというパッケージになったことで飛躍的に使い勝手が良くなったと思います。世界中のハッカー達がこれでもかとライブラリを揚げているもの良い点です。
 私の場合、Arduinoが得意とする単機能デバイスはPICを使えば済んでしまうので使ってきませんでしたが、RaspberyPiを使うには大げさだけどATmegaやPICでは物足りない物を作るのに最適なら新しいArduinoも使ってみたいと思います。
 ただ、RaspberryPiを中核にPICを組み合わせるとそこそこ何でも作れるので、開発時間が取れない状況で新機軸に手を出す価値があるかは何とも言えません。

#RaspberryPi
Icon of admin
 3Dプリンタは条件が出ました。
 廃番になった古いプリンタなのでCAM(スライサ)の設定は揚げませんが寸法補正は出ました。

 外形補正はCAMの全体伸縮を100.2%します。
 内形補正はCAD上で行い、円なら直径に+0.6mm、多角形なら基準寸法に+0.3mmです。

 これらはCAMの他の項目によっても違ってくるので、現在標準としているCAMの設定に於いては・・・という値です。
 ただ、上記3点の補正値が定数であることが重要です。サイズによって補正値が違うと難解ですからね。

#3Dプリンタ
Icon of admin
 3Dプリンタは期待値が出る様になりました。
 樹脂成型は難しいですね。

 期待値は出たものの、5.7mmにしたM3六角(5.5mm)を挿す穴が緩い。5.5mm丁度は危険なので期待値を5.6mmにして再度プリント中。
 5.5mmに対する5.7mmは3.6%の違い。たかが0.2mm、されど0.2mm、一見小さな数字ですがこれだけのクリアランスでガバ付きを感じるんですね。たぶん、丸穴なら気にならないのでしょうけど。

#3Dプリンタ
Icon of admin
 フィラメントを使い切ったので別な物に交換。反り難いと高評価の物。
 十分綺麗なプリントだし謳い文句の通り反りは少ないけれど、ノズルの温度が合っていない感じがします。縁にバリというかブツブツが出るのです。温度設定をどうするか・・・
 購入ページで確認し直したところ、ノズルの推奨温度が今までのフィラメントよりも15度くらい高い。その代わりプラットホームの推奨温度は5度くらい低い。
 今のプリンタでノズル温度をそこまで上げられるのか疑問だけど、反りが少ないので使える様にしたい。
 改めて条件出しです。

#3Dプリンタ
Icon of admin
 とりあえずの探り設定で綺麗にプリント出来ました。一つ前のプリントの不良は解消。
 これから数日は「靴屋の小人」さんに日夜頑張ってもらいましょう。1セット5時間半なので、出勤前と寝る前に開始、1日2セットです。
 製作数は未定ですが、角パイプを4mも買ってしまったので半分は使おうかなと。角パイプを90mm使うので20個程度作れます。パチモンTRUE1は山ほどあります。

#3Dプリンタ
Icon of admin
 本業の合間にTRUE1の分岐ボックスを進めていますが、落下防止ワイヤーの取り付け方を考えていませんでした。普通のブンキーのワイヤーと同じ使い方です。
 筐体の外側にワイヤーを掛ける金具を取り付ければいいのですが、言うほど簡単でもありません。プリント物に力が掛かればムシれてしまいそうですし、アルミ角パイプにネジ止めなら強度は十分なものの水対策をしなければなりません。
 金具はイロイロありますが、アイストラップが安くていいかなと。平板にネジとワイヤーを通す穴が空いただけのワイヤープレートは安そうで安くありません。形状が立体的なアイストラップの方が安いのには驚いた。
 課題は取付けネジの処理です。何も対策しないとネジ穴の隙間から水漏れします。筐体の角パイプは2.0tですから、丸穴ではなくタップを切り、ネジ山にコーキングを塗って締め付ければ目地止めになるでしょう。実際の仕込みでは本体だけでなく接続されたケーブルの加重もかかるので強度に不安がありますが、角パイプの内側からナットを締めればよいと思われます。

#器具の製作
Icon of admin
 amazonさんを眺めていたらワイヤーをカシめるクランプが出てました。
 この手の工具は一般的に高額ですがとても安い。試しに買ってみました。
 ORANGEHOME 圧着ペンチ ワイヤークランプカッター アルミスリーブ かしめ機
 20230426134153-admin.jpg
 造りはお世辞にも良くありませんが、補修とか数十本の製作には使えるでしょう。
 JISに準じた締め付けがされるかは不明ですが、試しにカシめたワイヤーは見た目にもしっかりしていて、強く引いても抜ける気配ありません。少なくとも、電工用のリングスリーブでカシめるよりマシではないかと。
 安全基準を担保したいならクランプもスリーブもJIS規格適合品を使いましょう。

#工具や資材
Icon of admin
 ふと思いついてこんなん試作ってみました。
20230427110940-admin.jpg 202304271109401-admin.jpg
 塩ビ水道管のT分岐にTRUE1のレセプタクルを取り付ける方法です。
 TRUE1の取付部は3Dプリンタで作っています。何の仕上げもしてないのはご愛嬌。
 塩ビ水道管の接着剤(エスロン)はABSも溶かすようです。ABS接着剤と臭いが似てるので試したところビンゴでした。
 溶着なら水漏れの心配はありませんし接着強度も十分です。
 
 先日作ったのはY分岐で、これはT分岐です。
 どちらがいいというより使い分けです。
 サスバトンに鈴蘭ケーブルごとく横繋ぎしていくならこれの方がいいかも。
 寸法の手直しがあるので、もう1セット作って評価しましょう。

 Y分岐もそうですが、意外な問題点はケーブルの仕舞い方です。
 ハウジングにはレセプタクルの取付穴しか開口部がありませんので、ケーブルの先端が取付穴から顔を出さないと結線が出来ません。この顔を出すための余長が思った以上に仕舞い難いのです。
 出来るだけ柔らかく、出来るだけ細いケーブルが望ましいのですが、KIVではなくHKIVなら太さを1ランク落とせます。KIV2.0スケアとHKIV1.25スケアの許容電流はほぼ同じです。
 

#3Dプリンタ #器具の製作
Icon of admin
 TRUE1のT分岐を配線してみました。
 ケーブルは圧着したタブ端子がハウジングより顔を出す長さにしましたが、TRUE1のレセプタクルを回してケーブルを捩じりながら押し込むと収まります。
 ただ、捩じることによってケーブルが引っ張られるため、マレにですが、先に固定したレセプタクルのタブ端子が半抜けすることがあります。
 ハウジングの構造上、組付け後の状態確認が出来ませんのでちょっと怖い。何らかの固定方法が必要です。
 タブ端子は全カバーの物を使っていますが、半カバーの物にしてハンダ付けで固定でしょうか。もしくは、TRUE1のタブ端子にケーブルをハンダで直付けでしょうか。

#器具の製作
Icon of admin
 TRUE1のT分岐のハウジングには呼び径16の塩ビ管チーズを用いていますが、ケーブルを処理しやすくするためにもう少し太くしたい。内寸は呼び径25がいい感じですが、TRUE1のネジ穴がチーズの外壁に被ってしまい取り付け方で悩む。コップ状のカバーとし、底というかレセプタクルを取り付ける面を厚くすることにしました。

#器具の製作
Icon of admin
 呼び径25のチーズを買ってみたのですが寸法に問題あり。
 規格の外形寸法は40mmですが、実測すると3口の内2口は40.2mmだけど1口が41.0mm。0.2mmオーバーは許容範囲だけど1.0mmオーバーには無理がある。
 カタログを見ると公差表記は内径だけ。本来の用途からしたら内径が重要であって外径はオマケ。型抜きしやすい寸法なのかな?
 さて、どうするか。TRUE1を取り付けるマウンタを1.0mmオーバーでプリントをしてもいいけど、規格値からは大きく外れているので今回買ったチーズがたまたまかもしれません。
 チーズの寸法を整えるのが良いと思われる。回転センターの補助金具を作ればミニ旋盤で削れると思う。塩ビは柔らかいからミニ旋盤にはサイズオーバー気味でも削れるし、エスロンで接着するなら0.2mmくらいの精度で収まっていればOK。

#器具の製作 #ガチ工作

2023年5月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 チーズを削ろうと思ったら呼び径25のチーズは手持ちのミニ旋盤には入りませんでした。枝が引っかかるのです。
 ならば違うアプローチの工夫です。3D-CADのデータをチーズに合わせて変更しやすくしました。チーズと噛み合う寸法を現物に合わせてプリントするのです。
 数を作ることになればネットでまとめ買いすると思いますが、近所のホームセンターの物と寸法が違う可能性への対応です。

#器具の製作 #ガチ工作
Icon of admin
 呼び径25のチーズでTRUE1の分岐を試作ってみました。
 チーズは10mmほど切り詰めています。
20230502171802-admin.jpg 202305021718021-admin.jpg 202305021718022-admin.jpg
 チーズとプリントしたマウンタの両側にエスロンを薄めに塗ってハメ込んでいます。ハメ合わせた直後に少し回して馴染ませて位置決めをします。固着が早いのでノンビリしていると動かなくなるので注意です。
 いい感じなので、マウンタにはジクロロメタンを塗布して目を潰し、全体を塗装して仕上げます。塩ビやABSは塗装が苦手ですが、シリコンオフで拭き上げ、ミッチャクロンを塗布して本塗りすれば十分に強い塗装に仕上がります。

 配線のためにチーズを太くしたワケですが、吉と出るか凶と出るか。
 手で扱う器具は小さくて軽いのがいいのですが、見た目は太ましくなったものの、計測すると重量も外寸もそれほど違わないのでいいかなと。

追記
 落下防止ワイヤー用の金具を付けたので写真を差し替え。

#器具の製作
Icon of admin
 触ったことはないのですが、最近のAIの進化は凄いですね。
 重箱の隅を突けばダメなところもあるでしょうけど、その結果を自らの手で作り上げることに比べたら圧倒的に簡単な作業(キーワード(呪文)を入力するだけ)で作ってくれます。
 今のところ目立つ成果は文書、イラスト(創作写真)、プログラミングですが、動画も作り始めています。一般の人が試せるようになったのはほんの数か月前からですが、その間にもすさまじい進歩をしています。使う人が増えたために情報も増えたというのもあるでしょうが目を見張るばかりです。

 以前から書いていますが、照明のプラン・オペをしてくれるAIも出てくれませんかねぇ~。
 凄い照明ではなく、曲に合わせてチカチカ・グルグルしてればいい照明の生産性を上げたいのです。フィクスチャーに内蔵された音調でもチカチカ・グルグルはしますが流石にそれではねぇ~。
 今も連休最後の土日に開催されるストリートダンスの照明打ち込みで部下が四苦八苦しています。CUE割りしたら900くらいあるそうですが、1曲平均15場面60曲としたら計算が合います。
 それが仕事だと言えばそうなんですが、AIを門前払いしたらムービングなど使わずに人の手によるサイドピン・バックピンにしろって話と同じですから、ご時世の技術を使ってより良い演出効果を低コストで求めるのは間違っていないと思うのです。

#雑談
Icon of admin
 今年の連休はちょいと忙しい。
 難しい物件はありませんが、事前準備が多い依頼が続いています。準備は一通り終わっているので気は楽ですけど。
 今日は午前中にリノ敷きだけなので午後は休もうかな。

 作りたい物(=欲しけど市販品に無い物)のネタが溜まっています。早く形にしたいのですが、製作経験のある物とは限りませんので何かと手間がかかります。
 限られた時間の中で何を優先するか悩ましい。
 Art-Netパッチやタイムコードプレーヤーも進めたいのですが、アタマを全振りしないと太刀打ち出来ないこれらの品物は空き時間にちょっと進めることは出来ません。
 今のところ片手間に進められるTRUE1分岐を試作っていますが、連休中にこれらの仕様が固まればいいかな
 次をどうするかは連休が明けてから考えましょう。

#雑談
Icon of admin
 TRUE1のT分岐は完成した感じです。
 ケーブルをハウジングに通してからレセプタクルに取り付けるのでケーブルの余長を押し込むことになりますが、この際の捩じりやコジる力がタブ端子にかかって半抜けになることがあるのです。組んだ後に中を確認することは出来ませんから対策が必要でした。前の書き込みでハンダ付けを試しますなんて書いたのですが、ハンダが馴染む温度ではTRUE1側が溶けてしまい使い物になりません。
 ちょっと発想を変え、ハウジングに収まる範囲でケーブルを出来るだけ長くしてみました。ハウジングの中で余裕を持ってトグロを巻ける様にしたらタブ端子に負荷がかからないのでは?というアイデアです。チーズを太くしたために可能になった方法です。
 結果から言うとビンゴです。組み上げてから数日おいて分解してみましたが半抜けの気配すらありません。
 TRUE1の取り付け部に水漏れ防止のコーキングを挿して本組みです。

 ちなみに、求める水対策性能は「防水」ではなく「防滴」です。水に浸すのはNGですが、水がかかるのはOKという意味です。
 防滴を考える上で気を付けなければならないのは狭い隙間です。毛細管現象で水が吸い込まれていくからです。明らかな水の進入路をコーキングで塞ぐのはもちろんですが、こういったところも気を付けるべきです。

 先に製作していたアルミ角パイプを使う方法も進めています。あとはコーキング処理だけだったのでお休みしてました。
 これも分岐ですが、ケーブルの方向性からY分岐と呼びます。

#器具の製作
Icon of admin
 今週末はバレエ教室の発表会です。
 舞台監督でも照明でもなく道具屋です。ガチ公演ではありませんから、リノを敷いてジョーゼットを主にした飾りを休憩転換するだけで忙しくはありません。
 以前も書いたような気がするのですが、リノの掃除方法をオレメモ。
 基本は水拭きですが、重曹を少し入れると松ヤニやスモークオイルが落ちやすい様です。1リットル当たり大さじスリ切り1杯の割合です。いわゆる床掃除に使う濃度に比べたら薄いのですが、このくらいだと乾いても白く粉を噴きませんので中和拭きをしなくてもいいかなと。施工は農薬散布器で軽く噴霧して乾いたモップで拭きます。散布量の目安はリノを2-3本拭いてモップがやや湿る程度。乾くまでは少しヌルヌルしますが、乾けば本来のグリップに戻ります。松ヤニやオイルの付着が気にならなければ重曹の使用は3回に1回くらいにした方が良さそうでもあります。
 スモークオイルが落ちない場合は重曹の濃度を3倍程度にしてオイルを落とし、クエン酸溶液で中和拭き、水で仕上げ拭きと進めます。

#本業
Icon of admin
 昨日に引き続きバレエ発表会です。
 道具の転換だけですからリハ中の今はヒマなのでアイデアを整理しています。

 課題は「LTC Sound Player」です。
 wavやmp3の音源プレイヤーですが、再生している音源と並列のLTCも出力します。先日も書いたネタですが、折角の空き時間ですから改めて整理しています。
 音源再生にはVLCのライブラリであるlibvlcを使います。もっと直接的にOSとやりとりする方法もあるようですが、フォーマットやコーデックの違いをVLCが吸収してくれるので頼った方が間違いありません。記述はC言語系ならC++ですから勉強が増えますが、Pythonなら比較的簡単に書けそうです。
 LTCの出力にはPICを挟みます。LTCの変調は差動バイフェーズですが、RaspberryPiには専用モジュールはありませんし、ソフトウェアで波形を起こすよりPICを使った方が自分には簡単です。RaspberryPiとはUARTやSPIで通信します。
 レイテンシーを管理したガチの業務用ならC++記述しなければなりませんが、とりあえず作ってみようならPythonでイイと思います。

#器具の製作 #タイムコード
Icon of admin
 連休が終わってしばらく現場がありません。開発やらメンテナンスをする余裕が出ました。

 LTCジェネレーターの研究を進めてみます。
 これは「LTC Sound Player」で使うタイムコードジェネレーターで、UARTで受信したデータをPICで送出する物です。間にFT232RLを繋げばパソコン等からUSBでも制御出来るハズです。
 FT232RLはUSBシリアル変換ICです。比較的簡単な回路で動き、ドライバは最近のOSなら予め入っているか自動でインストール出来ます。
 FT232RLのいいところはMacでもWindowsでもLinuxでも使えることです。アプリケーションからは極々シンプルなシリアルデバイスに見えるので、大半の開発言語の標準ライブラリで扱うことが出来ます。
 当初C言語で開発しようと思ったのですが、音源再生やらLTCジェネレーターの構成を考えていくとPythonを用いるのが良さそうです。巧く書けばMacでもWindowsでもLinux(RaspberryPi)でも使えるモノになるからです。

#器具の製作 #タイムコード
Icon of admin
 オレメモです。

 LTCジェネレーターの制御は、パソコンやらRaspberryPi(以下、母艦と呼称)でLTCのバイナリを生成し、PICで所定のbpsの差動バイフェーズに変換することにします。
 PICにはFIFOバッファーを構成しようと思っていますが、母艦からPICへの送信がバッファオーバーフローか遅延にならない様にタイミングを考慮しないといけません。PICから母艦へデータ送信要求(許可)をする方法が必要でしょう。FT232RLはフロー制御も出来ますからそれを使ってもいいのですが、RaspberryPiのUARTにはフロー制御がありません。GPIOを直接制御してその様な信号を作ってもいいのですが、フロー制御を持ちなくても済むならそれに越したことはありません。UARTはデータを双方向でやり取りできますので、PICから母艦へデータ送信要求を送ることにしましょう。
 SMPTE12Mのフォーマットを8bit(1byte)区切りで見ますと、バイナリグループのビットを常に0にすることが条件ですが、上位4bitは0x0,0xB,0xF,(0x3)のどれかにしかなりません(0x3は逆再生した際にシンクワードで発生する値)。これ以外の値ならば制御コードとして使えます。ASCIIテキスト制御ではありませんから0x00と0xFF以外なら何でもいいので、双方で使える制御コードにしておけば後でわかりやすいかなと。
 この場合、上位4bitは0x5か0xAが一般的でしょうか。2進数ならb0101またはb1010です。0x7F以下のASCII文字になる値がデバックしやすいかもしれないので0x5かな。
 例えばですが、

0x50 初期化(LTC送信停止・バッファクリア)
0x51 これに続くデータは設定データ(設定はfpsとDF/NDF)
0x52 これに続くデータは送信データ
0x57 データエンド
0x58 データ受信要求
0x59 データ送信要求
0x5F データ(動作)エラー


 こんな感じ?

 後はbpsの精度をどこまで求めるかです。
 タイムコードの項に延々と書いていますが、波形周期を得るタイマー割込みのコンペア値を動的に変化させることで長周期の精度を水晶発振子の精度ギリギリまで出すことは可能です。ですが、どこまでの精度が必要なんでしょうね。

#器具の製作 #タイムコード
Icon of admin
 「LTC Sound Player」を本格的に製作する前にLTCによって生産性が上がるのか検証しなければなりません。本番操作が楽でも結果的に作業量が増えたら本末転倒だからです。
 音源を加工せずにLTCを出すことが目標ですが、まずはテスト音源を作成。花火屋さんに倣い、L-chに音楽、R-chにLTCです。今回は29.97fps(NDF)と25fpsの2種類を作ってみました。
 LTCはここで作ってもらいました。便利なサイトがあるものです。
 1時間目から本編開始とし、マイナス2フレーム(29.97fpsなら00:59:59.28)からのLTCです。2フレームは01:00:00.00を確実に掴んでもらうためのノリシロですが、普段の音源編集でも0.05秒程度のノリシロ(余白)を付けているので問題無いと思います。

 吉と出るか凶と出るか。

 そうそう、VLCをベースにするなら映像を元にしてもLTCが出せそうです。

#器具の製作 #タイムコード
Icon of admin
 LTC音源で卓が動きました。「MA dot2 core」です。
 トリガータイムは手打ちも出来ますが「TC Record」機能を使えばLTCを受けながら「GO」を押すことでタイムが取れます。タイムの修正も現在値に対するプラスマイナスで行えます。
 ただし、LTCが走り出してから認識するのに0.3sec.程度かかります。また、エグゼキューターをOffにしておいてもその時刻が来るとCUEが走ってしまいます。
 装置を構成するには卓の挙動をよく観察しないといけませんが、一度覚えさせればその通りに再現してくれる感覚は良いですね。

追記
 LTCの認識は同じ値を送り続けたら解決出来るかもしれません。スタートするまで1フレーム前のデータを繰り返し送り続けるのです。1:00:00.00からスタートするなら0:59:59.29(29.97fps)のデータを送り続けるのです。試すしかありませんが、アクティブな一時停止が実現出来れば手段が広がるように思います。

#器具の製作 #タイムコード
Icon of admin
 パソコンの音声再生アプリにはタイムコードを出す物があるらしい。
 様々なアプリがあるので一概に言えませんが、タイムコードは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の回線をタイムコードで占有しないために2フレーム分の時間を使って送信するようです。
 バイト送信のタイミングはMTCを出す側に依存するとしても、1フレームの時間で8バイト送れればいい。MTCに完全特化してコマンド0xF1を省けば4バイトです。
 4バイトなら1フレームの時間内で40bit送れればよく、最もビットレートが速い30fpsでも1,200bpsあれば事足ります。差動バイフェーズで音声信号化しても問題無しです。
 受信側はバイト受信の度に0xF1を付けた2バイトをMIDIとして送出するだけです。
 この方法は僅かな遅れを生じますが、MTCは2フレーム遅れるのが前提の規格ですし、遅れが一定ならば実用上の問題は無いと考えます。
 分解能が1/12~1/15秒であることもMTCの前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。

 自画自賛ですが悪くないアイデアです。

#器具の製作 #タイムコード 
Icon of admin
 MIDIのビットレートは31,250kbps、8MHzの256分の1です。
 ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
 これならPICのUARTで誤差無しで扱えます。

 送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
 信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。

 凄くシンプルなMTCジェネレーターならすぐ作れそうです。

#タイムコード
Icon of admin
 TRUE1のY分岐とT分岐の試作は繋ぎ目にコーキングを入れて終わりました。
 数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
 求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでOKなら防滴性能があるとしていいでしょう。

#器具の製作
Icon of admin
 秋月電子通商さんからFT232RLが入荷しましたので、Windows11に接続してチェックしてみました。
 ドライバは自動でインストールされますが、ネットからドライバを引っ張ってくるためかCOMとして認識されるまで数分かかります。
 RaspberryPiにシリアルコンソール接続して試してみましょう。

#電子工作 #器具の製作
Icon of admin
 タイムコードの使用にあたり卓(MAdot2)の挙動で重要となるのは次の点です。

・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。

 取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
 注意点が2点あります。

1)CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
2)卓に入力されるタイムコードの有効無効を操作出来なければならない。

 (1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(1曲あたり10分割振りとか)。
 (2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。

 一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな?
 その筋に詳しい音響担当に相談していますのでしばらく待ちです。

 ・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ~。

#タイムコード #器具の製作
Icon of admin
 頭の区切りが付かないので、LTC-Generatorの回路図を描いてみました。
20230511184545-admin.jpg
 FT232RLを使ってPICにUARTを送る
 → PICで所定のbpsの差動バイフェーズ化する
 → PICの出力を分圧して約1vp-p(要は2v)にする
 → オペアンプの1:1ボルテージフォロア回路で音声信号化
 → 出力
 といった簡単な構成です。
 1vなので音声信号としては約+3dBです。
 グランドループさせない様にした方がいのかな?

追記
 気分が乗って描いてしまった基板の3D図も揚げます。
20230512123739-admin.jpg 202305121237391-admin.jpg

 折角なので発注しました。
 本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ~。

#器具の製作 #タイムコード
Icon of admin
 PythonでVLCライブラリを使った音源ファイルの再生は驚くほど簡単。
 インストールするべき諸々や音源モジュールの設定などもありますが、貴兄のサイトにいくらでもあるのでここでは割愛。
 VLCで再生が出来、Python本体とPython-VLCがインストールされていればいいと思います。

 以下、sound.mp3を再生するPythonのコード。

import vlc

if __name__ == '__main__':
 p = vlc.MediaPlayer()   #vlc.MediaPlayerのインスタンスを作成
 p.set_mrl('sound.mp3')  #インスタンスに音源ファイルを関連付け
 p.play()         #再生開始


 こんだけです!
 vlcのインスタンスを宣言し、音源ファイルを設定し、再生を指示するだけ。
 再生はバックグラウンドで行われるので、マルチスレッドを使うことなく再生中に他のことが出来るのも良点。
 ちなみに「p」はインスタンス名なので自由に定義して良いようです。

 Python-VLCはC言語などが使うlibVLCをPythonから呼び出せるようにしているので、libVLCで出来ることの大半が出来るようです。
 以下基本的なAPI。
p.set_mrl('sound.mp3')  #インスタンスに音源ファイルを関連付け
p.play()         #再生開始
p.pause()         #再生中なら一時停止、一時停止中なら再生再開
p.get_time()       #開始からの経過時間を取得(msec.)
p.set_time(1000)     #指定した秒数(msec.)にセット
p.audio_set_volume(100)  #0=mute,100=0dB(パーセント指示だと思っていいみたい)
p.stop()         #停止

 やりたいことはこれだけで済んでしまいそうな気もする。

 python-vlcのドキュメント
 沢山の事が出来るようですが、
 vlc.MediaPlayer
 の項を読むと上記のことがわかります。

#Python
Icon of admin
 オレメモです。
 LTCの差動バイフェーズのクロックをPICで起こす計算です。
 Fosc32MHz(8MHzPLLx4)にすると、Timer1でコンペアモードとするクロックは最速で8MHz。
 1時間は3,600秒。
 8MHzで1時間カウントすると28,800,000.000.カウント。
 1時間あたりの総カウント数をこれに近づける。

 CCPRxH/Lに与える値は次の通り。

● 30fps(2,400bps相当)
 ベース値は1,666.
 3回に2回、1,667.にする。
 (1,666count×2,400bps×2倍周期×3,600秒)
 +(((2,400bps×2倍周期×3,600秒)÷3)×2)
 =28,800,000,000.
 誤差無し

● 29.97fps(30÷1.001fps、約2,397.602bps相当)
 ベース値は1,668.
 3回に1回、1,669.にする。
 (1,668count×2,397.602bps×2倍周期×3,600秒)
 +((2,397.602bps×2倍周期×3,600秒)÷3)+0.25
 =28,800,000,000.004238...
 誤差 004238...
 水晶発振子の精度からして十分だと思う。
 ※ 最後の+0.25は4時間1回+1するって意味。タイムコードは24時間時計なので因数だからいいかな。

● 25fps(2,000bps相当)
 ベース値は2,000.
 (2,000count×2,000bps×2倍周期×3,600秒)
 =28,800,000,000.
 誤差無し

● 24fps(1,920bps相当)
 ベース値は2,083.
 3回に1回、2,084.にする。
 (2,083count×1,920bps×2倍周期×3,600秒)
 +((1,920bps×2倍周期×3,600秒)÷3)
 =28,800,000,000.
 誤差無し

 以前の計算と何か違うのだけど、まぁいいか。

#器具の製作 #タイムコード
Icon of admin
 ダイレクトボックスってのがあります。主に楽器の信号をミキサーで受けやすく変換する装置です。
 メジャーな普及機はBOSS(Roland)のDI-1でしょうか。安価で安定した製品ですが、可も無く不可も無く色気はありません。ダメではないけど物足りなさはあります。BassのLINE取りに使われることが多いように見受けられますが、音が丸くなってしまうというか何というか、当たり障りの無い音になってしまうような気がします。楽器の音は演奏者さんや音響さんの調整、何よりも好みに寄るので絶対値は無いと思いますが、某音響さん曰く「何を繋げてもDI-1の音になっちゃうよね」とのこと。もう少し楽器の個性を引き出せたらいいんじゃないかとか、今どきの高品質な部品を替えたら改善しないのかとか思ったり。
 アナログ音声回路は組み合わせのバランスが重要ですから一部を良い部品に替えれば単純に良くなるモノでもないと思いますが、オペアンプやコンデンサを交換したらどんな変化をするか凄く興味があります。
 DI-1の回路を見ますとオペアンプには4558直系のM5218が使われています。安定したとても良いオペアンプだと思いますが、可もなく不可もなくに徹したちょっと古い製品です。これを高音質とウワサのJRCのMUSES01やMUSES02に替えたらどうなるのだろうと数年前からモヤモヤしてました。MUSESシリーズはコストを度外視し理想を求めて作ったオペアンプらしいですが、オーディオ改造オタク界隈では評価が高く、並みの4558互換品が数十円で買えるところMUSES01は3,500円もします。100倍良い音(?)が出ることはないでしょうが、試したい酔狂な気持ちは抑えられません。
 ただ、DI-1に使われているM5218はSIP8PでMUSESシリーズはDIP8Pです。ピンアサインは同じですが形状は違います。単純に載せ替えは出来ませんので変換基板が必要です。連休明けに時間があったので基板を描いて中華基板に発注してみました。先ほど届いたので取り付け。取り急ぎは手元にあるNJM4580で動作テストをし、MUSES01が入荷したら付け替えてみようと思います。
 個性を持った高品質なダイレクトボックスは沢山ありますので、あえてDI-1を改造することに意味があるのかと問われそうですが、「純粋に興味によるもの」なので。。。
 もしオペアンプの交換で良い変化を得られるなら、INPUTの直下に使われている0.01uFのセラミックコンデンサを高品質な物に替えるのもアリです。実装されているのはベッタベタの普及品ですから、高品質でレスポンスが良いセラミックコンデンサに替えたらどうなるか「興味深々」であります。

#音の世界
Icon of admin
 NJM4580を乗せたDI-1を鳴らしてみました。
 CDプレーヤー → DI-1 → スピーカー(Amp入り)
 こんな感じです。
 音源はVoの無いイージーリスニング向けの物です。

 音はかなり変わりました。私のバカ耳でもわかるのですから間違いなく変わっています。
 あくまで私の感想ですが、高域の分離が良くなりアンサンブルの各楽器の音像が明瞭になりました。無改造の物は高域の分離が弱くそれぞれが糊で貼り付いた印象なので良点だと思われます。半面、中域がかすれてオクに引っ込んだ印象があります。出るところがあれば抑え込まれるところもあるのかな?
 好みの分野ですから絶対値ではありませんが、私の感覚では良くなった印象です。
 ベースは周波数帯域が広く、特にスラッピング奏法では高域の明瞭さが重要だと思いますので、この変化は歓迎する物だと思います。

 今回使っているオペアンプの型番は細かく言うと「NJM4580D」で、4558互換のNJM4558の性能向上品です。安価なミドルレンジとしてはこれ以上望んではいけないほど優秀で、音声回路にもデジタル回路にも使える便利なオペアンプです。世の中のヘッドホンアンプにも多用されているそうで、以前、インカム関係の物に使った際も聞きやすい印象がありました。
 本命の「MUSES01D」はその遥か上を行く品質らしいのでイヤでも期待感が膨らみます。

追記
 約3時間経過。暖まったためか、エージングが進んだためか、中域のカスレが無くなり全域がバランス良く出ます。
 今回の課題はオペアンプを替えると何が違ってくるのかの実験です。違うことは実感できましたが、手間ヒマお金をかけて商売道具に施す価値があるか、オタクの蛇足で終わらせるか、しばらく様子見です。

追記
 約6時間経過しました。時間と共に明瞭感と安定感が増してきました。NJM4580のエージングは8時間前後と聞いたことがありますが、そういうことなんでしょうか。セミアコ、ウッドベース、バンドネオンの音は無改造品に比べ明らかに良くなっています。
 ただ、聴いた瞬間に違いがわかる程ではありませんので、手間ヒマお金をかけて改造するレベルかと聞かれると返答に困ります。本命ではないNJM4580Dでの話ですからMUSES01Dの入荷を待ちましょう。
 オペアンプによって音が違うことは確認出来たので、今日の実験は成功ってことで。

 ちなみに、改造に使っているのは20年以上前の品です。
 ヘタリが出ているので使わせてもらってます。

#音の世界
Icon of admin
 LTC Generator の基板が入荷しました。
 今回はDHLを使ったこともありますが、オーダーしてから6日です。早し。
 送料を見ると発送後2-3日で届く業者の中でDHLが一番安い。今までならDHLが一番高いくらいだったのに不思議。通常使っている日数が倍以上かかる安い業者と比べると3ドルしか違わない。不思議だなと思いつつ、安くて早いならヨシでしょう。数日早いと日程的にリフローの研究をジックリやる時間が取れるので数百円の違いはアリアリです。

 組み立ては他の部品の入荷後ですが、リフローハンダの段取りを玉成することも含めての作業となります。

 PICのファームウェアはもちろん、PC側のプログラムもありますのでしばらくかかりそうです。
 今はFIFOのライブラリを考えています。これがまた簡単そうで難しい。

追記
 秋月さんから部品が発送されたそうです。
 次のオフにリフローの研究をジックリ出来そうです。

#電子工作 #器具の製作 #タイムコード
Icon of admin
 秋月さんから「MUSES01D」が入荷。
 試したいけれど時間が微妙です。
 けど、モヤモヤするのでやりましょう!
 基本動作だけでも確認します。

#音の世界
Icon of admin
 MUSES01Dが入荷したので我慢出来ず実験。
 エージングが済んでいないのにNJM4580Dよりも圧倒的に良い音です。良い音の基準は難しいですが、第一印象は重なって隠れてしまう音が一つも感じられないことです。今まで聞こえなかった音が聴こえるとか、音の向こうの無音まで聴こえてきそうだと書いたら大げさですがそんな感じ。ジャズっぽい音源で試していますが、主旋律は勿論、僅かに入っている伴奏の輪郭や余韻まで明瞭に聴こえ、NJM4580Dではあまり聴こえなかったスネアのブラシにまで存在感があります。粒立ちが良く透明感があるとでも書けばオーディオ評論っぽい?
 いかにもJRCの音なのは否定しませんが、これ以上は自分のバカ耳では評価不能かも。凄いの一言です。ちょっと聴いただけで「良い音ぢゃね!?」と思ってもらえるレベルだと思います。
 バンドモノの現場で楽器を繋いで試してみたいです。ベースはもちろん、キーボードの音も圧倒的に良くなりそうな期待感があります。
 本領発揮には300-350時間のエージングが必要とのこと。本当にここまで必要なのか疑問もありますが、やらないとわかりませんのでエージングを開始。2週間ガンバレ!

 ちなみに、どの比較情報を見ても「OPA627」が群を抜いた高評価。形はMUSES01Dと同じDIP8ピンですが、1回路物なので今の基板では使えません。
 実売価格は1個6,000円もします。DI-1に使うなら2個必要ですが、ここまでになると良質なダイレクトボックスを買った方が良さそうなので止めておきます。
 端っからDI-1の限界に挑戦するつもりは無く、部品代5,000円未満で改善出来るならアリぢゃねってプランですからね。
 予想以上に良い経過を得ているので更に上を試してみたい気持ちは捨てきれませんけどwww

 余談かもしれませんが、amazonや中華電機には刻印を書き換えた偽物が多いらしいのでご注意を。5,000円以下のOPA627は怪しさ満点だし、MUSESシリーズは秋月電子通商以外で買わない方がいいとのこと。真相を確かめる気はありませんので、ナンとも言えないところですけどね。

 オマケとして、今回の基板と外したM5218の記念撮影。
20230518210431-admin.jpg
 aitendoさんに同じ用途の基板がありました。
 0.65-2.54/8P★SIL変換基板(3枚入)
 DI-1の基板並みに太くて真っすぐな配線にグランドシールドが過剰にされている物が欲しかったので私には少し違うのですが、これを使えば同様の改造が可能だと思います。
 aitendoさんのアイデア商品は売り切りで終わりになる事が多いので、興味のある方はお早めに購入されることをお勧めします。
 3枚100円は安い!!

#音の世界 #器具の製作
Icon of admin
 LTC Generator の部品も揃いました。
 次のオフでリフローをやって組んでみます。
 まずはFT232RLをパソコンで認識出来るところまで早々に確認したいです。

#電子工作 #器具の製作 #タイムコード
Icon of admin
 MUSES01Dのエージングを始めて12時間、中域が膨らみました。その影響なのか若干モコモコした印象です。輪郭や余韻が失われたワケではありませんので、高域まで膨らんでくれたらいいのかな。先の書き込みで「いかにもJRC」と表現した感じは薄まっています。

#音の世界
Icon of admin
 丸一日現場でしたので新たなネタはありませんが、エージングの進捗など。
 30時間経過ですが、音が膨らむ周波数帯域が広くなってきました。12時間経過では500-700Hzくらいが膨らんでいましたが、それが上に広がり、今は1kHz近くまで伸びている感じです。特に印象に残ったのはウッドベースのゴリゴリ感が生々しさを増していることです。エージング開始直後のキラキラした感じも良い印象でしたが、今と比べたら青臭くて薄い音だったかもしれません。今は楽器の「香り」がしてきそうです。
 時間の経過と共に明らかに良い方向に変化していますので、300時間とも言われるエージングでどうなっていくのか楽しみです。
 
#音の世界
Icon of admin
 昨日オフでしたが、用事が終わらず趣味の工作は断念。

 現場へ出向く前にエージングの具合いを確認しました。約60時間経過。またしても音が変わっています。
 膨らみが上に伸び、音の質量を感じられるのは良点ですが、どこか歪んでいる印象を受けます。いわゆるオーバーロードで歪んでいるのではなく、倍音の質によって伸びたり詰まったりを繰り返すために歪んでいるように聴こえる印象です。
 全体としては良い方向に変化していると思いますし、ガットギターのソロの曲は特に良くなっていますが、今の状態が落としどころだったら微妙ですね。

追記
 現場から戻ってエージングを確認。70時間経過です。
 奇妙な歪み感は無くなり、高域が伸びてしました。肉厚な色っぽさが出始めたかも。

#音の世界
Icon of admin
 エージングは85時間経過。改めて無改造品と比べてみました。
 ところが、比べる以前に出力が弱くなっています。
 計測はしていませんが、聴感で半分くらい。ケーブル等の接続に異常ありませんし、無改造品に使っているケーブルと差し替えても改善しません。
 何が起こったのでしょう。
 かなり年数を経た機体ですのでエージングの連続運転で寿命が表に出たのか、MUSESはそういうモノなのか、現時点では何とも言えません。
 思い起こせば、昨晩のチェックでも出力が少し小さくなっていたかもしれません。

 そんな作業で気づいたのですが、無改造品の音が良くなっています。この機体はNJM4580Dのエージングの際に比較用として一緒に12時間動かしたものです。
 私のバカ耳基準ですが、DI-1にありがちな高域の詰まりが減っています。総合的にはMUSES01Dの方が良い音ですが、現時点では出力が小さくなっていることもあり、無改造品の音質向上に耳が行ってしまいます。
 無改造品というか純正状態に連続運転というエージングを施すことで音が良くなるならそれに越したことはありませんので、これはこれで経過観察です。

#音の世界
Icon of admin
 エージングについて先達のご意見を拝見すると、対象がプリアンプ、パワーアンプ、スピーカーによっても違いますが、概ね次の様な手順が多い感じがしました。
1)通電して無音状態を維持。
2)負荷に適切なノイズを当てる。
3)音源を通す。
 といった感じです。
 機械の慣らし運転という意味では納得できる手順ですが、悪い言い方をするなら俺様仕様で行うことですから正解があるようで無いのかもしれません。
 ただ間違いないことは、使い始めは時間と共に特性が変化していることです。劣化なのか仕上げなのかは扱う人の考え方次第ですが、特定の手段でその時間を経過させるとその後の安定期が良い状態になるならその方法は得たいものです。

 ここまで音楽を通してきましたが、ロジックな手段ならピンクノイズかなと思い、90時間経過で音源を差し替えてみました。
 途中で交換すると今後の参考にならないような気もするのですが、このまま音楽を通してもダメな気がするのです。

#音の世界
Icon of admin
 PICのファームウェアを書くのは久しぶりなので最新版のMPLABX-IDEをインストールしました。現時点でv6.10です。
 しかし、MPASMが入っていません。アセンブルするためのツールですが、これが無ければアセンブラソースが扱えません。
 こりゃ困った。
 ネットを徘徊したところ、MPASMが入っているのはv5.35までとのこと。v5.40以降はXC8(Cコンパイラ)のアセンブラを使えってことみたいです。

追記
 v5.35をインストールしましたが、MPASMは64bitOSでは使えませんときた。
 アセンブルは実行されるのに警告が出ます。
 今は動いても将来的に問題がありそうなので、XC8のアセンブラを使うことにします。

追記
 MPLABX-IDEはv6.10、XC8はv2.41、アセンブラはXC8のPIC-asにしました。書式が少し違うだけで要領がわかれば簡単です。MPASMをMPLABX-IDEで使っている方なら、細かい設定は先達のサイトを検索して頂けば解決すると思います。
 こちらのサイト「XC8 アセンブラの使い方 1(MPASM 移行)」が参考になりました。
 私が以前のソースを変更したのは次の3点です。
1)ラベル文字列の最後にコロン「:」を付ける。
2)数値書式を変更。
3)ORGで指定していた開始アドレスの指定方法を変更。
 PICの動作は確認していませんが、アセンブルは正常終了しました。
 コンフィゲーションビットの設定はソースコードに記述するのがXC8の流儀みたいです。

#電子工作
Icon of admin
 DI-1の音が小さくなった原因というか対策ですが、7vくらいになっていた9v電池を新品にしたら治りました。
 ファンタム電源で動かしていたので電池は無関係だと思ったのですが・・・。古い機体だから電池の扱いが違うのかな?オペアンプがよくない方向に行ったワケでないことを確認できたのでヨシとしましょう。
 現状の音ですが、DI-1特有の高域がモッサリする感じが無くなり、スッキリと上まで伸びて音像は明瞭ですが、どことなく安っぽい音に感じるかもしれません。高域が良くなった半面、中域が細くなって音の分離が弱くなった印象です。手間ヒマお金をかけて改造するレベルかは微妙。
 300時間として残り200時間。。。。

#音の世界
Icon of admin
 LTC Generator の基板をハンダ付け。
 表面実装部品の取り付けはオーブントースターを用いたリフローです。手順が決まれば簡単です。
 リフローに関する過去記事
20230522221900-admin.jpg 202305222219001-admin.jpg
 当たり前ですが、KiCADで描いた3D図のままです。
 Windows11がCOMとして認識しましたので、Pythonでシリアル通信が出来るハズです。
 この後はPICのファームウェアを書きます。MPLABX-IDEも使えるようにしましたので地道に書いていきます。

 基板に書いた抵抗値が一部間違ってました。
 データは修正しましたが、次の製作では注意が必要です。

#電子工作 #器具の製作 #タイムコード
Icon of admin
 MUSES01Dに換装したDI-1はエージングが110時間ほど経過し安定してきました。昨日の中域が詰まった安っぽい音は解消しています。
 無改造品より良いのですが、手間暇お金をかける程の印象はまだありません。

 良い点を特筆するなら、生ギターの高音弦やハイポジションは圧倒的に良いことです。弦が擦れる音や細い響きに立体感があります。
 ダイレクトボックスの役目は楽器のレベル変換ですし、DI-1の不満点は高域の詰まった感じですから、これはこれで良いのかもしません。

 ただ、並列で音を通している無改造品も日に日に良くなってきている印象があります。
 上記の特筆点では改造品に負けますが、エージングしたら無改造品でもいいんじゃないか!?という予感もしています。

 ちょっと違う分野ですが、次の様なyoutube動画がありました。
「エイジングするとエフェクターの音はどう変わるのか」
 
 MUSES01D化したDI-1はもっと変わります。

#音の世界
Icon of admin
 エージングの仕方を少し変え、これまでは抑えめの信号でしたが、歪まないギリギリのところから3dBくらい下げたレベルのピンクノイズを与えることにしました。
 海外の某メーカーのテクニカルノートにかなり高いレベルの信号を与えてエージングを行うとの記述があったためです。正解は不明ですが、メーカーが言うならやってみるべきです。
 これが功を奏したのかわかりませんが、3時間後にチェックしたところダイナミックレンジが明らかに広がっていました。MUSES01Dはエージングが済むと出力レベルが高めになりダイナミックレンジが広がるとのレポートもありますので、ちょうどそういう変化が起こるタイミングだったのかもしれませんけどね。
 これまでは無改造品に比べ少しだけ良い感じが続いていましたが、改造品が徐々に差を広げ始めています。

#音の世界
Icon of admin
 MUSES01DのDI-1のエージングは135時間経過です。
 劇的ではないものの、時間経過と共に安定感と明瞭感が増しています。無改造品との違いも分かりやすくなってきました。
 今朝感じたことは、アコースティックギターのピックや指が擦れる音が一層明瞭に聴こえてきたことです。そういった音を主張したミキシングではありませんし、パルスに近い音が大きくなったワケでもありませんが、音の向こうの無音が以前より感じられる様になったとでも言えばいいでしょうか。聴こえるということは音が大きくなったかそれを隠す余計な音が無くなったかのどちらかですが、原因は定かでないものの、聴き取り難かった音が明瞭になったことは事実です。
 音作りは好みの世界で、低能率やノイズすら「味」や「色」とされることもありますが、ダイレクトボックスは楽器の音をPAに受け渡す入口ですから正確に次に渡すことが役目だと考えています。正確の意味は演奏者が作った音を足しもせず引きもせずということです。

 どこからの情報かわからないのですが、MUSES01Dのエージングは300~350時間らしいので半分経過です。

 ちなみに無改造品の変化は止まった気がします。そのため改造品と差が開いた印象があるのかもしれません。途中参戦なので少し短いですが、ここまでのエージング時間は約80時間だと思います。
 今後も改造品と共にエージングを続けますが、無改造品のエージングは歪み限界から-3dBのピンクノイズを100時間当てる、としておきましょう。

#音の世界
Icon of admin
 LTC Generator のファームウェアもボチボチ製作開始です。初期設定から整理を始めています。
 まずはPICとプリアンプの確認を兼ねてパルス出力のテストプログラムからでしょうか。これが思惑通りにならないと何も始まりません。
 30fps向けの2,400bpsと25fps向けの2,000bpsです。実際は倍の4,800Hzと4,000Hzのパルス生成です。
 生成にはTMR1をコンペアモードで使います。
 TMR1はタイマと呼ばれるもので、CPUクロックなどをキーにした自動カウンターです。時間の計測に使えます。
 コンペアとはタイマが指定の値になったらタイマの値を初期化しつつフラグを立てる機能です。一定の周期を得られます。
 周期を動的に調整して1時間あたりの総カウント数を出来るだけ正確にしようというのが今回の肝です。

#PIC #器具の製作 #タイムコード
Icon of admin
 オレメモです。
 PICにおいてPORTx,nに対するbit反転方法。
 TMR1のコンペアで割り込みしてPORTの出力を反転すればパルスになりますから、差動バイフェーズで重要です。

; PORTAの3bit目だけ反転させる。
 MOVLW 00001000B  ; Wレジスタにフィルタ値を定義 3bit目だけ1
 XORWF PORTA,SELF  ; PORTAの3bit目だけを反転
 ※ 書式はXC8のPIC-as


 データシート読むとPORTxではなくLATxに対して計算を当てるのがいいらしいのですが、ここではわかりやすさのためにあえてPORT相手です。

 XORの計算は次の通り。
0 xor 0 = 0
0 xor 1 = 1
1 xor 0 = 1
1 xor 1 = 0

 PIC16系にはbit単位の反転命令がありませんので、反転させたいbitだけ1にしたフィルタ値をXORで当てます。
 左の値をPORTの現在値、右の値をフィルタ値とすると、2行目と4行目が反転になり、1行目と3行目は非反転になります。

 論理演算の基本ちゃ基本ですが、案外忘れてしまうのでメモメモ。

 アセンブラに限らずですが、出来るだけ簡単な計算で条件分岐を行うことが大事です。
 例えば処理を10回繰り返すとして、0から加算してカウンタが10になったことを判断するより、10から減算して0になったことを判断する方が好みです。PICのアセンブラの分岐処理は計算結果が0かで扱うのが自然だからです。
; 10回繰り返す
 MOVLW 10      ; COUNTに10を設定する
 MOVWF COUNT     ;
LOOP:
 ~ 10回繰り返す処理をここに書く ~
 DECFSZ COUNT,SELF  ; COUNTをデクリメント(-1)し、結果が0なら次行の処理を飛ばす
 GOTO LOOP      ; LOOPを繰り返す
 ~ 繰り返しの後の処理をここに書く ~

 DECFSZはDECFとBTFSSを組み合わせたマクロ命令みたいなものです。

 少し蛇足ですが、レジスタの現在値が0であるかを見るには、
; レジスタNUMの値は0か?
 MOVF  NUM,SELF  ; 自分自身へ値をコピー
 BTFSC STATUS,ZE  ; 計算結果がゼロかどうかで分岐
 GOTO  NUMisZERO  ; ゼロの場合NUMisZEROへジャンプ(CALLでもいいけど)

 MOVFで自分自身に値をコピーするとSTATUSのゼロフラグ以外変化しないので便利です。
 もちろんWレジスタにコピーしても同じ結果を得られますが、Wレジスタが変化しない方がスッキリまとまることが多いようです。

 てな感じで、PICのアセンブラのリハビリをしています。

#PIC
Icon of admin
 MUSES01DのDI-1のエージングは185時間経過です。
 無改造品は80時間時点から変化はありません。高域の詰まり感が減少して伸びる感じが出ているのでエージングは望ましいと思いますが、この辺りが限界なのかな?
 MUSES01Dの方は高域の明瞭度が更に良くなり、主旋の裏にある細い音が一層聴こえる様になっています。特に無改造品では聴き取れない高域のリバーブ音が存在感を持って聴こえます。無改造品とはすでに別物です。ただ、「シャー」ノイズが耳に付くような気もします。S/Nが悪くなったのではなく、高域が主張されるのに伴って音源からの「シャー」も大きくなったようです。
 良し悪しはともかく、改造によって別物になった意味では現状でもアリだと思いますので、この後はエージングの時間を決めることでしょうか。本番中に音が変わっても困りますからね。変化が落ち着くタイミングを知りたいところです。

#音の世界
Icon of admin
 LTC Generator のアルゴリズムを整理しています。
 これまで別々に考えてきた要素を一つにまとめて確認する作業ですが、潜在しているバグを見つけるのはパズルを解くような感じです。文法の間違えはアセンブラに怒られるのでわかりやすいのですが、アルゴリズムの間違えは自ら見つけないといけないからです。今は設計書の段階ですが、ソースを書く前に出来る限り潰しておきます。
 現地照明の仕事に来ていますが、他社さんのお手伝いですし、仕込み直し以外は楽屋待機なので暇つぶしに丁度よい作業です。

#タイムコード #PIC
Icon of admin
 MUSES01DのDI-1のエージングは230時間経過です。
 先日「シャー」ノイズが増えたと書きましたが、電池の電圧が落ちたことが原因みたいです。電池を交換したところノイズは無くなりました。ファンタム駆動なのに電池の影響を受ける不思議。その他、無改造品とは挙動が違うところがあり、正確な比較が出来ない感じもあります。
 音は良くなったと思います。高域の抜けが良くなり、特に残響音がストンと切れる感じはありません。しかし、一緒にエージングをしてきた無改造品も音質の向上が認められたために費用分の価値があるかというと正直微妙です。
 さて、どうすっかな。。。

#音の世界
Icon of admin
 無改造のDI-1のエージングは150時間を経過しましたが、ここへ来て急に音が良くなってるんですよ。24時間毎に音が変わるので評価がアッチコッチします。
 良いの意味はDI-1特有の高域が尻つぼみする感じがなくなったことです。よくよく比べればMUSES01Dの方が透明感を感じますが、言われなければわからない違いです。実用上はどっちでもいいんじゃね?って感じ。
 MUSES01Dのエージングが300時間ならまだ数日ありますが、DI-1に感じていた問題が解決してしまったなら無理してMUSESD01D化する必要はありません。
 ただ、オペアンプよりもコンデンサの方が音に影響がある可能性もありますので、この辺りも試すつもりです。

#音の世界
Icon of admin
 DI-1の内部電源はDC9vと表記あり。オペアンプの電源端子を実測すると8.3v。
 MUSES01Dの定格電源は±9~±16v。単電源換算なら18~32vですから圧倒的電圧不足ぢゃね?ちなみにM5218やNJM4580Dは±2~±16v(4~32v)なので楽勝。
 エージングをすれば良い方向になると思い込んではいたものの、NJM4580Dに比べて価格差ほど良質なのかと腑に落ちない感じはありました。ひょっとしてコレ?
 MUSES02D、MUSES8820D、MUSES8920Dは±3.5~±16v(7~32v)です。DI-1向けならこれらを選ぶべきぢゃね!?
 MUSES02Dをポチリました。エージングも評価も全部やり直しです。
 MUSES02Dで納得いけば、MUSES02Dの廉価版ながらNJM4580Dより高音質と評判のMUSES8820Dも試してみましょう。安く済むに越したことはありませんので。

 正直なところ、ナゼMUSES01DとMUSES02Dの2種なのかイマイチ理解出来ませんでしたが、電源電圧の違いではないかと思ったところ。
 音質云々以前に、電圧低めの回路にはMUSESD01DではなくMUSES02Dを使うべきです。所定の電圧を突っ込まずに良い音が出るワケありません。
 メーカーの意図は想像の域を越えませんが、基本的な確認を怠ったことは大反省です。部品と販売店さんに謝らないといけません。

 オペアンプの評価はこちらを参考にしました。
 オペアンプの違いによる音質比較表
 ここの評価を真に受けるなら、DI-1にはMUSES02Dではないか!?

#音の世界 #電子工作
Icon of admin
 PICをプログラムするのに開発ツールのMPLABXと書き込み機のPICkitを使っています。
 最新のMPLABXでアセンブラファイルを作ったので書き込みのテストを始めたのですがPICkit4が正常に動かない。認識はされているのに書き込みをすると正常な通信が出来ないとエラーを出します。イロイロ試すものの一向に改善しません。
 こんな時はヴァージョンを落とすのも対策の一つです。原因がMPLABXにあるのかPICkit4にあるのかわかりませんので、開発ツールも書き込み機も世代を落とします。条件はXC8のアセンブラとPICkit3が使えることです。ver5.40、5.45、5.50が該当します。
 ダウンロード済みだったver5.40を試すとアッサリ解決。正常なログが出ました。試行錯誤の6時間はなんだったのでしょう。
 当面、ver5シリーズの最終版であるver5.50を使うことにします。

 PICが正しく動くかのチェックはこれからです。正しく書きこんだ顔をしているのにダメって可能性もあるので安心するのは早いです。
 PICkit4が動かないのは困りますが、こういった開発ツールではヴァージョンアップの過渡期によくあることです。気にしても始まらない。

#PIC
Icon of admin
 MPLABX-IDEv5.50、XC8_pic-as、PICkit3 の組み合わせでPICが動きました。
 今までは古い古いMPLABv8.92を主に使ってきましたが、MPLABXへの引っ越しが終わった感じです。出来るだけ新しいMPLABXを使わないと対応デバイスやら動作クロックの制限があって不便だったのです。
 PICに対して行う要点は同じですが、大事なところが微妙に違うのには難儀しました。特に、プログラムメモリアドレスの指定とコンフィゲエーションビットの設定という超重要項目の設定方法が全く違うのには泣かされました。先達の情報に感謝です。
 TMR1をコンペアモードで動かして所定の基底パルスが出ています。25fps向けの4,000Hzなので折り返しは250usec.です。オシロスコープにしっかりと波形が出ています。

 基本的なところがクリア出来ましたので、試行錯誤で散らかったソースコードを掃除して次のステップです。

追記
 音声信号に変換するプリアンプ回路が思った様になりません。
 アナログは苦手です。

追記
 先達の情報にこんなんがありました。
 単電源でアンバランス-バランス変換 その2
 単電源でオペアンプを使う際の注意点というか基本が読み取れる回路図です。自分は単電源での使い方を間違って覚えているかもしれません。
 試しにブレッドボードで組んでみましょう。
 つか、苦手な要素はテストしてから基板作れよっ・・

追記
 上記のサイトの回路を参考に、プリアンプ回路の修正基板を描いてみました。オペアンプを搭載するDIP8ピンのパターンに被せる基板です。
20230531131752-admin.jpg 20230531132020-admin.jpg
 全てを作り直してもいいのですが、無駄になる物が多いので、すでに入荷済みの基板にはこの手で使おうかなと。聴くものじゃありませんので多少ノイズが出ても支障ありませんし。
 オーダーするのはブレッドボードでのチェックの後にしますケドね。

#PIC #タイムコード
Icon of admin
 MUSES02Dが入荷したので入れ替えてみました。
 率直な感想は素直で良い音なこと。成り行きでエージングした無改造品と比べても明らかです。
 音に迷いがなく自信に満ちている感じ。中域がシッカリしていて余韻も気持ちよく、全域に渡って耳に入ってきます。ネットには「今まで聴こえなかった音に気付きます」との評価がありますが大げさな表現ではありません。
 私個人としては5,000円なら納得の変化ですが、大事なのは商売道具としての価値です。エージングが済んだら音響チームに確認してもらいましょう。

#音の世界
Icon of admin
 LTC Generator のPICのファームウェアを書いています。
 今日の課題は「バイトデータ送出モジュール(補正機能付)」です。信号を出す要の部分でしょうか。
 30fps、29.97fps、25fps、24fpsに対応する予定ですが、それぞれに適したパルス波長を作る部位です。
 1時間単位の計測方法が無いので精度の確認は出来ませんが、オシロスコープで確認する限りは適切なパルス長です。
 データ送信も確認しました。0x00と0xFFを繰り返し送出するテストですが、ちゃんと差動バイフェーズの波形が出ています。そこそこ面倒なアルゴリズムですが一発で動いてしまい嬉しいやら寂しいやら。
 データに応じた波形が出せる状態になったのでファームウェアは一旦お休み。
 この後は、プリアンプの手直し、パソコンからFT232RL経由でデータを送るテストプログラムの作成と続きます。

追記
 そういやFIFOモジュールを書いてない。
 これは先にやっておきましょう。

#PIC #タイムコード

2023年6月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 MUSES02D化したDI-1はとても良い音ですが、どこか物足りない。オペアンプが鳴りきっていないというか躓いているような気がするのです。勘ですが、入口か出口のコンデンサがMUSES02Dに対して性能不足の様に感じます。
 当初はオペアンプの交換に留めようと思ったのですが、コンデンサは安価で元に戻すのも簡単なので試してみようかと。
 別な部品と共にコンデンサも手配しました。

#音の世界
Icon of admin
 気分転換にFIFOを書いてみました。初期設定を含めても50行くらいです。
 ループメモリを非同期で読み書きする構造ですから、それぞれのアドレスカウンタの扱いが肝です。当初悩んだものの、条件を整理すれば案外簡単でした。アルゴリズムの設計大事です。
 こういったモジュールは例外も想定して慎重に動作確認をしなければなりませんが、実機だと確認が難しいのでMPLABXのシュミレータの出番です。ステップ毎のレジスタの変化を観察したいのです。
 MPLABXのシュミレーターは使い方がイマイチわからんのですが、操作メニューが違うだけでやることはv8.92と同じでしょうから、先達の書き込みを参考に探ってみます。

追記
 シュミレーターの使い方は次のサイトがわかりやすい。というか、この通りにやったらシュミレート出来ました。
 MPLAB X の使い方(Simulator編)
 MPLABv8.92とはデザインが違いますが、やっていることは同じなので慣れればいいかなと。PICの中身を知らないと何が何やらですけど・・・
 テスト用に少し書き換えればFIFOの挙動をチェック出来ます。

#PIC
Icon of admin
 FIFOの動作チェックをしました。
 バク無し・・・嬉しいような怖いような。
 FIFOはループメモリです。例えば10個のメモリを使うなら10個目を書いた後は1個目から書きます。これを続けます。読出しも同じ。
 ただ、読出しと書き込みはタイミングがシンクしませんので、読出しが書き込みを追い越さないこと、書き込みは一周以上先行しないことが重要です。これらの確認も出来ました。
 処理のタイミングとしては、読出しはLTCの送出に合わせてになりますが、書き込み(パソコンへのデータ要求とも言う)はメモリが空いたら行います。
 パソコンとの通信速度がLTCの送信速度より十分に速く、パソコン側のレスポンスも十分に早ければタイミングがズレることはありません。たぶん。
 読出しが書き込みに追いついてしまえばデータが無いことになりますので、新しいデータが入るまでLTCを送出しないだけです。

#PIC #タイムコード
Icon of admin
 FIFOなど、諸々書き加えたファームウェアも正常に動きました。
 自分で書いた送出停止処理の扱いを間違えて信号が出ないことに悩んでしまいましたが、テストプログラムが間違っていただけでした。肝心のモジュール本体は一発OKです。
 今回のPICはパソコンから送られてきたデータを淡々と差動バイフェーズで送り出すだけです。難しいことはパソコンでやれと、PICの名前の由来を考えろと。そんな作りです。
 データを差動バイフェーズで送出することは出来た。データのタイミング緩衝となるFIFOもどうやら正常に動く。残るはパソコンとの通信です。FT232RLを経由したシリアル通信ですが、PIC側はDMXで散々やったことですし、パソコン側はPythonなのでほんの数行で書けます。10分の空き時間で進められるものでもありませんけどね。

 あとはラインセレクタも必要です。
 音響さんからもらう本線LTCと自分のパソコンから送るチェック用LTCの2系統を切り替える必要があるからです。
 セレクタにはJRCさんのNJM2750が良さそうです。単電源で動く電子ロータリースイッチってイメージですね。
 NJM2750はアンバランスのLRを4系統から1つ選ぶって構成ですが、バランスのモノ4系統として使っても良さそう。
 今回はそこまで使わないけど、4系統のラインセレクタ基板を作っておけばいいかな?

#PIC #タイムコード #電子工作
Icon of admin
 LTC Generator のプリアンプは回路を手直ししてOKになりました。
 バイアス電圧を当て、反転増幅回路の出力端子とマイナス端子の間の抵抗と並列に20pFのコンデンサを入れて解決しました。
 波形を示さないとわかりにくいのですが、コンデンサを入れる前は妙なノイズが出ていたのです。音声ではなく矩形波ですから周波数特性はそれほど気にしませんが、ノイズというか別波形が足されている状態はいただけない。
 回路修正用の基板も発注したので、プリアンプはとりあえずOKかな。

#PIC #タイムコード
Icon of admin
 LTC Generator のPICはFIFOにデータを突っ込んで波形が出力するまでまとまりました。
 内部のテストルーチンによるものですが、データのリレーはシュミレーターで、波形はオシロスコープで確認出来たので、最も面倒な部分が成立した模様です。
 昨日一見動いたものの波形が安定せず悩みましたが、バグを手直しして今は期待した波形が出ています。0x00や0xFFはもちろん他の数値もOK。オシロスコープのトリガが引っかからず波形が読み取れない数値もありますが、この値が確認出来ればいいでしょうって値はいけたので、デバイスドライバ的なところが終わったと言えます。

 今後の課題はパソコンとの通信です。PIC側は過去実績、パソコン側はライブラリに頼れば左程難しくないハズ・・です。パソコンから受信した値をFIFOに突っ込んで期待した波形が出れば重要な機能は完了です。
 完成に至るには、PICからパソコン側にデータ送信の要求を送ったり、コマンドでfpsのモードを切り替えたりと課題は残っていますが、ハードウェアとデバイスドライバ的な部分がまとまればハードルは低くなります。

 ちなみに、今作っているのはシリアルで受信したバイトデータを差動バイフェーズで出力するだけの物ですから、TASCAMのプレーヤーのリモコンと組み合わせることも可能(正しくは不可能ではない)です。曲ごとのタイムコードをユニークする方法を考えなければなりませんが、これはこれで欲しい一品です。
 当然リモコンはフルスクラッチとなりますが、出来るだけ音響さんの環境を変えないためにこういった発想もありかなと。

#PIC #タイムコード
Icon of admin
 以前から考えていたことですが、MTCのデータを差動バイフェーズで送るのはどうかなと。
 データ構成はLTCよりMTCの方が簡単です。通信インフラはMTC(MIDI)より差動バイフェーズの方が選択肢が多く遠距離でも使えます。双方のいいとこ取りをしたらどうかって発想です。
 LTCに比べMIDIの方がビットレートは速いのですが、MIDIを占拠しないためにMTCのデータレートはLTCより遅いのです。通信媒体を占有するならLTCベースでもMTCを送ることは可能です。
 なぜこうするかいうと、専用の通信インフラを使わず、音響さんに迷惑をかけずに音響回線を借りられたら汎用性が高いと思うからです。LTCは電気的には音声信号相当ですからダンテなどのEtherも通せます。
 差動バイフェーズとUARTの変換は作らねばなりませんが、この変換はタイムコードに限らず他の制御にも使えると思うのです。データレートの制限はありますが、MSCをマイクケーブルで送れたらいいなぁ~なんて妄想してます。

#電子工作
Icon of admin
 LTC Generator の今の課題はPCのPythonからデータを送ってそれに則した差動バイフェーズの波形を出すことです。
 シリアル通信とコマンド処理を書き加えました。シュミレータでは思った通りの挙動をしたので次は実機テストです。
 ですが、この時間なので流石に寝ないといけません。デバグがすんなり終わればいいのですが、夜明けを迎えたら明日に差し障りそうです。
 いささか力尽きましたし、シュミレータでの確認が済んで気分的にも区切りが付いたので今夜は終わりにします。
 明晩、Pythonでシリアル通信して挙動を確認します。思った様に動けばPICのファームウェアは投了です。

#PIC #タイムコード
Icon of admin
 改造したDI-1の主要なコンデンサも変えてみました。音響用として評判が良いニチコンのコンデンサ達です。
 MUSES02Dにしても改善されなかった特定の響きがスッキリと抜ける様になりました。特にガットギターの音源では使い古した弦と新品の弦くらい響きが違います。
 ダイレクトボックスは楽器の音声信号をミキサーに入れるためのレベル変換ですから、演奏者が奏でるニュアンスを出来るだけ正確にミキサーに渡すのが仕事です。この改造の発端はDI-1を通すと正確さに掛けるのではないか?という疑問からです。何を以って正確かというと難しいですが、「DI-1なら弦を新しくしなくてもよかったなぁ~」などと演奏者に言われてしまうならば正確ではないのだろうと思っています。イメージとしては、高域を膨らますというより、響きや余韻を出来るだけ多くミキサーに渡したいといったところです。
 今のところ、圧倒的な変化が起こっている訳ではありませんので売りは弱いですが、繊細な響きや余韻といったDI-1が苦手なところは改善されています。演奏者からすればこの辺りが大事だと思うので良い変化だと考えていますけどね。
 最終判断は、手持ちに無かった物を替えてエージングした後になります。

 新規開発や改造などの話は、モノの良し悪しより「誰が評価したか」が重要です。または、成り行きで使い続け、しばらくして以前の物に戻ってみたら物足りなさや不便を感じて意味を発見する、といった物語が必要です。残念ながら、自分の価値基準でゼロベースの評価をできる人は極めて少数です。ですので、社内でプレゼンすることは労力の無駄かもしれませんw
 誰に試作品を送ろうかな・・・

#音の世界
Icon of admin
 秋月電子通商さんからコンデンサが届きました。お昼休みのお遊びで交換。
 エージングはこれからですが、DI-1の欠点だと思う響きや余韻の鈍さが驚くほど改善されました。ガットギターやアコースティックギターの音が気持ちいい。
 もちろん、ハイ上がりで尖った音ではありません。柔らかくて自然な明瞭さのある音です。

 オレメモですが、以下が交換した部品です。

● オペアンプ
 MUSES02D(変換基板使用)
● コンデンサ
 C1 フィルムコンデンサー 0.01μF50V ルビコンF2D
 C2 オーディオ用無極性電解コンデンサー10μF25V85℃ ニチコンMUSE・ES
 C3 オーディオ用無極性電解コンデンサー10μF25V85℃ ニチコンMUSE・ES
 C5 オーディオ用無極性電解コンデンサー47μF50V85℃ ニチコンMUSE・ES
 C6 オーディオ用無極性電解コンデンサー47μF50V85℃ ニチコンMUSE・ES
 ※ C1~C6は基板上の部品名です。

 送料は除きますが、部品総額3,800円くらいかな?
 変換基板は手前設計の中華製造ですけど。

 C1も無極性電解コンデンサーにするか悩みましたが、ハイインピーダンスのピックアップと直結しますから高レスポンスなフィルムコンデンサーにしました。元々もフィルムコンデンサーです。このフィルムコンデンサーは低ノイズ・高レスポンスなので調光回路に使っても良かった物です。なので手元にあったのですけどw
 今日交換したのはC2とC3です。オペアンプの入力部に使うバイアスフィルタコンデンサですが、コンデンサの中で最も変化が大きかったかもしれません。
 なお、C2とC3は耐圧25v以下の物でないと基板に入りません。C1、C5、C6はファンタム電源に曝される可能性があるので耐圧50vの物でないと壊れると思います。

 MUSES02Dに替えてもイマイチ改善しきれなかった音の響きや余韻が改善しましたので、オペアンプはそのままにコンデンサだけ替えてもいいかもしれません。上記のコンデンサを全部替えても130円ですし、付け替えも普通にハンダゴテが使えれば簡単に出来ます。純アナログの部位なので、良い部品にすれば必ず良い結果になるとは言えないのですけどね。

 憑き物が落ちて肩が軽くなった気分です。

追記
 C2とC3を別なコンデンサにしました。原因は不明ですが、時間経過と共に音に張りが無くなったためです。
 次のコンデンサにしたところ、高域がまろやかで伸びのある音になりました。
 C2 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW
 C3 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW

#音の世界
Icon of admin
 DI-1はバイアスフィルタコンデンサを交換してエージングすること6時間。とりあえずのチェック。
 呆れるほどの明瞭感。ハイ上がりでキャンキャンしているワケではありません。バランス感に疑問はありません。ガットギターは胴の響きを感じ、生ベースはブンブンゴリブリとエグイ鳴りをし、ヴァイオリンは弓が擦れる音まで目の前に見えます。生々しい感じが強調されているので嫌いな人がいるかもしれませんが、ダイレクトボックスではなくエフェクターと考えれば納得!?
 良いとか悪いとかではなく、DI-1とは全くの別物になってしまいました。私は改造品の方が楽器が出している音をダイレクトにミキサーに渡せるような気がしますが、現場で使えんのかな?
 エージングが終わったら布教活動という名の人柱募集でもすっかな。

 そういや、オペアンプはMUSES、コンデンサはMUSEです。
 MUSEとは芸術全般を司るギリシャ神話の女神様だそうな。
 何か名前を付けないとなぁとは思っていましたが、命名にこだわりはありませんので、DI-1MUSEとします。

#音の世界
Icon of admin
 困ったことに LTC Generator が一発で動いてしまいました。デバグのために本業を途中で切り上げ、午前様を覚悟していたのに実作業15分で終わってしまいました。ここまでデバグせずに進んだのは初めてかもしれません。
 何をしたかと言うと、Pythonからシリアルでデータを送り、それに則した波形を出し、コマンドコードで波長を切り替えるというもの。実験用に一部書き換えましたが、どうやっても想定の結果が出ます。
 予想より早いですが、実際にタイムコードを出してみる段階になってしまいました。プリアンプの改修基板は明日入荷なのでいいか。
 仕方ないのでPythonのプログラムの構想を始めましょう。まずは固定値のリストで2-3秒出すところからです。

 そりゃ嬉しいけど、機械たちにスルーされているみたいでなんだか寂しい。
 こんなにすんなりいくと何かありそうで怖い。

#PIC #タイムコード
Icon of admin
 あまりにすんなり動いたので忘れてましたが、FT232RL凄いです、便利です。こんな素晴らしいデバイスをナゼ今まで使わなかったのか自分にクレームです。
 Pythonのシリアルも無茶苦茶簡単、PICのシリアルも設定が少し分かりにくいけど数行のアセンブラで送受信できて簡単。
 先人が作ってくれた素晴らしいシステムたちに感謝です。

#PIC #Python #電子工作
Icon of admin
 今後はLTCをMTCに変換する方法も考えましょう。
 LTCをバイトデータとして受信し、MTCのパケットに書き直して31,250bpsのUARTで送出すればMTCになります。

 オレメモです。 

 PICには「変化割込み」と呼ばれるI/Oピンの入力が変化すると割込みが発生する機能があります。これとタイマーを組み合わせれば波長の計測が可能です。
 PICのクロックを32MHzにした場合、LTCの波長は命令ステップ(Fosc/4)換算でビットが1なら1,666から2,083、0なら倍の3,332から4,166です。誤差10%としても1の最大値(2,291)と0の最小値(3,029)は被りませんしグレーゾーンも広いので、波長の判別はfpsの種類に関係なく可能です。fpsやフォーマットの種類はLTCのデータに書かれているので計測した波長から判断する必要はありません。
 差動バイフェーズのビットは短い波長が2つ続けば1、長い波長が1つで0です。ビットデータが取れたら80bitのシフトレジスタに入れていきます。短い波長は必ず2回続きますから、長い波長の直前の短い波長が奇数回ならエラーとして仕切り直しです。80bitのシフトレジスタの末尾16bitにシンクワードが認められれば正常なLTCパケットが取得できたことになります。
 LTCパケットが取得出来ればMTCパケットを作り、入力されたLTCに基づいたタイミングで31,250bpsに設定したPICのUARTから送出します。後は電気的にMIDIにすればMTCです。
 必ず3フレーム遅れますが、欲しいのは絶対値ではなく相対値ですからいいかなと。

 プログラムが求めるメモリサイズ次第ですが、8pinの12F1822で作る予定です。

追記
 LTCにはfpsフォーマットを記載する領域はありません。訂正します。NDF/DFは記載されます。
 fpsフォーマットをデータに記載するのはMTCです。
 ですので、LTCの場合は波長からfpsフォーマットを推測します。

#PIC #タイムコード
Icon of admin
 DI-1MUSEはコンデンサを替えて24時間経過。
 音が鈍ったというか、明瞭感が弱くなっています。コンデンサを替える前と大差ない印象。
 先行して替えたコンデンサでも24時間経過で一度鈍くなり48時間経過で戻る現象がありました。コンデンサのエージングはそういうものなのかもしれませんが気分は萎えます。

追記
 確実ではないのですが、ピンクノイズを当てた直後は音が鈍るものの、通常の音源を数時間当てると音が戻るようです。通常の音源を3時間くらい当てて再チェックしたところ、昨日のイイ感じに戻っていました。
 この話だけですとピンクノイズは余計なことに感じますが、ピンクノイズを当てて通常音源を当てると明瞭なだけでなくまろやかさも加わりますので、エージングには良いように思います。
 音源100時間、ピンクノイズ100時間、音源100時間の設定で続けています。現在ピンクノイズ30時間。

#音の世界
Icon of admin
 LTC Generator は入荷した修正基板を用いてプリアンプが完成。+4dB(1.23Vp-p)の波形を出しています。
 まだPythonプロンプトのレベルですが、シリアルでデータを送ると波形が変化します。Pythonからデータを送る場合、バイト毎ではなく、配列にバイナリを格納してpyserialに渡すのが良さそうです。
 タイミングが正しいかは確認出来ませんが、PICからの送信要求も受信出来ています。これを受けてデータを送る段取りです。

 本業が詰まっていますのであまり長い時間は出来ませんが、1日0.5課題くらいの気持ちで少しずつ行きましょう。

 明晩は仮のLTCデータを送出するPythonプログラムを書いてみます。
 あらかじめ2-3秒分の配列データを作っておいて送信要求があれば1フレーム分送出する物ですが、卓に接続してLTCがカウントされれば最大の山場を越えます。

#PIC #タイムコード
Icon of admin
 今後のこともあり、移動時間にPICのI2Cを勉強し直してみました。
 これまではイマイチ理解出来なかったのですが、ボチボチ使い方がわかってきました。わからなかったのはハードウェアとソフトウェアの棲み分けとソフトウェアの手順です。
 I2Cの規格を頑張って説明するのはありがたいのですが、一番知りたいソフトウェアの手順がボンヤリした文書ばかり。ちょっと複雑な手順を踏むので突っ込んだ理解が望ましいのはわかるのですが、その説明で力尽きしまうのか、どとのつまりどうすればいいの?に応えてくれる資料が少ないように思います。特に、I2Cの特徴的な要素である「ACK」を扱うのがハードウェアなのかソフトウェアなのかが見えないのです。
 正直、Pythonなどではライブラリを使うだけで済んでしまいますので、いくらPICマイコンでもそこまでローレベルの機構まで理解しないといけないのか不思議です。

 わかったことは、設定さえしてしまえばソフトウェアの手順はUARTと大差ないことです。
 マスタが送信する場合はスレーブアドレスを先頭にしたバイトリストをハードウェアモジュールに渡す(PICではバイト単位で渡す)。
 マスタが受信する場合はスレーブアドレスを送り、返信されたバイトデータを取り込んだら取り込み済みのフラグを立てる。
 スレーブは、自分のアドレスを設定しておけば自分向けの通信かハードウェアが判断してくれるので、マスターの要望に従って受信値を取り込むか返信値を投げる。
 データの終りのストップコンディションは、マスター/スレーブ・送信/受信の立ち位置で違うけどフラグを立てるだけ。
 波形をコマンド操作で作るワケじゃありませんし、前後関係で調整することもありません。規格はザックリ概要がわかっていれば十分なのに、ソフトウェアの手順の説明がボンヤリしているのはイマイチ理解不能なワケです。

#PIC
Icon of admin
 オレメモ

 windows10(11)でDHCPサーバーからIPアドレスを取り直す。
コマンドプロンプト(管理者権限)
> ipconfig /release
> ipconfig /renew


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

#パソコン
Icon of admin
 LTC Generator は24時間カウントの関数をPythonで書いてみました。限りなく本チャンに近いモノです。
 期待通りの動作をします。卓への接続テストはまだですが、オシロスコープには波形が出ます。
 ただ、24時間で約40秒の遅れが出ます。1時間あたり約1.7秒ですから無視出来ません。
 時間のクリックカウントはPICで行っていますが、TMR1のコンペア値が1個多いと仮定すると辻褄が合います。そういえば、TMR2でコンペアと同様の機構と思われるPWMを作る場合は折り返しで1カウント余計にかかるハズ。データシートには記載が見受けられなかったけど、TMR1のコンペアモードでも同様なのかもしれません。
 コンペアの定数値を変更して改めてテストしましょう。

#PIC #タイムコード
Icon of admin
 LTC Player には外付けスイッチが欲しい。
 RaspberryPipicoはUSBキーボードやマウスを簡単に作れるとのこと。
 てことは、picoでキーボードシステムを構築しといてもいい。USBのHIDはもちろん、UART、I2Cなども使える様にしとけば便利だと思われる。チャタリングを含めたセンシングのマトリクスと通信まで作っておくのです。
 picoについて調べてみましょう。

#RaspberryPi
Icon of admin
 LTC Generator のタイマーを修正してみました。
 8時間経過で約1秒ズレていますが、以前より良くなっていますし、SMPTEが求める精度には十分収まっています。何よりも比較に使っている時計の精度がどこまでなのかわかりませんからこんなもんでしょう。
 PICに与えている水晶発振子の精度は30ppmですから(ppmは100万分の1を表す単位なので比率だと0.00003)、1日(86,400秒)あたり±2.592秒の誤差がありえます。実測値は想定される誤差相当なのでソフトウェアは間違ってなさそうです。
 現在値以上を求めるなら、ソフトウェアの修正ではなく個体差に対する補正となりそうですし、もっと精度の高い発振子を使うべき話です。
 補正計算が無い25fpsでテストしていますが、補正計算が入る他のfpsも同等に収まればいいでしょう。

 秋月電子通商さんで手に入る高精度な発振子は最高で1ppmです。高精度に越したことはありませんが、ここまで必要か、これで十分か、30ppmに比べてメリットがあるかは別問題です。
 求めているのは数分間の音楽の時間座標を表す信号です。卓がエラーを出さない条件を満たし、目視でズレを感じない繰り返し精度があればいいのです。高精度の時計や放送用の基準を作っているワケではありませんから、無制限に高精度を求めても意味がありません。十分に使えて低価格も大切な精度です。

#PIC #タイムコード
Icon of admin
 LTC Generator は29.97fpsも25fpsと同等の誤差でした。30fpsと24fpsも同等に収まればPICのファームウェアは完成とします。
 比較に使っている時計はカタログスペックで月差±15秒。1日あたり0.5秒の誤差とみなせます。基準にするには十分でしょう。
 「卓がLTCとして認識するか」を早々に確認したいですね。これが一番重要です。

#タイムコード
Icon of admin
 LTC Generator は24fpsも他のfpsと同様の誤差に収まりました。現在稼働中の30fpsも確認出来れば LTC Generator はヒト段落です。
 本業もそこそこ忙しくなってきたので工作に使える時間は限られますが、LTC Player まで出来るだけ早く到達したいところです。

#PIC #タイムコード
Icon of admin
 RaspberryPi pico はとても面白いマイコンです。少なくとも私好みです。RaspberryPi のブランドですが、RaspberryPi の廉価版、簡易版ではなく、Arduino の親戚と思った方が自然な存在感です。想定される用途、ソースコードを書いてから実行に至るまでの流れが Arduino のそれととても似ています。
 純正の開発・実行環境は MicroPython と呼ばれるシステムですが、MicroPython からの派生品である CircuitPython を使うことで自由度が更に広がるようです。MicroPython がスタンドアロンでの実装を主眼としているなら、CircuitPython はPCなどの周辺機器を作ることを強く意識しているように思います。MicroPython、CircuitPython のどちらもとても良く整備された開発・実行環境だと思いますが、CircuitPythonの方が私の趣向に合っている気がします。実際、CircuitPython の存在を知って pico に興味を持ったのは事実です。
 pico のプロセッサはarm系32bit133MHzです。Arduinoは、高速化高機能化が進んではいますが、基本はAVR系8bitマイコンです。処理能力は pico に格段の優位性があります。その余裕を使って Python を動かしているとも言えますが、C/C++の開発環境を使えば攻めた造りも出来そうな気がします。また、pico は ArduinoIDE と呼ばれる Arduino の開発環境でもコーディング出来るので、Arduino に親しんだ方がシームレスに使えるメリットもあります。ArduinoIDE を用いてこれらのデバイスの開発環境を一本化するのもアリですね。

#RaspberryPi
Icon of admin
 LTC Generator は30fpsも他のfpsと同様の誤差でした。時間の勘定に期待値が出たので PIC のファームウェアは一応の完成とします。あとは、卓が認識するかです。
 今後はPC側のアプリケーションの製作です。Pythonベースでvlcライブラリを使い、LTCとVLCは同時スタートの疑似シンクです。VLCの現在時からLTCを生成することは難しいからです。途中スタートではLTCの現在時からVLCの開始時を補正して合わせる様にします。
 音声ファイルはプレイリストとしてまとめ、スタートタイム、エンドタイム、ボリューム、連続再生、曲間時間などを個別に設定出来る様にします。複数の音声ファイルを並列で再生する用途は想定しませんので、1トラックのわかりやすいモノを目指します。もちろん、LTCのタイムが被らない様にチェックする機能も大切です。

#タイムコード
Icon of admin
 LTC Generator のLTC信号を卓(MA dot2)が認識しました。
 ただ、同じ値を送り続けても認識しません。LTCを入力してから認識するまで1秒弱かかるので、カウントを進めずに信号を認識し続ける方法が欲しいのです。
 試しに数フレームの繰り返しを組んでみたところ認識し、数フレームの繰り返しを一定回数行ってから抜ける様にしたところ期待する結果を得ました。
 最初のCUEポイントのマイナス数フレームの位置で2-3フレームの繰り返し待機をし、トリガが立ったらそれを抜ける考え方で良さそうです。
 ともかく、卓が認識したので一安心です。

#タイムコード
Icon of admin
 オレメモ

 PythonでVLCを使った音楽再生方法を再整理。

 Windows11x64
 Python3.7
 VLC media player ver.3.0.18

 pipでpython-vlcをインストール。
コマンドプロンプト(管理者権限にて)
> pip3 install python-vlc

 pipとはPythonのライブラリを提供してくれるリポジトリのこと。先達に感謝。

 pythonでvlcによる再生。
import vlc

if __name__ == '__main__':
 p = vlc.MediaPlayer()   #vlc.MediaPlayerのインスタンスを作成
 p.set_mrl('sound.mp3')  #インスタンスに音源ファイルを関連付け 相対パスも可能らしいがフルパス指定を推奨
 p.play()         #再生開始

 これだけで音声ファイルが再生されます。

 以下基本的なAPI。
p = vlc.MediaPlayer()       #vlc.MediaPlayerのインスタンスを作成
p.set_mrl('<file_name>')     #インスタンスに音源ファイルを関連付け 相対パスも可能らしいがフルパス指定を推奨 ファイルはVLC media player で扱える物なら何でも。
p.play()             #再生開始 戻り値 0=正常再生/-1=再生出来ない ※ pauseされていれば再生再開
p.is_playing()          #再生中か 戻り値 0=再生していない/1=再生中
p.pause()             #再生中なら一時停止、一時停止中なら再生再開 戻り値無し
p.get_length()          #音源の長さを取得 戻り値 秒数(msec.)
p.get_time()           #音源の最初からの再生位置を取得 戻り値 秒数(msec.)
p.set_time(<msec.>)        #再生再開位置を秒数(msec.)で指定 戻り値無し ※ 再生中やpause()中でないと指定出来ない
p.audio_set_volume(<パーセント>) #0=mute,100=0dB(パーセント指示だと思っていいみたい。100以上も指定可能。)戻り値 0=再生中に設定成功/-1=設定はしたが再生はしていない
p.stop()             #停止 戻り値無し 次回のplay()では最初から始まる
※ 最後まで再生しきっても、stop()をしないと次回のplay()はスタートしない。再生終了で必ずstop()を実行する。
※ 停止中は次の再生開始秒数を指定出来ないので、特定の秒数(msec.)から再生する場合は、play()に続いてset_time(<msec.>)を実行する。ただし、pause()中は指定可能。
p.play()
p.set_time(<msec.>)


 複数の音源ファイルをプレイリストとして扱ってくれるクラスもあるのですが、LTCを作るには少し不便がありそうなため、1曲単位で扱うことにしています。

 vlc.MediaPlayer()のリストを作成する。
p = ( [vlc.MediaPlayer(), vlc.MediaPlayer(), vlc.MediaPlayer()] )
# p[0]、p[1]、p[2] などと使える。

 普通にオフジェクトのリストとして扱える。

 これだけはメモ。
 リストのオブジェクトを追加する。
p.append( vlc.MediaPlayer() )
# 上記に続いた場合は p[3] が追加される


 再生操作のレスポンスはとても良く、タイムラグはほとんど感じない。
 ただ、プレイリスト分のインスタンスを設定するにはメモリに注意かもしれない。

参考
 python-vlcのドキュメント
 ここの「vlc.MediaPlayer」を参照。

#Python
Icon of admin
 python-vlc で音源を流す試験をしました。
 単に再生するだけなら簡単。
 ちょっと難儀したのは再生終了を確定する処理。再生後自動的にリセットされませんので、再生が終了したことを確認して後処理をしないといけません。
 vlc.MediaPlayer.is_playing()は再生中かどうかを把握出来ますが、これだけでは再生が終了したフェーズかわかりません。オレフラグ(下記ではis_playing)を併用して再生前か再生後かを判別します。再生後ならstop()を実行します。きちんとstop()しないともう一度再生が出来ないpython-vlc。
 下記は再生終了を確定する試験として繰り返し再生するモノです。

# -*- coding: utf-8 -*-

import time
import vlc

def play() :
 # 音声ファイルを定義
 play_music = ( [ vlc.MediaPlayer() ] )
 try :
  play_music[0].set_mrl( 'C:/音源.mp3' )
 except :
  return -1
 # 再生ボリューム設定
 play_music[0].audio_set_volume( 60 )
 # フラグ定義
 is_playing = 0  # 再生実行済みフラグ

 # Main Loop
 while True :
  try :
   # 予備睡眠
   time.sleep( 0.0001 )  # Ctl-Cの反応を良くするのに少しsleepを入れるといい
   # 停止中
   if( play_music[0].is_playing() == 0 ) :
    # 未開始で停止中
    if( is_playing == 0 ) :
     play_music[0].play()
     while ( play_music[0].is_playing() == 0 ) : # 再生状態が確定するまで待つ
      time.sleep( 0.001 )
     play_music[0].set_time( 0 )
     is_playing = 1
    # 再生終了で停止中
    else :   # if( is_playing == 1 ) :
     play_music[0].stop()  # 再生終了を宣言してインスタンスをリセットする 主にこれをやりたいがための処理
     is_playing = 0
   # 再生中
   else :
    pass   # 再生中に行う処理は書いていないのでとりあえずpass

  # Ctl-Cで終了
  except KeyboardInterrupt :
   play_music[0].stop()
   break
 return 0

if __name__ == "__main__" :
 play()



 python-vlc便利過ぎ。

追記
 vlc.MediaPlayer.get_length()とvlc.MediaPlayer.get_time()を使って再生が最後まで行ったかチェックしました。
 何曲か試しましたが、概ねlengthの-0.1~-0.2秒で終了しています。vlc.MediaPlayer.get_time()は取得単位の1msecで厳密にカウントされているモノでも無さそうなので表示上の誤差かもしれません。トラック別で音繋がり場合は少し不安がありますが、音のお尻には1-2秒の余白があるのが一般的ですし、そこまで突き詰めるシステムではありませんのでいいかなと。
 画面作りをやって LTC Generator と合わせれば完成が見えてきそうです。
 ウィンドウマネージャーはPython標準のtkinterを使う勉強をしています。書式は違いますが、考え方はHTMLとCSSを使ったweb画面作りに酷似していますので、方言的に翻訳が出来れば何とかなりそうです。ただ、ボタン操作や画面の更新をオブジェクト指向のイベント処理(割り込み)で書くので少し面倒ですし、LTC Generator の制御やvlcの部分はバックグラウンドの常駐処理にしたいのでウィンドウ制御とは別スレッドとなり手間がかかるかも。

#Python #タイムコード
Icon of admin
 DI-1MUSEはコンデンサを交換しました。時間経過と共に音に張りが無くなったためです。
 次のコンデンサにしたところ、いわゆるハイ上がりではなく、まろやかに高域が伸びる音に戻りました。数日エージングしていますが安定しています。
 C2 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW
 C3 オーディオ用電解コンデンサー10μF35V85℃ ニチコンMW
 ただ、無改造品がエージングの効果なのかとても良い音になっています。DI-1独特の高域がモヤっとする感じが弱くなり、MUSEの方がスッキリしているものの、とてもキレイに伸びています。
 MUSE化することで特に生楽器やキーボードのピアノ音源には効果があると予想はしているものの、コストを考えたら無改造品を丁寧に長時間エージングするのがいいのかもしれません。
 そもそもが改造ありきの話ではありません。DI-1の欠点を改善するのが目的で改造は一つの選択肢ですから、別な手段が見えればそれはそれでいいと思います。

#音の世界
Icon of admin
 LTC Generator は卓に繋いで20時間以上正常に連続動作しています。PCとのやりとりの都合で手直しはありますが、基本的な機能はこれで完成とします。
 python-vlcでの音出しも方向性が見えましたので、あと必要な要素はPC上のソフトウェアです。
 Pythonのウィンドウマネージャーはtkinterが一番ベタな選択肢です。Python標準ですから安定性が期待出来ますし、WindowsでもMacOSでもLinuxでも同じソースで動きます。もっと書きやすくデザイン性に優れたウィンドウマネージャーもあるそうですが、何が違うのかよくわからないですし、基本過ぎるモノに慣れれば便利な物も使えるでしょうから、当面はtkinterを勉強してみます。つか、目に見えないところで動作するソフトウェアばかり書いてきたので画面作りは苦手です。

#タイムコード #Python
Icon of admin
 昨日書いたpython-vlcが別なPCでも再生出来るか、mp3以外のフォーマットも再生出来るかチェックしました。
 もちろんVLCで再生する物は問題なく再生出来ますが、VLCのアプリで再生するよりも音の締まりと広がりが良いように聴こえる。。。
 何が違うんでしょう!?

 音源再生アプリ(LTC Player)には一般的な音源プレーヤーにはあまり無い機能を付けます。
1)音源毎に音量設定
2)再生開始点、終了点の設定
3)曲の終わりで止めるか曲続きか。曲続きなら曲間秒数も設定。
4)処理が許せば、指定秒数からの F.I/O も実装。可能ならクロスフェードも実装。
 ダンスイベントですと音源の音量がマチマチですし、前後の無音(白身)がやたら長い物があったりするからです。
 通常は事前に音量と白身を調整して現場に臨むのですが、あったら便利かなと思う機能です。
 あとは、先日も書きましたが、raspberryPi pico を使ってプログラムマブルキーボードを作って外部スイッチにします。

#タイムコード #Python
Icon of admin
 LTC Player を作るのにPythonのGUIライブラリを検討しています。
 Python標準のtkinterも良いと思うのですが少し物足りない感じ。
 マルチプラットホーム対応で無料の条件ですと kivy が良さそうです。出来ることが多すぎて難しそうですが、これは贅沢な悩みです。
 kivyはkv言語と呼ばれるコマンド群を使うことでスタイルシートの様な使い方が出来る様です。Tkinterよりも細かい画面作りが可能ということです。
 何が出来るのか、どこまで出来るのか、どうやったら使えるのかはこれからの勉強です。

追記
 仕事の合間にkivyについて調べてみましたがとても難しい。これで出来ない表現は無いように思える程ですが、ここまで必要か疑問。正直、kivyの学習には時間がかかり過ぎます。
 別なGUIライブラリが無いかと調べたところ「PySimpleGUI」というのがありました。必要な表現が出来るかわかりませんが簡単です。コマンドで画面を描きますが、難易度はFileMakerProの画面描きと大差ない感じです。

#Python
Icon of admin
 LTC Player を試作ってみました。
20230618062945-admin.jpg
 まだまだ途中ですが、ウィンドウの下半分はこんな感じかなと。音源ファイルを選択して再生出来ます。再生、停止などは当たり前ですが、スライダーで再生位置指示と音量を付けてあります。音量は音源に対するものでシステムの音量は変化しません。上半分にはプレイリストを表示する予定です。
 PySimpleGUIはレイアウトの制約が多いのですが、その範囲で並べればいいだけです。自由度を求めるならTkinterやKivyですが、これらはプログラミングが大変過ぎます。PySimpleGUIなら予習2日、製作数時間でここまで出来ました。
 ボタンがフォーカス(押してはいないけど選択された状態)されているとスペースキーで押されたことになるので、フォーカスをボタン類から外すか常にPLAYボタンがフォーカスされた状態にするにはどうするかが課題です。
 キー入力の取得も簡単でした。ウィンドウを表示コマンドにキーイベントを拾うスイッチを加えるだけです。キーボードで押された文字が戻り値に入ります。日本語入力状態には対策が必要です。

追記
 ボタンのフォーカス問題ですが、ダミーボタンを置き、常にこれがフォーカスされる様にしました。
 イベントが発生してPySimpleGUI.Window.read()を抜けたらイの一・無条件にダミーボタンをフォーカスするのです。
 今はボタンしかレイアウトしていませんのでいいですが、強制フォーカスがダメな時には強制フォーカスの実行に条件を付けましょう。

#Python
Icon of admin
 LTC Player はPySimpleGUIの扱い方を探りながらです。Tkinterのラッパーらしいですが、簡単に使える反面制約が多いので、別な意味で難しいところがあります。
 主な制約はウェジット(オブジェクト)の並べ方によって挙動が違うことです。全てではないのですが「ナゼそうなる!?」に出会うことが少なくありません。昨日もExecl的な表示をするTable機能で出くわしてしまい数時間悩んでしまいました。下記の試作品では「Add Music」が今の位置では期待通りの挙動をしますが、表の左隣りでは期待通りに動きません。ウェジットを単独テストしてからレイアウトに入れ込めば期待に反する挙動が起きても並べ方が原因だろうと予想出来ます。
 問題点と言えば問題点ですが、クセといえばそれまでですし、TkinterやKivyに比べて簡単なことは余りある価値です。これで無理な製作は自分はやらないとすればいいでしょう。

 画像は製作途中の物です。パラメータやレイアウトは今後変更していきますが、基本的な機能は実装出来ました。挙動を確認しながら進めていきます。
 一般的な音楽プレーヤーには無い機能を考えています。
 画面でわかりやすいのは「▼ NEXT ▼」です。プレイリストの順番で再生していくのは当然ですが、これにアサインしてからPLAYに行く前提です。曲順が入れ替わっても前の曲が再生している最中に呼び出せます。照明の卓っぽいですねwww。
 あとは、曲間というか次の曲への手順を決めます。曲間が自動停止か続くかはもちろん、次の曲へ渡すまでの秒数を決める様にします。表のNextの列にPauseとあるのは自動停止、秒数らしき数字があるのは曲続きの意味と待ち秒数です。
20230619113316-admin.jpg
 VLCにも少し問題があります。
 スライダーで再生ポジションを表示し変更できる様にしてありますが、スライダーの動作によってはVLCがタイムスタンプのエラーを出します。圧縮が高いmp3の為かもしれませんが原因は不明です。
 止まりはしないのですが、エラー発生の後、テンポやピッチが狂うことがあります。ダンスイベントが主目的ですから本番でポジションスライダーを触ることは無いと思いますが、必要な時にテンポやピッチが狂うのは困ります。
 処理手順の変更でエラーを防止できないか調べることにします。

追記
 ふとアイデアが出て、本業中なのに手を止めて修正www
 VLCのエラーは対策が出来たっぽい。
 かなり面倒な手順ですが、
0)ポジションスライダーのイベント確認
1)再生停止 stop()
2)ポジションスライダーの情報からポジション値を計算
3)再生開始 play()(タイム00:00:00.00からになります)
4)再生確定まで待つ
5)ポジション値をセット
6)操作が一時停止中ならpause()
 といった感じ。
 VLCをリセットし、改めて再生して位置を宣言する手順です。
 コマンドプロンプトにはエラー表示が出ず、テンポやピッチの狂いも起こっていないようです。

追記の2
 mp3ファイルではポジションスライダーの行き来を繰り返すとタイムスタンプがズレることがあります。
 いやーな感じでしたが、wavファイル(非圧縮)だと起こりません。mp3の圧縮方法を知っていると納得出来ますし、wavファイルで問題が無いならいいかなと。

#Python
Icon of admin
 LTC Player はPySimpleGUIとpython-vlcを勉強しながら書いてきたためにソースコードがゴチャゴチャ。
 この先もあるので、変数やインスタンスの名前も手直ししながら大整理をしました。時間がかかりましたが読みやすく手直しもし易くなりました。
 で、そんな整理をすると出てくる出てくる細かいバグ。
 先日、mp3再生中にポジションスライダーを動かすと警告が出て再生速度などがおかしくなることがありましたが、対策はplay()、stop()、pause()を実行した後にis_playing()が望みのフラグを返すまで待つというものです。コレが抜けてる所が数カ所。状況が整っていないのに次の指令が来ることが原因だったようで、再生速度が狂う現象は解消されました。mp3でスライダーを多用すると再生時間のズレが出るのは変わりませんが、wavなら期待通りの動きなのでいいかなと。

 現在の画面。PlayListとNEXTはモックアップです。
20230621223221-admin.jpg

#Python
Icon of admin
 LTC Player はファイルを読み込んでセットリストの編集をするところまで来ました。
 この辺り、かなり面倒です。編集の手順、再生中のLockなど、よく考えないといけません。
 それでも、かなりそれっぽくはなってきました。

#Python
Icon of admin
 このところサーバーを作っていました。設置場所は某劇場の舞台事務所です。
 インターネットにも行けるごく普通の館内LANを使うのですが、館内のフリーwi-fiと元を同じくする回線です。先の設定がどうなっているのかわかりませんが、ネットマスクの桁数から想像するにフリーwi-fiの回線そのものと思われます。無料で使わせてもらえるので贅沢を言ってはいけませんが、接続しているパソコンと共有しているフォルダは絶対に隠さなければなりません。
 となると、必要な通信は通って不必要は通信は遮断するゲートウェイサーバーを構成する必要があります。その他の課題は、ローカルLANをwi-fiにすることです。机の配置の都合でLANケーブルを敷設出来ないからです。
 サーバー機の構成は、機体がジャンクのPC、OSはdebian、データストレージはRAID1にしたHDDを2台とバックアップ用のUSB-HDD、wi-fiのアクセスポイントとしてUSBのwi-fiトングです。マザーボードにはLANコネクタが2個あるので、外向きLANと内向きLANを構成してwi-fiトングは内向きのLANとブリッジします。
 これまでにも近い構成を何度も組んでいますからすんなり終わるだろと思ったら大間違い。このところのdebianはヴァージョンが上がるごとにセキュリティ対策が増え、設定が微増するのは仕方ないとして、旧来のコマンドが使えなくなったり設定の仕方がちょっとだけ変わるのです。私からすればよくわからん方言となりますので調べるのに時間がかかりました。持った通りに組めましたが、思惑より2日間余計にかかって他の仕事がヤバイ。
 おまけというか蛇足ですが、VPNで本社にも繋がる様にしておきました。本社の共有フォルダにアクセス出来れば業務も楽だろうと。

 突っ込んだ話ですが、DHCPサーバー、DNSサーバーとしてdnsmasqを使ってみました。簡易的なモノというイメージがありますが、私が組む小規模サーバーにはisc-dhcp-serverやbind9よりも等身大です。複雑な振り分けやルーティングはしませんので機能は十分ですし何よりも設定が分かりやすい。これらはサーバーを作り始めた当初に難儀したところですからこの使い勝手は感激レベルです。一つ問題を上げるなら、起動後、wi-fiトングと内向きLANとのブリッジが完了する前にdnsmasqが起動すると正常に動作しないので、dnsmasqの起動に待ちを入れる必要があったことです。これを見つけるのに少し時間がかかりました。
 /etc/resolv.conf を dhcpcd に書きかえらない対策が必要なことも気付くのに時間がかかりました。dnsmasq は自分でルートファイルを持たないために設定が簡単ですが、dhcpでアドレスを受け取る際に得たDNSサーバーの情報で /etc/resolv.conf を書き換えてしまうのです。これをされると自分でDNSサーバーを持っている場合に不都合が出るので、/etc/resolv.conf は書き換え不可にしなければならないのです。dnsmasq にも書き換えしない設定があるようですが、何度やっても書き換えられてしまう。ならば、/etc/resolvconf をOSレベルで書き換えられてない様にすればいい。同様の問題を抱えた先達がいましたので有難くパクらせて頂きました。パーミッションを400にするのかと思いきや、パーミッションより上位のフラグがあって、それを設定するのがいいらしい。# chattr +i /etc/resolv.conf とのこと。+i は書き換え不可のフラグを立てるスイッチです。外すなら -i だそうな。
 あと、DHCPクライアントをdhcpcdにしました。RaspberryPiで慣れているのもありますが、旧来の /etc/network/interfaces だけで設定するより何をしてもスムーズ。特にwi-fiトングをアクセスポイントにする hostapd を使うなら dhcpcd 一択と思えるほど快適でした。

 書き始めたらキリがありませんが、都度の感想も書き入れた設定記録を残したので、次の製作では参考にしつつ読んで楽しもうと思います。

 サーバーの設定は server world さんを参考にしています。
 server world
 ここの通りにすればちゃんと動きますので、私はここのレシピで基本設定をしてから好みに変更する様にしています。
 ただし、セキュリティについては別です。基本はフォルダやファイルのパーミッション、ルーティング、IPフィルタリングですが、ここはそうった解説を書かない方針と見受けらえます。それらについては別途勉強しなければなりません。

#サーバー
Icon of admin
 そんなこんなで LTC Player の製作は止まっています。進めたいのですが時間だけでなくアタマの容量も不足してます。
 PysimpleGUI を筆頭にプログラム環境でどこまで出来るかを探りながらなので、自分でもどう仕上がるかわからんという本音もあります。
 最近気づいたのは、sg.FileBrowse() などのボタンとしてレイアウトしなければならない機能は、不可視設定した column に入れ込んでしまえば表示しなくても使えること、ボタンオブジェクトを押したことにする .Click() を使えば他の event から(もちろんメニューからも)読み出せるというものです。PysimpleGUIを使ったことがないとピンとこないことですが、これは PysimpleGUI のレイアウトに自由度を与えてくれます。

追記
 .Bind() を使うと細かいキーボード操作を event として取り込むことが出来るらしい。
 キー操作をプレスにするかリリースにするかを選べるハズです。この辺りも研究課題です。

#Python

2023年7月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 PysimpleGUI は簡単な画面を簡単に作れますが、母体である Tkinter の機能の一部を直接引っ張り出すことで思った以上に細かい作り込みも出来ます。
 もちろん、直接使うのに比べたら出来ることは少ないのですが、少ない学習量と記述量でここまで出来るなら御の字だと思います。主なGUIライブラリは、一つのことをするのに「あっちにコレ」「そっちにソレ」と彼方此方に記述をしなければなりません。細かく言うなら、雛形 class をオーバーライドして自分用の class 定義を延々とやらねばならず、Pythonの書き方としては王道なのでしょうが、簡単なことを簡単に実現するには程遠い感じです。
 何を以って良しとするかは難しいですが、GUI画面製作の入門として PysilmpleGUI がお勧めなのは間違いありません。class ってイマイチわからない、って人も使えると思います。
 もちろん、オブジェクト指向の書き方が出来るプログラム言語で class を使わないのは魅力が半減ですから身に付けるべきですケドね。

 本業が詰まってしまい LTC Player の製作は完全に止まっていますが、合間に勉強を進めていきましょう。

#Python
Icon of admin
 某所に設置したサーバー機の OS は Debian です。
 それ自体が素晴らしいのもありますが、細かい解説を残してくれる先達が多いので、自分がやりたいと思うことはネットを検索すればほとんど解決します。
 samba を用いてのファイル共有はその昔の文字コード問題は全く無くアクセスも速いですね。Windows-Server で共有するのと遜色ありません。
 Wi-fi のアクセスポイントにもしていますが、汎用の USB-Wifi トングで問題ありません。
 VPN(openvpn)で本社のサーバーとも繋げています。ファイルを直接開くのはお勧め出来ないものの、特別なことをせずに本社の共有フォルダにアクセス出来ますから作業性は良いですね。VPNとは拠点間LANとも呼ばれる手法で、疑似的にLANケーブルが繋がっているのと同じ状態を作り上げる手法です。openvpn 以外にDNSサーバーに細工をしてルーティングを施さないといけませんが、要領がわかってしまえば簡単です。

#サーバー
Icon of admin
 PysimpleGUI の使い方が更に見えてきたので LTC Player はそれっぽさが増しています。
 右クリックメニューが便利ですね。ほとんどのウェジットに設定が出来ます。ボタンを配置することなく操作イベントを起こせるので、使用頻度が少ない操作やパソコンに間違って触れても発生させたくない操作には良いようです。問題は「ここには右クリックメニューがあるよ」をどうやって示すかです。隠しコマンドの様なショートカットキーは嫌いなのでその様にはしたくありませんし、「ここにあるよ」を強く主張したらボタンと同じです。強く主張することなく右クリックメニューがあることを示すデザイン手法が欲しいところです。もう少し研究が必要です。

 まだまだα版ですが、「自分が仕事で使うなら欲しい機能」を実装していくのは楽しいですね。
 VLC Media Player にもある機能ですが、スライダーで再生位置を設定したり、カーソルキーで少し戻す・送る機能は便利です。音源を聞きながらのデータ整理では能率が良いですし、リハでは「音の終わりから何秒戻したところから再生したい」とかがよくあるからです。されど本番では絶対に触りたくない機能ですから、右クリックメニューで有効/無効を設定出来る様にもしておくと更にイイ感じです。

#Python
Icon of admin
 LTC Player はいい感じに進んできました。
 PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
 それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ!という正論は聞きませんwww

#Python
Icon of admin
 LTC Player は音源プレーヤー部がほぼ終わり。今後は LTC Generator の制御を組み込んでいきます。
 LTC Generator の制御部はマルチスレッドを使って音楽プレーヤーと分ける必要があると思われます。LTC Generator との通信は最短で33msec(1/30秒)毎に行われますが、PysimpleGUI の sg.window.read() のタイムアウトを25msecにしているためにタイミングが間に合わない可能性があるからです。タイムアウトをもっと早くすれば良さそうなものですが、これ以上早くすると PysimpleGUI にとってよろしくないのです。あちらを立てればこちらが立たず状態ですが、トータルの処理量には無理は無く、あくまでタイミングの問題ですから、マルチスレッドにすればストレス無く動くと思います。
 スレッド間通信には Queue を使えばいいでしょう。共有メモリや Pipe より通信は遅いのですが、List だろうが Tuple だろうがPythonで扱う変数をそのまま扱えるので便利です。通信するデータ量も僅かですから速度が気になることもないでしょう。ちなみに、Queue を送った後にほんの僅かな sleep() を入れると受け側のスレッドが動くまでの時間を短く出来る様です。

#Python
Icon of admin
 EVがエコである条件は、環境負荷が少ないエネルギー源で電力を起こし消費量も少ないことです。製造においても運用においてもです。
 ところが現実は違うようです。電力の大半を火力発電で賄い、運用エネルギーの消費量も少ないとは言えず、製造ではガソリン車よりも多くのエネルギーを必要とするそうな。
 ぶっちゃけ、目の前で排ガスを出さないだけでエコとは呼べないのが今のEVです。給電インフラの不足や電池の原料採掘と廃棄のことまで言い出したらキリがありません。
 まぁ、目の前で排ガスを出さないのはアリっちゃありっちゃありなんですけど。

 そんなこんなの裏で人造石油が注目されています。藻に下水を喰わせて搾り取ったり、炭酸水に原油(種油)を混ぜて培養するなど様々な方法が考案されていますが、人造石油のいいところは大気中の二酸化炭素が原料の一部になること、燃やしても有害物質の発生がとても少ないことなどです。特に硫黄の含有量がほぼゼロなので硫黄酸化物(SOx)の排出が理屈ではゼロです。しかもとても安価に作れるそうな。これは凄いことです。

 欠点があるとするなら主要特許を持っているのが日本だということです。
 日本車潰し(正確には日本のエンジンメーカー潰し)のためのEV化なのに、このままではEVはダメでやっぱり内燃機関でしょとなり燃料まで日本が強くなって本末転倒です。
 次世代燃料、高性能電池、レアメタルレス高性能モーターなどの主要特許を日本がほぼ独占しているのは皮肉でしかありません。

 他者の足を引っ張ることで一番になろうとしても頂点には立てないという道徳の授業かな?

#雑談
Icon of admin
 Pythonでマルチスレッドをする方法を改めて調べていました。
 以前は threading を使いましたが、concurrent.futures が便利っぽい。普通の関数を使うのと大差ない手間で使えます。
 しかもマルチスレッドだけでなくマルチプロセスも扱えます。マルチプロセスでも fork して管理する作業が無く、マルチスレッドとほぼ同じ書き方で使えるので、どちらかで書いておけば後から変更するのも簡単。
 マルチスレッドとマルチプロセスの違いは先達の書き込みが沢山があるので割愛しますが、今回の用途ではマルチスレッドが良さそうです。処理の総量はシングルプロセスでも十分に間に合っているのですが、ウィンドウマネージャーの待ちとシリアル通信の待ちがかみ合わないことへの措置なので軽快なマルチスレッドなワケです。

#Python
Icon of admin
 弊社の音響担当に意見を聞きました。使ってもらうために彼らの慣れに合わせたいと思っているので、私の感覚だけで作りたくないのです。
 こちらのイメージも具体的になってきたのでナルホドねぇ~が連発でしたが、そんな話の中で驚いたのはいわゆる叩きに使えるアプリが少ないという事実。
 世の中には音楽再生アプリが数多ありますので私が作ったアプリを使ってくれるだろうかと思っていましたが、音響さんにとって便利な機能を積極的に取り込めば割り込む余地はありそうです。
 大半の音楽再生アプリはあくまで音楽を聴くことを目的にしているためか操作に対するレスポンスが悪くキッカケ合わせに使うのは難しいのだそうです。私が音源再生のライブラリとして使っているVLCライブラリはレスポンスが良いので不思議です。

 マルチスレッド化を考えていますが、その前にソースコードの整理が必要っぽいです。
 フラグを用いた逐次処理をベタベタの平文で書いていますが、2000行に届こうともなるとインデックスが使えない平文ではエディタを上下スクロールするだけでも面倒ですし、今後の加筆、修正を考えるとこのままではいけないような気がします。
 特に PysimpleGUI の設定が大量なので、せめてこの辺りをC言語で言うところのヘッダーファイル化したいものです。定数や関数をオレ様ライブラリ化するのですが、これが正しい書き方なのでしょう。
 ここまでを試作とし、Python として美しい書式で新たに書いた方がいいのかな?

#Python
Icon of admin
 コロナも明けた感じで繁忙期に入っています。開発・製作をする時間が取りにくくなってきました。
 LTC Player は早く欲しい気持ちはあるものの、近日中に使いたい案件があるワケではありません。1年くらいかけてノンビリ作るつもりです。
 先日も書きましたが、Python らしい様式で書き直そうと思います。マルチスレッドの基本構造を最初から組み入れ、平文ではなく構造化・ライブラリ化(ヘッダーファイル化)を進め、可能な部分は出来るだけクラス化するのです。
 PysimpleGUIも読みやすく手直しがしやすい書き方を検討したいですね。ウェジット一つにも設定項目が多いのでちょっとしたウィンドウ作るだけで膨大なコマンド数になりますが、これを出来るだけ簡素に書きたいのです。他人に読んでもらう気はありませんが、2年後の自分が理解できるようには書きたいかなと。PysimpleGUIは他の製作でも使いたいので、習作というか自分なりのひな形作りも兼ねるつもりです。

 複数のファイルを使って構造的に書いていきますので VSCode を使った方が楽です。RaspberryPi の開発では便利に使っていますが、目的・用途に合わせたセッティングの仕方をオレマニュアルにまとめる必要があります。VSCode は素直で使いやすいエディタだと思うのですが、やれることが多すぎるので最初の段取りをキチンと踏まないと後で困るからです。
 ファイル1枚の短いモノなら秀丸エディタでチョイチョイ書いた方が手っ取り早いのですけど、LTC PLayer はそういう規模ではなくなっています。

#Python
Icon of admin
 Python をスレッドに分ける基準についてオレメモです。

 待ち時間が発生する処理単位をスレッドとして独立化することが基本的な考え方でしょう。デバイスの応答待ちや重い処理の終了待ちがある場合です。この間に何もしなくていいならスレッド化をする必要はありませんが、大概は待ち時間に他の処理を平行して行うことになるからです。
 この様な想定がされる場合は最初からマルチスレッドで書き始めるのが良さそうです。主処理を親スレッドとしてサブルーチン的な子スレッドを定義する手もありますが、親スレッドはスレッド間通信の管理と子スレッドの起動・終了だけを扱うようにするとわかりやすいような気がします。
 スレッド間通信の手段はデータ量や求める速度によりますが Queue を使うのが良さそうです。Tuple で包めばどんな型でもやりとり出来ますし、FIFO スタックなのでスレッド間のタイミング管理が楽です。

 こういった検討する場合、一つのプロセスで処理しきれるかも同時に検討します。OS次第ではありますが、一つのプロセスは一つのCPUスレッドで処理されるのが普通ですから、処理が重い場合はプロセスを分けてCPUスレッドを分散させた方がいいこともあります。ただし、プロセスを分けると子プロセスを起動するのに時間がかかり、プロセス間通信も手続きが煩雑ですので、ハードウェアの能力を余すところなく使えそうなマルチプロセスが必ずしも最良の選択とは言えません。

#Python
Icon of admin
 本業が詰まってしまい工作が進みません。
 困ったような仕方ないような。

 さて、合間に調べモノと妄想はしています。
 課題は PysimpleGUI のウィンドウのサイズを変更しても画面レイアウトを成立させるにはどうするかです。

 まずは基本情報の位置とサイズの取得です。
 位置(左上の角)は sg.window.current_location() を用います。Tupleで(width, height)を取得出来ます。
 ウィンドウサイズを取得するには sg.window.size を用います。Tupleで(width, height)を取得出来ます。ちなみに size の後にカッコは入れません。
 ウェジットのサイズも同様の方法で取得出来ます。
 ただ、PysimpleGUIはウェジットのサイズ指定が文字数/行数単位とピクセル単位が混在していますので、取得したサイズ情報からウェジットのサイズ指定をどのようにするか熟慮しないといけません。

#Python
Icon of admin
 PySimpleGUI にてウィンドウのサイズを取得出来ました。
 これは基本情報です。

 課題は Windows サイズに合わせて Table のカラム幅を自動調整する方法です。
 純正のドキュメントには解決策が無くネットをしばらく徘徊。
 結論から言うと解決したのですが、Tkinter のパラメータを PySimpleGUI から直接操作すると思われるコマンドでカラム幅を直接指定しました。
 Tkinter を知らないので全く理解出来ていませんが、先達の例文にあった定型文を試したところビンゴでした。
 細かい調整は沢山ありますが、根本的なところは解決したので一安心です。

#Python
Icon of admin
 Table のカラム幅の自動調整で少し悩む。
 初期サイズからウィンドウ枠をドラックするサイズ変更を1回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
 ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が1回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
 PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。

 あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
 調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
 フォントの指定も列ごとに出来るといいのですけどね。

#Python
Icon of admin
 まだまだ途中ではあるものの使えるっちゃ使える LTC_Player で本業の音源チェックをしています。
 思いっきり自画自賛ですが、コレ、便利です。
 作った本人だからってのが81%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
 今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。

 私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを1フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー1個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね?とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
 ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。

#Python #PIC
Icon of admin
 バレエ発表会で道具だけ。転換は休憩の時だけなので緩い現場です。

 Python の記述エディタを VSCode に変更しました。
 インストールするべき拡張機能は次の通り。
1)Japanese Language Pack for Visual Studio Code(VSCodeを入れたらまず入れるべき拡張機能)
2)Python Extension Pack(拡張機能が3つ6つ入る。この中のPythonだけでもいいらしいけど、全部入れた方が便利だと思う)
 こんだけでいいならもっと早く使えばよかったなと。

 VSCodeはいいっすね。「オイラ便利だろ!」という主張がほぼ無くサラッと便利。
 軽いし、無駄な装飾は無いし、わかりやすいし、こんなバランスが良くてスマートなツールが microsoft 発祥とは意外だったりして。
 VSCode はお勧めです。

 LTC Player のソースコードを整理しようとしていますが、import した自作ファイルの変数の有効範囲などを改めて確認しています。スマートな記述のためには大事なことです。
 試してシミジミ実感したのですが、出来るだけ class で記述した方が可読性が高いですわ。

#Python
Icon of admin
 オフの今日は LTC Player のソースコードを整理しております。
 出来るだけ class 化しているのですが、慣れれば平文で書くのと大差ありません。書き上がったコードはむしろ読みやすい。VSCodeは折り畳みが出来たり、自分なりにわかりやすいと思えるコメント文を入れているのものありますけどね。
 メインのウィンドウの描画の再現まで完了しましたのでデザインの手直しにかかります。変更というよりは書いていなかったパラメータの追加が主な作業です。
 明日からは山積みの本業に手を付けないといけませんので進むかな?

#Python

2023年8月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 自作のポップアップウィンドウを作っています。
 汎用もあるのですが、ちょっと違うなぁ~って思いまして。

 ウィンドウを表示するだけなら簡単ですが問題は表示位置です。通常はモニタのセンターに表示されますが、ポップアップウィンドウは親ウィンドウの中央に表示したい。
 モニタのサイズ、親ウィンドウの位置やサイズは取得出来ますのでポップアップウィンドウのサイズがわかれば左上の位置は計算で出せますが、

 ・表示するとプログラムから表示位置の変更が出来ない。
 ・表示しないとウィンドウのサイズを得られない。

 といった制約のためナカナカ難しい。

 ならばと閃いたのが、テキトウな位置に表示してサイズを取得してすぐに消し、位置を計算して再表示するというもの。サイズ取得のための表示はタイムアウトを10msecくらいにすれば全く気になりません。
 進捗表示などはメインルーチンで進捗の更新しないといけませんが、関数側で表示まで行い、ウィンドウのステータスをメインルーチンに戻して進捗表示を進めます。処理が終わればメインルーチン側で close() を実行です。ウィンドウのステータスをポインタで返しているんですね。

 ついでに、親ウィンドウがモニタからハミ出した場合にはフルサイズになるようにもしてみました。

#Python
Icon of admin
 PySimpleGUI ですが、ウェジットの更新がかなり重い様子。
 大したことやってないハズなのに重いなぁ~と以前から思っていたのですが、内容が更新されていないウェジットまで毎フレーム書き直しをしていたことが原因でした。進捗の時間表示もありますので毎フレーム書き換えるウェジットはありますが、かといって全部やるこたありません。
 ウェジットをグループに分けて内容が更新された時だけ書き換えを行う様にしたところ劇的に軽くなりました。当然っちゃ当然なんでしょうけど、ナルホドなぁ~ってことでした。フラグを立てまくりですから書き直しは面倒でしたが、これだけ軽くなるなら手間の分の価値はアリです。
 気になってどうしても確認したかったのですが、オカゲで本業が遅れております。これはこれでヤバイ。

#Python
Icon of admin
 LTC Player はかなり良い仕上がりです。機能をもう数種類搭載すれば音楽プレーヤーの部分は終わりかなと。
 主な課題は構造の整理ですが、細かいバグを潰しているためか負荷が減っています。特定の操作をするとファイルのアサインがおかしいバグがあったのですが、これを潰したところタスクマネージャー上の負荷が8%前後から4%前後に半減。余計なコマンドを1行消しただけなんですけど、重要な変数に破綻はさせないけどおかしな値を与えるものでした。プログラムは量じゃないと感じた一瞬ですね。

#Python
Icon of admin
 現場が立ち合いだけだったので LTC Player を書き進めることが出来、音楽プレイヤーとして搭載予定の機能はほぼ入りました。この後は動作確認しつつバグ取りです。
 LTC を送出する LTC Generator の組み込みも考えましょう。LTCが組み込めれば全機能成立です。

#Python
Icon of admin
 Python の VLC ライブラリで mp3 を再生するとタイムオーバーします。長さ30秒の音源が32秒くらいまでカウントされて終わるのです。mp3 はデータの前後関係から復号する圧縮データのためでしょうか。
 再生ポイントがズレてのことかと思いましたがお尻に無音が付くだけの様子。VLCの再生が終了していなくても再生秒数が長さ分になったことで終了と同じ扱いにしました。
 付け焼刃な対策ですが、wav などの非圧縮データでは起こらないことですから、厳密を求めたいなら mp3 などの圧縮データを使わなければいいだけ、、、とします。
 条件を織り交ぜた Play List で一晩連続再生しましたがエラーはありません。今後は頻繁な操作を続ける試験が必要です。

20230807085604-admin.jpg

#Python
Icon of admin
 本業がイイ感じに忙しいのでプログラム作業は思った程進みません。仕方ありませんけど。
 LTC Player は音楽プレーヤー機能が一応組めたので、LTC の送出部を本格的に進めます。

 どういった構造にしましょうかね。
 クラスライブラリの書き方も体に入ってきましたので、本格的なドライバっぽい書き方に挑戦してみようと思います。LTC Generator は LTC Player と別な時間軸で動かさないといけませんのでマルチスレッドを使うことはマストだと思われます。LTC Generator は import する別ファイルとし、LTC Player とやりとりする部分はクラスとして記述し、そのクラスからスレッドを立ち上げてシリアル通信を制御するのです。これならLTC Player からはシンプルな関数にしか見えませんので構造的に美しく如何にもドライバって風味になりますw シリアルポートのリストを得る関数も別枠で作り、LTC Generator のインスタンスを起こす際にシリアルポートを指定するようにすれば複数の LTC Generator を扱えます。実際には音声信号を分ければいいので複数扱う必要はないのですが、ドライバとしてならこうあるベキかもしれません。

#Python
Icon of admin
 LTC のフレーム値の計算で悩む。
 ノンドロップフレームなら簡単ですが、29.97fpsドロップフレームではそうもいきません。実時間とタイムコードの値が合うのは1時間ごと、つまり途中は実時間とズレるのです。タイムコードは映像のフレームに時間形式のナンバリングを与える手法であって実時間を表す物ではありませんので仕方ありません。ズレがあるとしてもフレームナンバーをゼロからカウントするのは何も問題ありませんが、不特定の時間値からカウントされる場合に漠然とした疑問があるワケです。

 困っていても仕方がないので条件を整理しましょう。
 10分単位で考えてみます。
 30fpsなら10分で18,000フレームです。29.97fpsドロップフレームは10分の間に18カウントを落としますので17,982フレームです。フレーム長の伸縮比1.001を掛けますと17,999.92となり、時間差は0.08フレームです。秒に直すと0.0026秒くらいの誤差です。そんなに大きな値ではありませんねぇ。見た目にわかる人は皆無ですからあんまり気にしなくてよくね?
 となると、基準点(時毎もしくは10分毎)からのフレーム数を出し、このフレーム数からタイムコード値を得ればいいんでないか?大げさな感じもしますが、時間値で計算すると奇妙な繰り下がりが発生して計算が面倒だからです。30fpsの24時間分のフレーム数は 2,592,000 ですから32bitの整数でも十分管理出来ます。時間からフレームの枚数目を得る関数とフレームの枚数目から時間を得る関数を作っておけばどうにでもなりそう。
 ここまでやれば、都度の誤差は人が感知出来ないレベルに収まると思います。

#タイムコード
Icon of admin
 次の2つの関数を作成しました。
・時間値をフレーム数に変換
・フレーム数からタイムコード値に変換(30・29.97・25・24fpsNDF、29.97fpsDFをサポート)
 29.97fpsでは±1フレームの誤差が出ますが、他のfpsの様にキリ良く計算出来ないからです。演出機器を動かすなら29.97fps以外を使った方がいいと思います。
 ドロップフレーム(DF)の処理はパズルでした。規則は単純ですが、計算式だけで解を得られない数の置き換えは思った以上に難儀します。
 この後は LTC Player から得られる時間値からタイムコード値を自動でカウントし続けるモジュールを作ります。すでに試作品があるのでそれを参考にします。ここでもDFが面倒な課題となります。

#タイムコード
Icon of admin
 29.97fp-NDF の場合、単位時間あたりのフレーム数は 29.97fps で 勘定は 30fps の NDF と同じです。
 ・・・ってことが頭の中で混乱しました。
 29.97fps-NDF はタイムコードの時間勘定が増えるため値の進みが遅くなります。
 こういった「増えると減る」みたいな関係は挙動の理解がややこしい。

#タイムコード
Icon of admin
 ディナーショーの現場です。
 仕込めてしまえは空き時間多め。

 LTC の時間値を扱う関数を書き上げました。
・msec からフレーム数得る物
・フレーム数から LTC の時間値を得る物
・時間値をインクリメント(+1)する物
・時間値を減算する物
 以上4つです。

 上3つは当たり前でも減算が必要か?って思われるかもしれませんが、卓がLTCを再認識するのに0.5秒くらいかかることへの対策に使います。試したのは MAdot2 ですが、LTCを停止すると認識が落ちますのでLTCを再開してもすぐには動作しません。ファーストCUEが遅れることになるので困ります。ところが2-3フレームを折り返し繰り返せば認識を維持しつつ進行を止めることが出来るのでコノ状態を Pause 処理にしようと思うのです。故に、現在値に対する減算が必要なのです。
 具体的には再開の頭フレームのマイナス1フレームからマイナス3フレームを繰り返して待機状態とします。マイナス何フレームで繰り返すのが適切かは卓に寄って違う可能性がありますので今後検証したいと思います。

 この後は LTC Generator 本体のファームウェアの手直しです。制御コマンドを少し増やしたいかなと。

#タイムコード #Python
Icon of admin
 本業が忙しい。工作が出来ない。哀しい。
 稼がんといけませんので仕方なし。

 こんなとき、ちょっとしたアイデアが出るもの。
 ジャンク品ですが、5Cクラスと思われるBNC同軸ケーブルと2回路の音声ケーブルが1本になっている複合ケーブル(ジープケーブル)が手元にあります。50mが2本と100mが1本です。
 出処は書けませんが、とんでもなく品質の良いケーブルです。もちろん機械強度も高い。
 丈夫で長さがあるので音声回線にDMXを通していましたが、考えてみたら同軸ケーブルにEtherでArt-Net通したらよくね?音声回線にはインカムとLTC通したらよくね?
 今回は「同軸ケーブルが望ましいので積極採用!」ではなく、ジャンクなケーブルを活かすって意味ですから実用域のアダプタが安く手に入ればアリかな?って話です。
 調べてみますと100Mbpsクラスの変換器なら入口出口のセットが1万円くらいで手に入ります。DMXマルチケーブルや屈強なLANケーブルで作ることを考えたら十分に安い。こんなんでもカタログスペックでは数百メートル引き回せるそうですから十分。

 これは試すしかありませんのでポチリました。
 幸い株で稼いだ分で賄えます。このところ株価の動きがアホみたいに大きいので、たまたま波に乗れたら3週間で原資の8%くらい取れました。巧い人は1年で何倍にもするのでしょうが、博才が皆無な私でも4月から月平均6%くらい取れています。どこに預けても増えるどころか実質目減りですから、損切り上等!で波を読むことを楽しんでます。現物なら目減りしても借金を背負うことはありませんから気楽なものです。運が良ければ持ち金が増える課金ゲームですね。昨年はちょっと負けましたが、自分に対する待ちどころがわかり始めた今年は負け分を取り返して小遣いくらいは稼げてます。自分を相手にポーカーをしているような気分ですけど。

#[Art-Net]
Icon of admin
 先週末、LTC Generator の関数を書いてました。モード値とタイムコード値から送信のバイナリを起こす関数です。
 この作業で Python の変数の型である bytes と bytearray の違いようやくわかりました。
 突き詰めたらどちらもバイトデータの羅列ってのが第一条件なんですが、コマンドで数値を処理するなら bytearray にしといた方が楽で、デバイスが送受信で扱うのは最終的に bytes ってだけでした。
 とかく serial、socket を扱うなら bytes と bytearray がわかってないと不便。bytes にしなくても送信は出来るのですが文字コードの悪魔がちょっかいを出してくるので便利機能に頼るにしても自力で bytes まで持っていくつもりで書いた方がいいし、受信はどこまで行っても bytes なので避けて通れません。アセンブラに慣れきってしまった自分にとって「バイナリのデータが読めるとホッコリするよねぇ~」なんです。

#タイムコード #Python
Icon of admin
 同軸ケーブルに Ethernet を通す方法というか規格には「MoCA」(「モカ」と発音?)というのがあるらしい。テレビアンテナからの配線を含め、すでに施工されている同軸ケーブルに Ethernet を通そうという指向みたい。日本語の情報が少ない感じですが、次のサイトが参考になります。
「MoCA 2.5 を使用しTVの同軸ケーブルを使ってLAN構築」
 有益な情報が含まれていますが、ここの情報だけではMoCAの全貌は把握出来ません。諸々理解するには少し時間がかかりそうですが、1000mの配線長でG(ギガ)クラスのネットワークを構築できるという謳い文句は魅力的です。テレビアンテナに使える同軸ケーブルは安価で入手性がいいので尚更です。
 ケーブルには75Ωの同軸ケーブルを用いるそうです。推奨されるケーブルの規格の詳細やグレードは把握できていませんが、すでに施工されているテレビアンテナの配線を利用することも想定してるそうですので最上位グレードのケーブルが求められているワケでもなさそうです。家屋内の商用電源配線にLANを乗せるPLCと似ているとか思ったり。
 MoCAの規格は1.0からあり、小売りで手に入る製品では2.5が今のところ最上位みたいです。表記は「MoCA2.5」です。2.5は世代を表すのではなく、スループットの最大理論値が2.5Gbpsって意味らしいです。
 この名称で検索するとまぁまぁ出てきますので興味のある方は是非調べてみてください。

 具体的な例が見当たらないので人柱をしましょう。amazonに次の製品があったのでポチってみました。先日ポチったのは未出荷だったのでキャンセルです。
「TRENDnet Ethernet Over Coax MoCa 2.5アダプター (2個パック) TMO-312C2K MoCA 2.0/1.1/1.0 RJ-45ギガビットLANポート ネットスループット最大1Gbps対応 最大16ノード対応 ブラック」
 期待値は200mくらいの配線で8ユニバースの Art-Net を実用レベルで通せることです。10baseのLANでも可能な内容ですから、これが通らない様では話になりません。
 イマイチ不明なのは、上記製品の「同ネットワーク内にノードを16個設置出来る」という謳い文句を形にする配線方法です。会場のあちらこちらに安い線材でノードを置けたら便利だろうなぁ~というイメージはありますが、メーカのマニュアルを読んでも構築の具体例が見当たりません。MoCAに関する他の情報を見ますと分波器を使えば分岐出来るようですが、どんな分波器を意味しているのかがわかりません。上記のサイトを読みますと MoCA2.5 の変調周波数は 1,125〜1,675 MHz らしいので、テレビアンテナの分波器でいいなら 2400MHz まで対応する物を使えばいいのかな?とか思いつつも分からんことだらけです。
 入荷には2週間くらいかかるそうです。時間はあるので、空き時間にノンビリと調べを進めましょう。実機が入荷したら1対1接続から始めて分岐の方法も探ってみるつもりです。分波器は中華電機にオーダーしてみました。これも2週間くらいで入荷する見込みです。

 あと、設置済みケーブルのインピーダンスの測定方法は次のサイトが参考になります。同軸ケーブルはインピーダンスが合わないと能率が激落ちするので重要です。50Ωでも通るには通るでしょうが、スループットも信頼性もどうなるのでしょうね。
「特性インピーダンスを測定してみました!」
 測定にはLCRテスターが必須です。一般のご家庭は知りませんが我が家では常備アイテムです。テスターと繋ぐ先バラケーブルと末端をショートするコネクタを作れば既設の埋め込み配線も測定できると思います。

#[Art-Net]
Icon of admin
 同軸ケーブルにEthernetを通すMoCAを調べています。
 分波器と呼ぶべきか分配器と呼ぶべきか、splitterについて参考になったサイトがありました。
「HTEM5 – How do I know if my splitter is MoCA 2.5 compatible?」
 Google先生に翻訳して頂いて読むところ、
1)テレビアンテナ用の分配器を使う。
2)双方向通信が可能な物。<=追加
3)1000MHz以上に対応する物。
4)MoCA対応と刻印のある製品が望ましい。
 てなことが読み取れました。
 さらに、ケーブル配線の条件として、
5)経路中に増幅器(アンテナブースター)が無いこと。
6)メインの分配器からの配線は100ヤード(90メートル)以内にする。
 との記載もありました。
 既設のテレビ回線を利用することが主目的の様ですからその筋の用品が使えるのでしょう。

追記
 分波器の条件には「双方向通信」も必要らしい。アンテナから受信機へ一方通行で繋がるだけの物はダメという意味です。
 この点を明記した製品は少なく判断が難しいので、MoCA対応と謳われている製品を選んだ方が無難っぽい。
 MoCA対応品はMoCA2.0と刻印されている製品が多い様子ですが、MoCA2.0と2.5の違いは同時に通信されるチェンネル数らしいので、MoCA2.0対応品ならMoCA2.5にも使えるような気がします。

#[Art-Net]
Icon of admin
 MoCAに関する情報は youtube にもあります。
 視聴して思ったのですが、海外では家屋の各部屋にテレビを設置することが普通らしく電源コンセント並みに配線されているアンテナ回線を使えたら便利しょ、っといった発想みたいですね。MoCAは既存のアンテナと共存できるそうですから、スマートテレビを使いやすくするという発想も含まれているようです。テレビアンテナの回線にアンテナとインターネットが共存出来るからです。ただし、日本国内では衛星放送の送信周波数とMoCAの変調周波数が被るので注意が必要らしいです。クローズドな使用をすれば問題にならないと思いますケドね。

 今のところは手持ちの複合ケーブルを活かす目的で取り組んでいますが、普通に使えるならDMXの配信の標準にしてもいいのかもしれません。
 屋外のライトアップで効果を発揮しそうな予感もするので、パケージは屋外仕様で考えたいですね。

 ただ、調べを進めるとMoCAの最大ケーブル長は100ヤード(90m)の様な気がします。300m送れるという製品もありますが、逆に見るならMoCAで1000mは無理ともなります。
 事の真相やいかに。

「LINOVISION 同軸LANコンバーター POE対応 電源不要型 1000mまで配線可能 100Mbps最大通信速度 既存の同軸ケーブルでIPカメラ ルーターなどのネットワーク機器を配線可能」
 上記の製品は「EoC(Ethernet over Coaxial cable)」と呼ばれる規格らしくMoCAとは違います。こちらは100Mbpsながら1000m延長出来るとあります。推奨ケーブルはRG59ですが、これは3C-2Vの別名と捉えても支障なし。3Cですから特性インピーダンスは75Ωです。
 100Mbpsあれば8ユニバース以下のArt-Netには十分ですので、ピア・ツー・ピアな用法に限定したコレの方がいいのかもと想ったり。出来る限りの便利を目指すと制限を理解せずに使って「動かない!」とか騒ぐアホが湧きますので、100baseを安価な同軸ケーブルで1000m延長するだけの単機能な器具にするのがいいかもしれません。
 これもポチってみました。人柱をするのにケチなことを言ったらいけません。

#[Art-Net]
Icon of admin
 LTC Player から LTC Generator を制御するモジュールを本格的に書き始めました。
 ハードウェアを作った3ヶ月前の自分が何を考えていたか整理しつつ、bytes と bytearray を用いてシリアル通信の再構築です。
 USB-Serial 変換の FT232RL には LTC Generator であるとマークを埋め込みたいのですが、FT Prog では書き換わっていても、Python で読むとシリアルナンバーくらいしか書き換えが反映しません。排他処理が出来ればいいのでコレでもいいのですが腑に落ちません。

#タイムコード #Python
Icon of admin
 EoC のアダプタが入荷しました。翌日お届け恐ろしい。
 まずはパソコンで試していますがネットワークが普通に繋がります。
 購入品は次の2品。
● EoC トランスミッタ&レシーバ
「LINOVISION 同軸LANコンバーター POE対応 電源不要型 1000mまで配線可能 100Mbps最大通信速度 既存の同軸ケーブルでIPカメラ ルーターなどのネットワーク機器を配線可能」
● PoE インジェクター(普通の Ethernet を PoE にする電源アダプタみたいな物)
「REVOTECH ギガビット PoE インジェクター アダプター、IEEE 802.3af/at パッシブ PoE+ 、PoE 48V 0.5A 出力電力、10/100/1000Mbps ギガビット速度、IP カメラ/AP/PTZ/テレビ電話用、プラグ アンド プレイ (D05A-G)」
 主ケーブルはカナレさんの A2V1B の 50mです。3C相当の同軸回線×1、平衡音声回線×2の複合ケーブルです。

 接続は次の通り。

 [パソコン]
  ↓ Cat5e
 [PoEインジェクタ] ← <AC100v>
  ↓ Cat5e
 [EoCレシーバ]
  ↓ A2V1B(3C相当)
 [EoCトランスミッタ]
  ↓ Cat5e
 [Ethernetハブ]
  ↓ Cat5e
 [LAN]

 といった具合です。
 EoCトランスミッタには同軸ケーブルから電源共有されますのでPoEインジェクタは不要です。
 EoCのレシーバとトランスミッタの違いは電源を供給するデバイスがレシーバってだけみたいです、データに方向性は無く、途中に同軸ケーブルが挟まったLANケーブルと見なして良さそうです。
 BNRで計測するとキッチリ100Mbps出ています。今時からすれば速くはありませんがArt-Netには十分な速度ですし、いわゆるLANケーブルの制限長は100mなので、最大ケーブル長1000mには魅力があります。

#[Art-Net]
Icon of admin
 EoCは割り切った仕様で好みです。
 ただ、youtubeの視聴でテストをしていたのですが一度だけ通信が落ちていたことがあります。 原因はわかりませんが、十分に検証する必要はありそうです。
 原因はEoC、LAN、インターネット、パソコン、youtubeなどの構成するすべてとその組み合わせにまで可能性あるだけに絞り込むのは困難でしょう。何かに問題があっても実用レベルで動けばいいのですけどね。そもそも、即応性は二の次として開発されたEthernetでライブ制御をするのですから潜在的な問題だと思いますが・・・。
 現時点ではパソコンをインターネットに接続する試験でしたので、卓からのArt-Netでノードを動かす試験をします。パソコンがインターネットに繋がるなら動くと思いますケド。

 現時点のコストですが、設備用の5C-FBが19,800円/100m、カナレさんのA2V1Bが59,800円/100m、カナレさんのDMX203が19,800円/100mです。
 100mbpsでArt-Netを通せるなら実用域は8ユニバース以上です。何を基準に評価するかですが、仮に4ユニバースとして、DMX203を4本に対しArt-Net&EoCシステム、同軸ケーブルのコストを比較すると若干EoCに分があります。
 コストに大差がなく配線長に優位性があるならEoCを研究する価値があるように思います。

#[Art-Net]
Icon of admin
 EoCの試験の続きでArt-Netを通してみました。全く問題なく動きます。繋いだだけで動いたので試行錯誤は無し。
 接続は次の通りです。配線が汚いのはテストなのでご勘弁を。

20230823104137-admin.jpg

 [MAdot2]
  ↓ Cat5e
 [Ethernetハブ]
  ↓ Cat5e
 [PoEインジェクタ] ← <AC100v>
  ↓ Cat5e(PoEとして電源供給線も兼ねるので細いケーブルは非推奨)
 [EoCレシーバ]
  ↓ A2V1B(3C相当) 50m
 [EoCトランスミッタ]
  ↓ Cat5e
 [Ethernetハブ]
  ↓ Cat5e
 [Art-Net Node]
  ↓ XLR 5P
 [DoctorMA]
  ↓ USB2.0
 [パソコン]

 エフェクトエンジンのデータで半日くらい様子を見てみます。

 トランスミッタとレシーバは逆にしても動きます。
 DMXのモニターにはDoctorMXを使っていますが、信号の遅れなのかDoccorMXの遅れなのか、ほんのわずかに遅れを感じるかもしれません。

 しばらく先になりますが、現場で使えるパッケージも考えないといけません。これらを毎回組んでいたら面倒ですからね。
 箱の中にそれぞれの用品を固定し、パネルに取り口を付けようと思います。これにUPSやインカムのパワーサプライも同居させたら便利かなと。
 EoCのレシーバとトランスミッタはそこそこ熱を持つのでパッケージにおいては冷却を考慮した方がいいですね。こうったバラバラの物をパッケージする際はベース板を合板にした方が楽ですが、底板をアルミにした筐体放熱も検討の余地ありです。

#[Art-Net]
Icon of admin
 初期構成の段階ですが、LTC Player & LTC Generator の融合が出来ました。
 PLAYボタンを押すと曲と共に LTC がカウントされ、卓(MAdot2)が認識します。まだまだ課題と見えない問題は多いと思いますが、峠を越えた心持ちです。
 処理負荷はWindows7世代のミドルレンジパソコンで20%前後です。まぁまぁでしょう。

 ここ2日間はEoCとコレばっかりやっていたので本業がヤバイですけど、祝杯を上げてもいいかもしれません。
 この後は考えをまとめて構造を整理します。

#タイムコード #Python
Icon of admin
 LTC Player & LTC Generator を α版 から β版 に昇格しました。主要な機能が搭載されたって意味です。
 プレイリストの保存やバグ潰し、細かい調整はこれからですが、音の再生に沿った LTC が出力され、それを拾って卓が動きます。音のポジションを飛ばしてもそれに沿った LTC が出ます。フレーム値が飛んだ時の挙動は卓次第ですが、一時停止も先送りもしなければとても素直に動きます。何度再生しても同じ結果が出ます。そうでないと困るのですが、これぞ期待した機能であります。
 ただしmp3などの圧縮データではパソコンによって再生のクセが違い、音アタマとオシリの挙動が一定しません。メロディ続きでトラックが分かれている音源では問題になりそうです。圧縮データだからでしょうが、VLC のライブラリに頼り切っている私にはどうすることも出来ません。非圧縮のデータ形式の wav では正常なので音源のデータ形式を制限した方がいいですね。Windowsならwav、MacintoshならAIFFってことです。
 なんでかんで5,000行もあるソースコードになりました。本業を後回しに書いていたのは間を空けると細かいことを忘れてしまうからです。自分なりに読みやすく書きましたので正常に動くところまでやっておけば読み返して戻ることも出来ますが、障害を残したまま間を空けると次の作業で障害を思い出すのに時間がかかるのです。
 一応の区切りが付きましたので、一旦お休みというか本業にアタマを戻してプレイリストの保存方法などを検討していこうと思います。

#タイムコード #Python
Icon of admin
 とある中堅企業さんの労働組合さんの納涼祭でした。お盆もとうに過ぎているのに納涼祭?とか思ったりしますが、中堅の工場はお盆前後が忙しいので時期をずらすのはアリアリでしょう。勤務日数が少ない8月を乗り切ったぞー!ってヤツも含まれていそうです。
 そんな現場でしたが、MAdot2 を使ったので LTC Player のランニングテストも同時に実施。本番でこんなことをするのは不謹慎ちゃ不謹慎ですが、LTC が途切れることなく受信されるかを確認するには丁度よい。普段なら卓をずっと眺めていることは難しいですが、目の前の卓を操作するのが仕事なら無理はありません。LTC で卓を動かすのでははく長時間の認識のテストですから時計を表示するのと同じ。LTC のデータが間違っていたり途切れたりして卓が止まることはまずありません。なんでかんで MA の製品ですから。
 8時間ほど実施しましたが問題は発生セズ。バグではなく設計(デザイン)のミスを見つけたので今後対策しますが、音源に沿った LTC で止まることなく卓がカウントを刻むのは気持ちがイイ。
 プレイリストの保存機能も構成しなければなりませんし、修正もまだまだありますが、間違いなく β版 に昇格しています。この達成感と安堵感は暑さという調味料以上にビールを美味しくしてくれています。オタク冥利とはこのことでしょうか。

#タイムコード #Python
Icon of admin
 今回の LTC Player と LTC Generator のパソコン側のシステムは全て Python で書いています。
 その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとC言語でやってきたこともC++にしてみたくなる。時間と脳味噌に空きが無くて1年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、C++で書いたらスマートに書けそうな気がしてきています。
 C++と言っても ANSI の C言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の C言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
 ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。C言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。

#C言語
Icon of admin
 LTC Player はセットリストの保存以外は完成した様子です。0.2.0βとしました。
 バグや設計ミスはあると思うのですが、これ以上は使ってみないと分からないような気がします。
 LTCについて、MAdot2の場合ですが、無信号から受信開始まで0.3-0.5秒かることへの対策として停止タイムの数フレーム前を数フレームリピートしていますが、他の卓の挙動の検証も必要です。

#タイムコード #Python
Icon of admin
 DMX Delay を発見!(知人に教えてもらいました)
 DMXdelayer (alpha version)

 同じことに取り組んでいる方がいらっしゃることが何より嬉しいです。

#Art-Net
Icon of admin
 LTC Player は「オイラ、最初からこうだよ」と言わんばかりの顔で動いています。嬉しいようなちょっとムカつくような。

#タイムコード #Python
Icon of admin
 Python でファイル保存するには次の方法がお手軽みたい。
「pythonでlistをファイルに保存し、読み込む方法(numpyも同様!)」
 上記内の「pickleを使用する方法(おすすめ!)」です。
 ここでは list を保存する方法として書かれていますが tuple でもOK。もちろん、list や dict を含む異なる型をテキトウに突っ込んだ tuple でもOK。Python で一つの変数として扱える状態にしてから pickle.dump でファイルに入れれば何でもいいみたい。読出しは load すれば pickle.dump する直前の状態で変数に格納されます。変数のまんま保存し変数のまんま読み出せるイメージです。
 やりたいことは list 型のセットリストと諸々のステータスの保存/読出しです。これらを tuple にまとめれば一括で扱えるみたいです。
 ファイル保存は手続きが面倒ってイメージがありましたが、これは楽チンです。

 追加オレメモ。
「Pythonでファイル、ディレクトリ(フォルダ)の存在確認」
「Pythonでディレクトリ(フォルダ)を作成するmkdir, makedirs」
「Python ファイルのコピーと移動」
 こういった基本的なことが凄く簡単なのは Python のすばらしさ。
 この様な操作を整理しているのは、データを他のパソコンに持って行く前提で、音源ファイルをセットリストファイルと同じフォルダに置きたいからです。

 pyinstaller を使って実行ファイル化(.exe化)してみました。この状態にすると Python をインストールしていないパソコンでも動きます。操作は簡単ですし中身を隠せていいかも。
 モノは試しにアップしてみました。Windows11の64bitでしか試していませんが、64bitならWindows10でも動くと思われます。
 LtcPlayer
 セットリストの保存機能が未実装のβ版です。モノ好き大好き自己責任でお楽しみください。
 LTC の出力には専用インターフェースが必要です。これが無ければ単なる音楽プレーヤーです。
 専用インターフェースのことを LTC Generator と呼んでいますが販売するかは検討中です。ノンクレーム返品可で少数販売でしょうか?手作りなので数を作れませんしサポートしきれませんし。

#タイムコード #Python
Icon of admin
 実行ファイル化した LTC Player 0.2.0β の処理負荷は5~7%です。十分に軽いと言えます。
 しばらくは本業を頑張らないといけませんが、その本業で使って細かいバグを見つけていきましょう。

#タイムコード #Python
Icon of admin
 今「人工石油」が注目されています。
 簡単に安く短時間で灯油や軽油とほぼ同質の油を作る技術です。

 この映像の3'40"くらいから細かい説明がありますが、これは面白い製造方法です。
 結合が強い二酸化炭素を分解するって発想がまず凄い。

#雑談

2023年9月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 pyinstaller でexeファイルを作ってみましたが環境によって微妙な不具合が出ます。原因は不明ですが、pyinstaller の操作手順かもしれません。
「PyinstallerでPythonプログラムをexe化する手順書(Windows編)」
 上記を参考に作った exeファイルは自分の環境では問題なく動いたのですが、ここに一工夫加えてみようと思います。
 仮想環境での実行が推奨されていますが、pyinstaller 自体も仮想環境にインストールするべきなのかもしれません。別の先達情報にはその様に書かれている物があります。
「PyInstallerを使ってみた」

追記
 作業手順のオレメモ。
 仮想環境に pyinstaller を入れての実行の方が良いようです。
作業ディレクトリに移動
> cd <作業ディレクトリ>
pipenv をインストール
> pip install pipenv
pipenv で使う python のバージョンを指定
> pipenv --python 3.9
pipenv(仮想環境)を開始
> pipenv shell
仮想環境にpyinstaller をインストール
> pipenv install -d pyinstaller
必要なライブラリをインストール
> pipenv install pyserial
> pipenv install PySimpleGUI
> pipenv install python-vlc
・・・etc
ビルドする
> pyinstaller ltcplayer.py --clean --noconcole --onefile
・・・数分で終わる。
作業ディレクトリ内の distフォルダ内 に ltcplayer.exe が出来ている。

終了なら仮想環境のshellから抜ける
> exit
仮想環境を削除
> pipenv --rm

作業ディレクトリは Python のソースコードがある階層でもいいのだけれど、
ゴチャゴチャするので私は一つ下の階層で作業をしています。
ソースコードがある階層で
> mkdir env
> cd env
> pyinstaller ..\ltcplayer.py --clean --noconcole --onefile
相対パスでソースコードを一つ上の階層として呼びます。
お好みですけど。


#Python #タイムコード
Icon of admin
 VLC が入っていて Python を入れていないパソコンが一台あったので exeファイルを試してみました。
 問題なく動きます。
 python-vlc は VLC を入れていなくても動くハズですが、入れておいた方がいいのかもしれません。

 VLC をアンインストールして試す手もありますが、DLL などが残る可能性もあるので、一度 VLC に触れたパソコンはインストール済みと思うしかありません。
 いずれにしても、VLC のインストールを推奨することにしましょう。
「VLC media player」
 とても便利なアプリです。特にこだわりがなければ、デフォルトアプリとしてもお勧めする一品です。

#Python #タイムコード
Icon of admin
 ボーダーケーブルを修理しています。
 シースを剥いてバラになった芯線をカバーするチューブが酷い状態になっています。チューブが縮んだのか芯線がシースから出てしまったのか七分丈になっています。これにビニテを巻いて誤魔化していたのですから困りものです。これは機能を失っている故障ですから要修理品だと思って欲しいなぁ~。
 取り急ぎなのでホームセンターを徘徊しましたがよさそうなビニールチューブがありました。
「三洋化成 特殊耐寒チューブ T-12」
 カタログスペックを読む限り環境耐性は良いと思われます。溶けるギリギリまで加熱しましたが寸法の変化は見受けられません。ビニル製品は熱、紫外線、水気を受けると形状がゆっくり変化していきますので数年経過を見ないとわかりませんが、安価なビニールチューブより期待出来そうです。
 ビニールチューブの固定方法ですが、被覆付き針金を巻き付けて本体ケーブルのシースと繋げてみました。電気工事のバインド線処理やカムロックコネクタの組み立て方法などをヒントにしています。ビニテやロックタイで巻くだけより長持ちしそうな気がします。
 一番の問題は作業時間です。バラして組み直すのに1本あたり2時間強かかります。安全のためにやらねばなりませんがかかりますねぇ。

#照明器具
Icon of admin
 LtcPlayer 0.2.2βです。
 細かいバグを修正しました。
「VLC media player」のインストールを推奨します。入れなくても動きますが、入れた方がいいみたい。

#タイムコード
Icon of admin
 なんとなーくネットを眺めていたところ「Open DMX USB」に目が止まる。
「Open USB USB」
 PCから DMX512 を出力する USB インターフェースです。仕様がオープンになっていてハードウェアは極めてシンプルです。FT232RL を用います。
 ライセンス仕様は GPLv2 です。大雑把に言うなら、改変しない限り商用/私用を問わず自由に使えます。
 FT232RL は LTC Generator でも使っているので、その延長線で使えるなら悪くないなぁ~と。

 このところ JASCII のオフライン打ち込みソフトのリクエストがあります。もちろん、ASCII や Comos-Text との変換を含めてです。
 正直言うと面倒臭い。有料にするとライセンスの管理やサポートが面倒だし、無料にすると空振り感が強い。プロでない私がコレを開発するには本業を1/3にして半年かかります。卓を持ち込めば済むことに掛ける手間ではありません。
 ですが、JASCII 関係は解決したいなぁ~って気持ちはあります。最近は、劇場間でデータを使いまわすためではなく、事前の空打ちが目的になっているからです。有志がお作りになったオフラインソフトもありますが、操作感に照明を作るリズム感がありません。テンキー操作でバンバン打ち込めるシステムがあってもいいのかなとは思います。
 もし作るなら、JASCIIベースでプレイバックも出来る様にしてPC卓にしてもいいのかなと。DoctorMX や Open DMX USB で DMX512 を出せばいいのです。

 イロイロ想うことはあるので、システムの構成だけでも考えていいのかなと。

#ガチ工作 #照明器具
Icon of admin
 「Open DMX USB」について考えていたのは移動中アタマが空いていたからです。
 学園祭への機材レンタルで搬送をしていたのですが、片道1時間半くらいかかるので考え事をするには丁度良い時間でした。

 そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
 ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。

 年齢が年齢なので経験量に対し学習量が少ないなぁ~と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
 厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。

 目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
 開発のプロからしたら当たり前過ぎることなんでしょうけど。

#[Art-Net] #C言語 #器具の製作
Icon of admin
 FT232RLで一般的なシリアル通信以外のことをするにはドライバを直接叩かないといけないらしい。250kbps 送信と長い長い BreakTime を生成するには OS のシリアルを叩いても不可能ですからね。
 FT232RL のメーカーである FTDI のサイトに D2XX Programmer’s Guide がありました。これが理解出来ればいいのでしょうが全く理解出来ません。

 Open DMX USB の Python ライブラリが落ちていました。これなら理解できます。
「PyFtdi」
 次の使用例はとてもわかりやすい。
「jlbrogdon/dmx_controller」
 細かい例外対策まで仕上げるには PyFtdi の API documentation を熟読しなければなりませんが、本丸が見えればナンとかなりそうな気分になります。
 PyFtdi の世代の問題なのか、少し手直しをしないとエラーになります。
 ・・・注意:READMEを読み返したらコレは RaspberryPi 向けに書いたモノだとか。動かなくても不思議はありません。

 Open DMX USB の回路図はこちらがわかりやすい。
「菅工房 Open DMX USB」

 汎用の FT232RL 基板を使うならここが参考になります。
「Open DMX USB コントローラによる DMX512制御」
 汎用の FT232RL にほんの少し設定を加えるだけで Open DMX UASB として使えます。FT232RL の電気特性は UART なので RS485 に変換する必要はあります。

 忘れちゃいけない本家。
「ENTTEC Open DMX USB」
「D2XX Programmer's Guide」

 習作ですので急ぐつもりはありませんしアイデアだけで終わるかもしれませんが、Open DMX USB を扱えたら応用の幅がありそうな予感はあります。テンキーでガツガツ打てて、MIDI でクロスフェーダーやサブマスターまで組めたらいいかなと。
 ホール卓のPC版ってのもネタとして面白いかも。「KOYATAKU」とでも名付けます?。ホール卓の基本構成をパソコンで構成してフリーウェアにしたらメーカーさんに嫌がられるでしょうけど、10年間違いなく動くのがメーカーさんのクウォリティであって、ここを真似するのは絶対不可能な領域です。

#器具の製作
Icon of admin
 「Open DMX USB」をオリジナルのアプリで使うことを考えていきますと「DoctorMX」も使えたらなと思ってしまいます。
 開発・販売元のクワテックさんでは DoctorMX を使うためのライブラリとサンプルコードを公開してくださってます。C/C++ 向けですが、サンプルコードは私でも読めるので扱えるかもしれません(その昔は全く理解出来ませんでした。ちょっと感動。)。
 小屋卓のPC版を作るかはともかく、DoctorMX と Open DMX USB の扱い方を習得しておくのはいいかもしれません。

 2023年9月現在、クワテックさんから DoctorMX の Python ライブラリの提供はありません。リクエストしたら作ってくれそうな気もしますが、まずは自力で解決を目指しましょう。工夫や努力もせずに安易なリクエストをされるのは私も嫌ですしね。

「PythonからC言語の関数を呼び出す(基本編)」

追記
 上記がコンパイル出来るか試みましたがエラーを吐いて終わらない。
 「error: Unable to find vcvarsall.bat」とのこと。
 なんじゃこりゃ!?
 環境は VSCode の上で gcc です。
 日本語サイトには直球な解決策は見つかりませんでしたが、某英語サイトに「Microsoft Visual C++ Build Tools」を入れたら解決するとの書き込み。

Microsoft Visual C++ ビルド ツールをインストールする

システムに Microsoft Visual C++ がインストールされていない場合、または古いバージョンがインストールされている場合は、Microsoft Visual C++ Build Tools をダウンロードしてインストールできます。Microsoft Visual C++ Build Tools には、Windows 上で C++ コードをビルドするために必要な環境変数とツールが含まれています。

Microsoft Visual C++ Build Tools をインストールする手順は次のとおりです。

1:Visual Studio Build Tools Web サイトに移動します。
2:インストーラーをダウンロードして実行します。
3:「C++ ビルド ツール」ワークロードを選択します。
4:「インストール」をクリックします。


 開演時間になったのでお試しはお預けですが、2時間ほど悩んでいたので期待感大。

#Python #器具の製作
Icon of admin
 「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言語の関数を呼び出す(基本編)」

 C/C++のライブラリを Python で呼び出せると製作の幅が広がります。
 手始めにしては難しい課題ですが、DoctorMX を Python から使えるようにしてみたいですね。

#C言語 #Python
Icon of admin
 VSCode でC言語の Python ライブラリを作る際、ラッパーには Python.h が必須です。
 ですが、
#include <Python.h>
 と書くと「Python.h なんて無いよ」と言われてしまいます。
 フルパスで指定すれば通りますがこれは避けたい。
 VSCode の拡張機能 C/C++ の設定に追加をします。「C/Cpp > Default:Include Path」の「項目の追加」から Python.h がある階層のパスを追加します。Python のインストールによってパスが違うのでそれに合わせて指定します。

#C言語 #Python
Icon of admin
 ENTTEC 純正の Open DMX USB を入手しました。
 しかし、先日調べたネタではデバイスの認識すらしません。README.md を読み返したところRaspberryPi用でした。動かなくても仕方ない。

 調べ直したところGitHubに次の様なモノがありました。
「PyOpenDmxUsb」
 README.md を読む限り、Windows 上の Python で Open DMX USB を扱う代物のようです。
 使い方が少し難しいようですが、調べてみる価値はありそうです。

追記
「PyOpenDmxUsb」
 は予想外に簡単でした。
1)pip で pywin32 をインストール
> pip install pywin32
2)GitHub からダウンロードしたファイルを メインの Python ソースがあるフォルダにまとめる。
 ・フォルダ「PyOpenDmxUsb-master」内の「C#」フォルダにある「DMXServer.exe」。
 ・フォルダ「PyOpenDmxUsb-master」内の「Python」フォルダにある「DMXClient.py」。

 あとは、サンプルプログラムを参考にソースを書きます。
from DMXClient import DMXClient
import time

dmxClient = DMXClient("PODU")
dmxClient.connect()

while True :
 for i in range( 256 ) :
  try :
   dmxClient.write([1, i, 2, i])
   time.sleep( 0.1 )
  except KeyboardInterrupt:
   dmxClient.close()
   break
 break

 DMX の アドレス001とアドレス002をカウントしていくだけの動作を確認出来ました。
 コマンドコンソールか PowerShell から DMXServer.exe を起動してから上記の Python コードを実行します。
> .\DMXServer -n PODU
 この後、別コマンドコンソールから Python コードを実行します。

 DMXServer.exe を起動してから本プログラムを実行する手順が少し面倒だし Python らしくない。
 出来ることなら Python モジュールとして import して使えるようにしたいと思います。
 DMXServer.exeのC#ソースが付属しているので、これを参考に Python モジュールを作れたらいいのかな?

#器具の製作
Icon of admin
 「PyOpenDmxUsb」の「DMXServer.cs」を読むと「FTD2XX.dll」をコールしているがわかります。
 ならば、C++ 化することは可能っぽいです。先日書き込みした C/C++ による Python ライブラリ化を参考にすれば作れるかも。
 C#のコードを Python ライブラリ化してもいいのでしょうけど。

 ちなみに DoctorMX については C/C++ の世代変わりの壁で対策がわかりません。
 kuwatecさんが公開されているのは VC6 世代のコードようですが、C++はその後の時代に多くの改変がされているらしいのです。

#器具の製作 #C言語 #Python
Icon of admin
 Open DMX USB を扱うには FTD2XX.dll をコールするのが肝らしい。
 チンプンカンプンな領域なのでこれから勉強ですが、次のサイトがヒントになりそう。
「PythonからDLLを使う」
「Python から DLL を利用する」
「C++で書いたコードをPythonで動かすには【pybind11】」

 以下も参考になりそう。
「USBを使って制御できるリレーモジュールをpythonで動かしてみる」
「Programming FTDI devices in Python: Part 1」

 上記の記事と以下を合わせるといけるのかな?
「jlbrogdon/dmx_controller」

#Python
Icon of admin
 以下を参考に少し試してみました。
「Programming FTDI devices in Python: Part 1」

 Open DMX USB や FT232RL が実装されたデバイスが手元にありませんので何ともですが、pip で ftd2xx をインストールするとVSCode ではそれらしい関数の候補が出ます。候補が出るということはアクセスできる可能性が高いという事です。
> pip install ftd2xx
 pywin32 もインストールされます。

 「ftd2xx」のサイト見ますと、「ftd2xx は、ctypes を使用した FTDI の D2XX DLL の単純な Python ラッパーです。」とあります。
 システムコールを直球で使えるってことだと思われます。

「jlbrogdon/dmx_controller」
 ここで使われている関数とは呼び出す文言が違いますが、VSCode で表示される関数の候補にはそれと思われる関数が存在しています。

 明日以降になりますが FT232RL が実装されたデバイスを繋げた状態で色々テストしてみましょう。
 今考えているアイデアでいけるなら Open DMX USB の制御が Python で完結します。

 これはいいかも
「Ftd2xxドライバー説明」
 本家の資料では理解出来なかったことが分かりやすく書いてあります。欲しかった資料そのものです。
「ftd2xx.py」
「xiangruili/RTBox_py」

 これらの資料で行けそうな予感がムクムク。
 ENTTEC 純正の Open DMX USB と DMXチェッカーを事務所に置いてきたことを後悔。
 すでに帰宅して呑んでいるので取りに行けませんので明日以降ですね。

 それにしても、敷居が高いと思っていた DLL をここまで簡単に使えるとは予想外です。
 ドライバに対する DLL があれば、少なくともC/C++なら簡単にアクセスが可能で、それを単純なラッパーにしてしまえば Python からストレスなくアクセス出来てしまうのです。
 この辺りの手段は手にしたいですねぇ~。

#Python #器具の製作
Icon of admin
 「ftd2xx.py」ですが、Open DMX USB を認識しました。
 テストで使ったのは次のコード
### ftd2xx test ###
import ftd2xx as ftd

if __name__ == '__main__' :
 try :
  d = ftd.open( 0 ) # Open first FTDI device
  d.setDataCharacteristics
  print( d.getDeviceInfo( ) )
  d.close( )
 except :
  print( 'No Device' )
  exit( )

### 実行結果 ###
{'type': 5, 'id': 67330049, 'description': b'FT232R USB UART', 'serial': b'B000T33S'}

 実行結果は期待値を得ています。「ftd2xx.dll」を通じて FT232RL とやり取りが出来ていると思われますので、Open DMX USB として動かせそうな気がします。
 今後は「ftd2xx.dll」の解説書とソースコード読みながら解明していきましょう。

#器具の製作 #Python
Icon of admin
 「ftd2xx.py」を使って Open DMX USB から DMX512 が出るか試してみました。
 うまくいかない・・・。
 値は表示されますが、テストプログラムでは値を変化させているのにそれが出ません。Break Time あたりに問題があるように思いますが、オシロスコープかロジアナで信号波形を見ないとわかりません。
 波形を見るにはテスト環境を整えないといけませんので空き時間にちょっとお試しってワケにはいきません。しばらくお預けです。
 そんでも、値は一応表示されるのであまり遠くないところにいるような気がします。

 頑張って読み解くしかない本家の資料
「D2XX Programmer's Guide」

#Python #器具の製作
Icon of admin
 オレメモです。
 Open DMX USB が期待通りに動かないのは BreakTime が正しく出ていないのが原因かと予想しています。
 FTD2xx には setbreakon と setbreakoff がありますのでこれを使うのが肝だと思われますが、これらのコマンドを実行するだけでは求める BreakTime に至らないのだろうと思われます。
 違うライブラリを用いたソースコードでは Break を有効化するコマンドが2回と Break 無効化するコマンドが続きで書いてありましたので FTD2xx では Break に関するコマンドを発行すると1バイト分の送信が行われるのかな?と思っていました。2バイト分ですと BreakTime の最小時間と等しいですからね。
 検証しないとわかりませんが、setbreakon と setbreakoff は FT232RL の動作モードを変える( setbreakon を実行すると待機状態が L となる / setbreakoff を実行すると待機状態が H に戻る)だけで Break の時間を確保するものではないってのが現在の予想です。テストプログラムでは setbreakon を2回、setbreakoff を1回実行していましたが、setbreakon と setbreakoff の間に空送信か待ち時間を入れてみようと思います。まずは time.sleep( 0.001 ) (Windowsだと15msec前後になる)を差し込むことから始めて setbreakon の状態で空送信をしたらどうなるかです。

#Python #器具の製作
Icon of admin
 Open DMX USB の BreakTime について考えていたところ PIC の BreakTime についてもアイデアが出ました。
 拡張ミッドレンジPIC16系の EUSART には Break 機能があります。ただし、11bit分の L を出力して StopBit(H) を出すまでが一連の動作なので2回繰り返しても DMX512 の BreakTime にはなりません。今は I/O ピンをプルダウンしておき、入出力設定(TRIS)を Input(Hi-Z) にしてから捨て送信をすることで BreakTime を作っています。
 本題です。DMX512 の BreakTime は 最小 88usec ですから 250kbps なら 22bit 分の連続した L を出力すれば成立します。PIC16系の EUSART の Break が DMX512 の BreakTime に使えないのはこれが理由ですが、BaudRate を変更した Break を出力したらよくね?ってのが今回のアイデアです。手段を問わず、L 送信が 88usec 以上ならいいのです。私の理解が間違っていなけば、アイドル時なら BaudRate をバイト送信毎に変更しても EUSART は正しく動くハズです。単純計算なら BaudRate を半分にすれば規格値が出ます。現状でも BaudRate の調整だけで 1/50 くらいには出来ますから十分な BreakTime を作れると思われます。もちろん、BaudRate を 1/3 以下にして Break ではなく 0x00 を通常出力しても同じことです。こちらの方が汎用性が高いかも。受信も併用する構成ではNGですけどね。
 この方法が成立すればプルダウン抵抗は不要です。たった一つの抵抗ですが、部品を減らすことは絶対の正義ですので検討する価値はありそうです。

#PIC #器具の製作
Icon of admin
 Python で Open DMX USB を動かすことに成功しました。
 setbreakon と setbreakoff の挙動は予想の通りでした。
 以下がテストソースです。
 slot1 と slot512 を 0 から255 までカウントして終了します。
### Open DMX USB test ###
import ftd2xx as ftd
import time

if __name__ == '__main__' :
 baudrate = 250000
 word_length = 8
 stop_bit = 2
 parity = 0
 purge_tx = 2
 try :
  d = ftd.open( 0 ) # Open first FTDI device
  d.setBaudRate( baudrate )
  d.setDataCharacteristics( word_length, stop_bit, parity )
  d.purge( purge_tx )
  channelVals = bytearray( [ 0 ] * 513 )
  channelVals[ 0 ] = 0 # start code
  for i in range( 256 ) :
   try :
    channelVals[ 1 ] = i
    channelVals[ 512 ] = i
    channelbytes = bytes( channelVals )
    # Send Slot
    cstart = time.perf_counter_ns( )
    d.write( channelbytes )
    while time.perf_counter_ns( ) - cstart < 22800000 :
     pass
    # Break Time
    d.setBreakOn( )
    cstart = time.perf_counter_ns( )
    while time.perf_counter_ns( ) - cstart < 192000 :
     pass
    # Mark After Break
    d.setBreakOff( )
    cstart = time.perf_counter_ns( )
    while time.perf_counter_ns( ) - cstart < 12000 :
     pass
   # Press Ctl+C to Exit
   except KeyboardInterrupt :
    break
  d.close( )
 except :
  print( 'No Device' )

 time.sleep() は求める精度に足りないので time.perf_counter_ns() を用いています。
 0 から 255 のカウントが5.9秒強で終わるので 43fps くらい。ほぼ規格最大値です。
 本当にコレでいいのかわからんけど、モヤモヤしてたのがスッキリした。

#Python #器具の製作
Icon of admin
 Python での Open DMX USB の制御は8時間経過でも正常に動いている様子。
 不定期に一瞬の不整合が起きているとしても確認の方法がありません。とりあえずこんなもんでいいのかな?
 この後は Class 化と Thread 化をします。Thread 間通信は Queue ではなく 共有メモリを使いましょう。共有メモリは Tuple を FIFO で使うような便利なことは出来ませんが、今回は数値の配列を一方向で渡すだけですので、速度が期待できる共有メモリがいいでしょう。
 下記は Thread ではなく Prosess の例題ですが、共有メモリのさわりが分かりやすい。
「Pythonでプロセス間の値の共有」

#Python #器具の製作
Icon of admin
 共有メモリを使う場合、読み書きが衝突しないように配慮しなければなりません。
 今回は情報が一方向ですから比較的簡単ですが、よく考えないとトラブルのもとです。
 一番簡単なのは、DMX512 の値の配列の共有メモリと読み書きフラグの共有メモリを使う方法です。読み書きフラグは送り側がセットし受け側がクリアします。送り側はフラグがクリアならば共有メモリに書き込んでフラグをセットし、受け側はフラグがセットしてあれば共有メモリから読み込んでフラグをクリアします。
 双方の待ちを考慮しないとといけませんが、送り側が受け側のフェーズ時間の数倍でチェックをすれば遅延は1フレームです。何よりも Queue に比べ処理時間が短く情報の渋滞も起き難いことを優先しましょう。

#Python #器具の製作
Icon of admin
 先のテストプログラムでは送信終了を経過時間で見ています。大丈夫なハズですが、本来ならデータを送りきってバッファが空になったのを確認して送信終了としたい。
 データシートを読み直したところ、getstatus( ) で バッファの Queue の残りデータ数と実行中のイベントが読めるらしい。ただ、残りデータ数の意味がパソコン側なのか FT232RL側なのかがわからない。パソコン側なら欲しい情報ではない。イベントの意味も不明。この辺りは試すしかなさそう。

追記
 getstatus( ) では求める物を得られない様子。戻り値は ( 0, 0, 0 ) だけである。
 テストプログラムでは送信を開始してから 23msec 弱の待ち時間で送信が完了しているとしています。理屈では十分なハズですが、送信が終わってアイドル状態なことを確認する方法を見つけたいところです。

#Python
Icon of admin
 FT232RL の Windows ドライバである FTD2XX.DLL について解説している本家の資料を読めるようになってきました。
「D2XX Programmer's Guide」
 C言語の勉強をした成果だと思われます。

 私が求めているのは FT232RL がすべてのデータを送信しきってアイドル状態にあるかどうかです。
 先の getstatus( ) は、パソコン側のドライバにデータが残っているかを得るものらしく違うようです。
 私が使わせて頂いている ftd2xx.py は ftd2xx.dll のラッパーですので ftd2xx.dll の解説を読んで ftd2xx.py の本文を読めば何がどうなっているかおおよそ検討はついてきました。
 けれど、FT232RL のセッティングや受信状況を読み取る方法はあっても送信状況を読み取る方法が見つかりません。

 Open DMX USB の 仕様書を見つけるしかないのかなぁ。
 本家の ENTTEC を探しても見当たらないないんですよね・・・。

#Python #器具の製作
Icon of admin
 FT232RL の送信終了を把握する方法が見つかりません・・・。FT232RL 内のキャッシュが空か(送信がアイドル状態か)という意味です。
 どうやら、FT232RL は Break 送信の指示を受けると問答無用に Break 状態に切り替えてしまうようなのです。DMX512 では送信フレームの折り返しを示しますのでキャッシュデータの一つとして扱って欲しいものですが、FT232RL では強制リセットに等しい扱いなのだろうと思われます。
 出来ないなら出来ないで発想を変えてみましょう。

#器具の製作
Icon of admin
 防滴のLEDスポットを使っていますが、本体に直接彫り込んである雌ネジがバカになっています。
 雌ネジを再生しなければなりませんが、肉が無くなっていますのでタップを当てただけではダメです。となると、何かで肉盛りして雌ネジを再生します。
 こんな時、インサートが便利です。
20230920184803-admin.jpg
 管の表と内側にそれぞれネジが切ってあります。今回は止ネジがM6ですので、表がM8(ただし細ピッチ0.75)の物を使います。
 M8の下穴(ネジピッチが0.75ですのでΦ7mmくらい)を空けてタップを切り接着剤を塗布してネジ込みます。接着剤は密閉状態でも硬化する2液式のエポキシを使います。もちろん仕上がり性能は脱脂に大きく左右されます。
 面倒ですが、溶接等で肉盛りするワケにはいきませんので、こんなことをするしかありません。

#器具の修理
Icon of admin
 自宅の本棚を整理していたら「空飛ぶ円盤製作法」なる書籍を発掘。
20230923203814-admin.jpg
 中学生だか高校生だか、厨二病真っ盛りの頃に買った思い出があるので懐かしー。
 内容は難しい数式の羅列。たぶん、理系大学レベルの数学だと思われますので全く理解できません。
 一つだけ面白いなぁ~って思ったのは、電場を高速回転させることで重力に反する(相当する)力場を作れるって話。
 オカルト方面のネタになりますが、コマは回転中にほんの少しだけ軽くなるとの説もあり、物体は高速で回転すると軽くなるとかなんとか。
 前出の書籍によりますと「電場を3GHzの三相交流で回転させる」とあります。物質を3GHzの周期で回転させるなど不可能だと思いますが、物質を回転させずに電場の状態を回転させるなら3GHzも不可能ではないでしょう。今どきのパソコンも3GHzで動くCPUはザラですからね。
 回転中のコマが持つ電場が構成する物質に対して一定の位置関係ならコマの電場も回転していると見立てることが出来ます。高速回転が静止状態と違った物理現象を起こすならば、この本で言うところの電場を高速で回すことに興味が湧きます。

 厨二病当時の自分が今の知識を持っていたらこんな妄想をしただろうなぁ~って話www
 ただ、3GHzの三相交流を作ることには今の自分が興味深々です。これを作れたらインバーター回路の神になれそうです。

#雑談
Icon of admin
 アタマが空いた時のパズルとして客席テーブルの改修を妄想しています。
 課題は軽量化です。基本機能や耐荷重は実用レベルですが、1BOX車に積み込んだりカマチから客席後方まで手運びするには重い。
 現在の総重量は21kgです。長テーブルとしては格別重いワケでもありませんが、希望は12kg以下です。
 軽量化の方法は、
1) 材を薄く
2) 材の肉を抜く
3) 軽い材に変更
 とかでしょうか。
 一番単位重量があるのは天板です。平台に似た構造ですが、ここから見直しです。14kgありますが、半分を目指しましょう。

#ガチ工作
Icon of admin
 客席テーブルについて頭が空いている時に色々考えてみました。
 軽量化には強い材料に替えるか材料を少なくするかのどちらかが主軸になります。
 となると材料の強度を評価できなければなりません。
 ようやくわかったことですが、材料の耐荷重強度は形状寸法と荷重支持条件、「ヤング率」と「断面2次モーメント」で求められるようです。ヤング率とは材質の強度。断面2次モーメントは断面形状の強度らしい。
 計算式は条件によって様々ありますが、評価の目安ならこの二つの数の積で行えます。試作品は必要な強度を持っていますので、これが持つ値を評価値として使えばいいからです。
 試作品の梁はファルカタ合板9.0tを縦方向に使っています。ラワン合板のヤング率は6.9G/Paとのこと。ファルカタは少し強度が落ちますので減るハズですが、塗装によって強度が増していますし、安全率の一部と考えてこのまま使います。断面2次モーメントは 32N/cm4 くらいなので、評価値を 220 くらいとします。
 他の材質のヤング率の目安ですが、鉄なら200G/Paくらい、アルミなら70G/Paくらいです。
 この辺りの数値をもとに、コストやら加工条件やらを加味し、評価値程度の材料を見繕えばいいのかなと。

#ガチ工作
Icon of admin
 中国で倒産が多いとかナンとか言われておりますが、基板製造のPCBGOGOさんは健在でした。
 ちょっと急ぎの基板製造があって先ほど入稿したのですが、24時までの受付のところ23時43分に原稿を送ってデータ確認から送金まで終了しました。
 なんだかこれまでよりレスポンスがいい・・・。業務改善をしたのか、受注が減って手が空いているのかわかりませんが、早いのは助かります。
 単価は自作より安い。最小ロッドや送料を考えれば総額はそこそこになりますが、レジストのかかったキレイな基板が手に入ると思えば十分に安いと思う。
 リードタイムは一週間です。入稿して受け取りまでですから十分すぎる程早い。感光基板での自作は防腐処理まで一気にやらねばならないため丸一日かかりますが、丸一日使える日を待っていたら何時になるかわかりません。
 結果、PCBGOGOさんみたいなサービスは私にとって有難いワケです。

#電子工作
Icon of admin
 客席テーブルのことを考えていたのですが、塗装が重いのかもしれません。
 塗装で固めれば強度は増しますが、2平方メートルに厚塗りしたら無視できない重量でしょう。

 使用した塗料は1平方メートルあたり0.12~0.17kgだそうです。これを5回塗りしています。
 塗料の種類によって違いはありますが、溶剤が揮発して硬化すると70%くらいの重量になるらしい。
 これらの条件で計算しますと1kg程度です。無視はできないけど大したことないな・・・。
 実測は14.5kg、無塗装の計算値が7.5kgです。違いが大きいな・・・。
 エポキシで固めてみたりイロイロやりましたのでそのせいかな?

 ちなみに、角スタッドと呼ばれる軽量材を試しましたが、限界を越えると一気に座屈するのでだめでした。

 結局のところ、現行品と同じくファルカタ合板で平台作りにするのがいいのかもしれません。
 合板の表面を固めるならワシンの1液油性ニスがいいみたい。1層目を限界まで緩くして染み込ませてから積層していく方法です。

#ガチ工作

2023年10月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 本業がちょっくらシンドイ。やってもやっても終わりません。
 今は資料映像のレンダリング待ちです。

 このところ書いていますが、客席テーブルの課題は軽量化です。
 キャンプ用品の軽量テーブルの作りはとても参考になってますが、そのままでは耐荷重が不足と思われますし、何よりも脚構造を取り付けるには接合部の強度を確保できません。
 テストしたいのは天板として使える最も薄いファルカタ合板の厚みはどの程度?です。9.0tなら十分な強度出せているので減らす余地があると思うからです。
 実用耐荷重の目標値は120kgです。もちろん面で耐えられても点で破れたらダメです。3.0tでは無理がありそうなので4.0tで試作してみましょう。9.0tから4.0tの範囲で条件を探るのです。ダメならコンパネでも貼って倉庫の作業テーブルにすればいいし。

#ガチ工作
Icon of admin
 ほう、すごい!

 これは試してみたいですね。

#雑談
Icon of admin
 客席テーブルの天板は出来るだけ薄い板にFRPを施工する手もあります。
 FRPの比重は1.5とのこと。塗膜が1mmなら1.5kg/m2です。客席テーブルは1,520×600ですので0.912m2となり1.37kgです。
 ファルカタ合板は比重0.37ですから、天板面積では1mm厚で0.337kg/m2です。前作は9.0tを使っていますが、これを4.0tにすると-5mmで1.69kg減です。4.0tにFRPを施工するなら500gの軽量化です。大差ないっちゃ大差ありませんが、9.0tなら表面仕上げの塗装類が更に加算されますし、FRPを施工すればそれが仕上げになるので、800gくらいの軽量化になりそうです。
 知りたいことはFRPの施工がファルカタ合板の何ミリ厚に相当するのかです。仮にFRP1mm厚がファルカタ合板6mmに相当するならファルカタ合板は3.0tでも構わないとなりますし、ファルカタ合板2mmに相当するならむしろ重量が増して意味がありません。
 あとは、ガラス繊維を使うか使わないかです。使えば間違いなく強度が増しますがエポキシ樹脂が大量に浸み込んで塗膜が厚く重くなります。ファルカタ合板に染み込ませて木の繊維を固めるイメージならエポキシ樹脂の使用量を減らせます。むしろ繊維密度が低いファルカタの特性を利用する方針です。

 さて、どう進めましょう。

 前の書き込みでは4.0tとしましたが、3.0tで作ってみて強度を確認してみましょう。正直不安はありますが、アウトドアテーブルはこの程度の厚さにメラミン化粧板を貼っている傾向がありますので、無理を感じる最も厚い物で試す考え方です。
 もう少し強度があれば済みそうならエポキシ樹脂を塗布し、かなり足りないようならガラス繊維シートを使ったFRPを施工し、どうにもダメならコンパネを上貼りして倉庫の作業台にします。
 骨材を1台分作るも3台分作るも手間はそれほど違いませんので、天板違いのバリエーションを作ってもいいかもしれません。

 ・・・っと、本業本業。

#ガチ工作
Icon of admin
 客席テーブルのことを本業の合間に考えています。
 これまでの経験則で間違いなく大丈夫と思える構造では希望重量を軽くオーバーします。
 二転三転アッチコッチしているところですが、判断基準を得るために形にはなるけど強度がギリギリ不足かな?と感じる構成で作ってみるしかないようです。
 木材の価格はコロナ前に戻ってくれませんのでお試しにも限度がありますけれど、試さんとわからんことは試すしかないようです。
 適度な重さで、荷重に耐え、ラッシングで締め付けても蹴り飛ばしても壊れない物は簡単ではありません。
 3kgは夢のまた夢。

#ガチ工作
Icon of admin
 天板の合板を薄くすると均等荷重には耐えられても点荷重でヤバそう・・・。
 打合せへの移動中に時間が余ったのでホームセンターに寄り道して現物検討しましたが、合板だけで点荷重に耐えるなら9.0tが欲しいかも。5.5tでギリギリ感。

 卓がケース込みで100kgあったら瞬間的でもケースの角やゴム脚に全荷重がかかります。少し勢いが付いたら数割多い荷重がかかります。これを最大荷重の目安にしていますが、この荷重で破れても困ります。ナグリで叩いても少し凹むくらいで済むのが理想だけど、どこまで落としていいんだろう。
 以前、素材テストとして30tのスタイロフォーム(発泡スチロールよりは強度がある水色の建築用断熱材)を2.5tのラワン合板でサンドイッチしたことがありますが、これは思った以上に点荷重に強かった。スタイロフォームは圧縮に強く緩い曲線で凹むので荷重を分散してくれるためのようです。
 20tのスタイロフォームを薄い合板(2.5t)でサンドイッチすれば仕上がり25tでファルカタ合板5.5tより少し重いくらいになります。厚みがあるので応力耐性は上がりますし、5.5tよりも点荷重に強いでしょう。結果9.0t程度となったら採用かも?

 あぁ、材料試験する時間が欲しい・・・。

追記
 帰り際、しばらく前に作った30tのスタイロフォームを2.5tのラワン合板でサンドイッチした試作品をゲンノウ(丸頭の金づち)で叩いてみました。1寸5分の釘を打つくらいの強さです。
 驚くほど平気。破れるどころか手で触ってかろうじてわかる僅かな凹みしか残りません。さすがにナグリの角で叩けば表面の繊維は破断されますけど、これは9.0tでも同じこと。思った以上に複合材すばらしい。
 ついでに重量を計る。9.0tのファルカタ合板とほぼ同じ。ん?微妙・・・
 20tのスタイロフォームにすればもう少し軽くなるけど、手間が増えるのですから軽くならなければ意味がありません。9.0tを使った方が施工は簡単ですから。
 結局のところ、求める強度で施工すると重量は大して変わらないのかな?
 合板の表面から木クズが出ないように固める最軽量の表面処理を考えるのがいいのかな?
 アイデアが出るのはいいですが、どこに向かったものか・・・

#ガチ工作
Icon of admin
 接着剤の重量も無視できませんので試作品から計算してみました。コニシさんの木工ボンドCH38を使っていますが、1坪あたりの仕上がり重量は1.2kgくらい。
 スタイロフォーム25tをファルカタ合板2.5tでサンドイッチした構成で計算しますと、枠も組んだ天板全体(脚を覗く部分)で5.1kgと出た。
 初の5kg台!!
 これに脚を取り付ける金具が1.2kg、塗装を1.0kgとして7.3kgです。
 ギリギリ目標値です。

#ガチ工作
Icon of admin
 拾いモノですが、こういうの大好きです。
20231007214703-admin.gif

#雑記
Icon of admin
 本業が絶賛過密中です。
 ちょっくらヘトヘト。

 穴あきボードの壁にLED-Barを吊り下げる現場があるのですが、昨年40個作っておいた金具が4個しかない!どうやら捨てられてしまったようです。
 金具といってもΦ3.2の針金を曲げた物なので2時間くらいで再製作出来ましたが、当日の午前中に出庫積込みをして午後仕込みのつもりだったので、当日発覚したらエライことでした。
 どうも納得いかないのは、Φ3.2の針金を簡易治具を使って曲げていますからそこそこ形も揃っており、特別な用途のための物に見えると思うのですが、それをその場限りの消耗品と思って捨ててしまうのが理解不能。。。
 特定の案件や会場に合わせた特殊品がどうしも増えてしまうので、管理はシッカリやらんといかんです。

#本業 #ガチ工作
Icon of admin
 中華電機の LED-Bar を使っています。購入当時1本1万円少々と格安でした。
 この手の製品はビームライトとして作られているのが大半ですが、買ったのは広角タイプ。公称25度ですが、ここまで広角なのは案外希少です。付け外し可能な拡散レンズオプションを作ってLHQの代わりとしても使っています。半減角の計測は難しいですが、印象としては45~60度くらいです。

 便利に使えていますが、安いだけあってイロイロな問題があります。
 入荷数の1割くらいが最初から動かないのは中華電機アルアルですが、両端のフタが貧弱なプラ製で丁寧に扱わないと簡単に割れてしまいます。このフタは横ネジの取り付け部も兼ねているので割れてしまうと使い物になりませんが、このところ割れまくって稼働数が減ってしまい対策を考えないといけません。
 金属プレートを作るのが強度的に望ましいですが、形状的に外注が必須でコストが掛かり過ぎます。とりあえず3Dプリンタで試作します。ABSで肉厚に作れば実用強度になるかもしれません。フィラメントも安いもんじゃありませんが、金属プレートを外注するよりは安く済むと思います。
 早速、出来るだけ肉厚にした形状をプリントしましたが行けそうな感じです。修正はありますが追い込んでいきましょう。

#ガチ工作 #器具の製作
Icon of admin
 LED-Bar のフタを装着してみました。外形に狂いはありますが、気持ちよくハマりますのでヨシとします。
 重要なのは強度です。オベタを取り付けた状態で少々手荒に扱っても平気でありたい。本体との接合は大丈夫そうですが雌ネジがもつかな。
 雌ネジはインサートと追加工したワッシャで構成します。インサートは真鍮製で内M8-P1.25/外M10-P1.0、ワッシャは真鍮製の外径φ25-内径φ8.5-3.0tにM10-P1.0のタップを切った物です。インサートだけでは強度不足と思われるので、ワッシャ2枚で本体を挟んで接着しつつ締め込みます。真鍮製を使うのは、鉄ほど錆びず、ステンレスほど雄ネジを痛めず、接着性が良いからです。
 まるで作ったように書いていますが、インサート、ワッシャ、タップの入荷待ちです。

#ガチ工作 #器具の製作
Icon of admin
 施工の現場が思った以上に早く終わったので少し工作。
 LED-Bar にはハンガー吊りのためにダボを取り付ける専用アングルを作ってあります。ダボは寸法の都合でΦ16-17兼用です。
 吊りの使い勝手は良いのですが、置き使いをどうするかが問題です。純正の脚に付け替えるのが順当な方法ですが面倒ですし安定もイマイチ。ダボがあるので普通のオベタを付けてもいいのですが運び方を間違えるとサイドパネルが強度不足で割れます。となると、軽量な専用のオベタというかメスダボの脚を作るのがいいと思われます。
 メスダボはΦ18mm弱の丸穴ですが、内径が丁度良い規格品のパイプはありません。近しい寸法の物があればと思って調べ直したところ、規格品のガス管に外径Φ21.7mm内径Φ16.1mmの物がありました。SGP-15Aです。肉厚2.8mmですので0.8mm落として内径Φ17.7mmにしても肉厚2.0mmあるので実用域です。
 今日の工作はこのパイプの試し切りです。ミニ旋盤で中グリしましたが鉄は一回に0.05mmくらいしか削れません。アルミを削るのが精一杯の旋盤ですから仕方ありませんが、0.8mm落とすのに時間がかかること。ちゃんとした汎用旋盤ならば瞬殺なのに・・・。
 時間はかかったものの、出来上がったパイプは良さそうですのでこの方向で進めてみましょう。

追記
 中グリに比べ良いかわかりませんが、ドリルビットを手配してみました。φ16.5mm、φ17.0mm、φ17.5mm、φ18.0mmの4本です。
 十分な剛性とトルクを持った旋盤を買うのは無理なのでミニ旋盤を使うのが前提となりますが、これらのドリルを径を上げながら数回に分けて切れば何とかなるかな。切削は一か所ではなく対面二か所を0.2~0.25mm毎ですので芯ズレも少ないでしょうし、単に中グリをするとチャッキングが弱くてチャック側と刃物側では0.5mmくらい違ってくるのでドリルビットの方が良さそうな気配。このくらいの径になるとドリルビットも高価ですが旋盤を買うよりは安いし。
 メスダボを作る手段を確保しておくと何かと便利ですから研究です。

#ガチ工作 #照明器具
Icon of admin
 なんでかんで本業は忙しい。例年なら3人の現場を1人とか。
 別にやれることなんでいいんですねどね。

 常にアタマまで一杯ぢゃありませんので、LED-Barの改修を考えています。
 今日の現場でも使っていたのですが、プラ製のサイドパネルが絶望的にダメ。屋外に放置して10年間紫外線を浴びせたかの様に少し力をかけるとパリパリ割れてしまいます。
 これを修復するのは不可能じゃありませんが大変です。先の書き込みの通り、ABSでプリントして補強を入れた物を試してみましょう。

 もちろん専用の脚もです。
 ドリルなどの刃物と手持ち工具をアップグレードする用具の購入費ですが、メスダボを作るための初期投資がかなりの額になっています。先月、株で小遣いを稼いでいなかったら辛い投資です。
 ただ、丸パイプ(SGP-15A)の内径をφ17.5~18.0mmにするのは費用以上に加工が難しい。ちゃんとした汎用旋盤があればちょいと中グリするだけですが、そんなモノを買う費用も置き場所もありません。使える工具はミニ旋盤と小型ボール盤ですが、この範囲でどうにかしないといけません。
 まず、ドリルのくわえ寸はφ13mmになります。以前、6.5mmの六角軸のφ17.5mmのドリルを使ったことがありますが、これは軸が安定せず使いモノにならなかったからです。手持ちのミニ旋盤も小型ボール盤もφ13mmはくわえられません。φ13mmを装着できるドリルチャックに換装しなければなりません。ミニ旋盤は取り付け部が特殊で専用のドリルチャックしか使えませんのでφ13mmのドリルは使用不能。小型ボール盤は1/2インチの雄ネジなので使えそうなドリルチャックがありました。今コレの到着待ち。
 さらに、小型ボール盤を使うならバイスが必要ですが、外径φ21.7mmのSGP-15Aを変形させずにくわえられるバイスは自作するしかありません。くわえ部を付け替えられるバイスにアルミの角棒を取り付けてφ22mmの穴を空けるのです。φ22mmのドリルがこれまた高価。
 なにかと面倒ですねぇ。

#ガチ工作 #照明器具
Icon of admin
 タカチ電機工業のカタログを読み直したところ良い箱を見付ける。
 IP68防水アルミケース AWNシリーズ
 サイズ感が良く、サイドのフタが金属なのも良い。
 C60AからC30Aへの変換するブンキーで使えそうです。

追記
 サイズ感は良いのですが重いかも。
 未来工業のPVPが良いかも。プルボックスは正方形が多いところ、PVPには長方形もある。

#器具の製作
Icon of admin
 ネットを読んでいて不思議だなぁ~と思ったこと。マイナンバーカードについてです。
 不正の防止や情報管理の効率化・低コスト化に大きく寄与しますので活用の幅が広がって欲しいものです。ただ、情報漏洩であったり、保険証として登録しても病院の端末で読めないなど、初動からイマイチ感が漂っています。
 ユーザーに不信が広がるのは致し方ありませんが、勘違いも凄いなと。カードの中に個人情報がすべて入っているとか、ナンバーやカードがあれば紐付いている個人情報をすべてブッコ抜けるように思っている方がいるようです。これが今回の不思議ポイントですが、過剰に大騒ぎするのはこの辺りの勘違いも原因の一つの様です。

 マイナンバー、マイナンバーカードはアクセスキーです。データ本体は別なサーバーにあり、情報は専用の端末にアクセスキーを与えて初めて得られます。もちろん、関連データをすべて閲覧出来るのは余程の特権端末だけです。銀行で口座番号を読み取れても病歴や薬歴は読めません。
 そもそも、第三者にとって不特定の凡人の個人情報に何の価値もありません。社会的に特別な立場・価値をお持ちなら別ですが、群のデータの一つとして世間の動向を読み取るのに使われるのが関の山です。
 自意識過剰な凡人も悪意を持った第三者と同じくらい面倒な存在かもしれません。

#雑談
Icon of admin
 仕事が予想以上に早く終わって中途半端に時間が空いたのでメスダボの試作をしてみました。
 まずは専用のバイスの製作です。バイスのくわえ部をアルミの角棒に替え、0.5mmの板を咥えてφ22のドリルで穴を空けます。ボール盤も購入したドリルチャックも貧弱ですので綺麗な穴は空きませんが、パイプ(SGP-15A)を変形させずに咥えられるバイスになりました。
 次はドリルで丸パイプの内径を削ります。専用のバイスを作ったのはアタリしたが、貧弱なボール盤では1回に内径を0.5mm大きくするのが関の山でした。1.0mm1回よりも0.5mm2回の方が短時間なのでまぁいいかなと。オスダボは16/17兼用ですので、内径φ16.1mmの母材パイプをφ16.5mmで貫通し、オスダボのφ17の分(深さ11mm)をφ17.0・φ17.5と進め、穴口をφ18.0mmで3mm削ってみました。ドリルを4本替え進めるのは面倒ですが、結果、16/17兼用のメスダボとして悪くない物になりました。
 こんなんを70本近く作るのかと思うと気が遠くなりますが、外注する費用がありませんので手持ち工具でノンビリやるしかありません。置き場所があるならシッカリした汎用旋盤を手に入れたいものです。

#ガチ工作 #照明器具
Icon of admin
 ちょっとしたイベント照明は一人仕事がデフォになっている今日この頃。30代の頃なら楽勝でやったと思いますが、製造後半世紀も経ちますと体力的にシンドイです。
 コロナ明けで仕事が多すぎます。コロナが明けたからとそんなに一斉にやらんでもええがな。各所からの増員依頼を合算すると数十人なんて日もあります。
 余程の義理でも無ければ自社の仕事を優先して断わりますが、自分のメンツを立てようと安易な請負をする身内がいて面倒があったり・・・。返事は3秒、形にするのは3日ってバランスを考えて欲しいものです。
 ちょっと愚痴になりましたが、これは毎度のことなのでご勘弁を。

 1日に2~3現場をこなしていると工作は出来ません。今日もライトアップを仕込んで別件の屋外イベントを仕込んで夕暮れからライトアップのクライアント確認です。たまにならいいですが、こんなんが続くとアタマが混乱します。
 昨日のちょいと作業は気分転換になりました。工作、特に道具作りは楽しいですね。出来なかったことが出来るようになる道具作りは大好物です。加工手段が無くて四苦八苦することの方が多いのですが、形に出来た時は気分がスッキリします。

#ガチ工作
Icon of admin
 旋盤を探してみたのですが、Compact9しか条件を満たす物がありません。
 これでも大きいのですが、鉄を切削するにはこれでも不足かも・・・。
 悩ましいところですが、株で小遣いを稼げたら導入を考えてみます。

#工具や資材

2023年11月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 午前中の作業が早く終わって時間が半端に空いたのでLED-Barの脚を組んでみました。
20231101125839-admin.jpg
 吊るし塗装の状態です。
 溶接がヘタクソなのはご愛嬌。こんな溶接がされた物に体を預けたくありませんが、小物の脚ですからいいかなと。
 メスダボの内側の防錆をどうするか考えてしまいましたが、缶スプレーを一瞬吹き付けすればいけるようです。ダレないように本当に一瞬ですから数回吹き付ける必要がありそうです。

 塗装の前に本体に取り付けてみましたがイイ感じ。

#器具の製作
Icon of admin
 C60A-C30Aの分岐ボックスは未来工業さんのPVP201007Aで構成案を描いてみたところいい感じ。ケーブルの取り回しを充分に考慮しないと手詰まりになりますから細かいレイアウト図を起こしています。

追記
 スケッチを揚げます。部品の形状の三面図をメーカーのDXFや実測から起こしてレイアウトを試します。こういったスケッチで検討してから寸法図・加工図を起こします。
 少し大きいケースはPVP-201507Aです。
20231103121410-admin.jpg 202311031214102-admin.jpg 20231103125021-admin.jpg

 余談ですが、PDF出力する仮想プリンタドライバとして「Cube PDF」を使っています。フリーウェアとは思えない程の機能と使いやすさ。さらにはPDFだけでなく、PS、EPS、PNG、JPEG、BMP、TIFFも出力出来ます。上記はそれで起こしています。
 アプリに付属の画像出力がイマイチの場合に便利です。ただ、画像の解像度が高すぎる傾向がありますので、用途に合わせて別アプリで解像度を調整すると良いようです。

#器具の製作
Icon of admin
 野外現場でしたがバックアップの立場なのでスケッチを描いていました。
 今回はミニカムロック(E1015)入力のC型30Ax6出力のボックスです。
20231105184013-admin.jpg
#ガチ工作 #器具の製作
Icon of admin
 LED-Barのオベタの塗装が乾いたので装着して記念撮影。
 まずはダボ金具だけの状態。
202311081106291-admin.jpg
 オベタを付けた状態。
20231108110629-admin.jpg
 安定感は申し分ありません。
 68個作るのは大変ですが、フタも含め作り上げたい一品です。

 Φ16/17兼用ダボを使う理由ですが、ダボ側のM8雌ネジにボルトを捻じ込むため取り付け内側の出張りが少なく済むためです。この件ではアングル金具を最小にするために横ネジとのクリアランスを考慮して使っています。もちろん10kg以上の器具にはΦ17ダボを使うべきですが、本体が軽いならば出来る限り小型の方が良いと思うのです。

#ガチ工作 #器具の製作
Icon of admin
 カムロックケーブルが故障です。ユニットのレセプタクルから外れなくなってしまいました。固定ネジが折れて樹脂製のシェルが空回りするのです。
 バイスグリップで挟んで外せましたが交換しないといけません。カムロックの取り付けは何度もやっているので問題ありませんが取り外すのは別です。
 固定ネジがダメになっているので樹脂製のシェルは廃棄です。遠慮なくカッターで割り、端子を外して新品に付け替えます。丈夫な物を壊すのは一苦労ですが無事に交換完了です。
 外れなくなった原因は潤滑不足による捻じ込みトルク過多です。カムロックは最大180度、最小でも120度捻じ込まないといけませんが、強引な捻じ込みを繰り返しますと固定ネジに負担がかかって破損するようです。KURE556(666)やWD40、シリコンなどを塗布して接点のロックピンが必要以上に噛まない様に管理しなければなりませんが、コロナでしばらく使っていなかったのでメンテナンスを忘れていました。
 接点の洗浄を兼ねてKURE556の塗布をするすることを定期メンテナンスの課題にします。また、固定ネジも緩むことがありますから塗布の際に締め付けを確認することも追加です。

#器具の修理
Icon of admin
 マルチツールをポチってしまいました!振動工具の一種ですが、専門職の方や工具オタク以外は知らないと思われる電動工具です。
 製品はHiKOKIさんのCV12DAです。手持ち電動工具はmakitaさん一強の世の中ですが、父が前身である日立工機を勤め上げた人なので可能な限りHiKOKIを選ぶ様にしています。
20231110233521-admin.jpg
 ナゼ購入に至ったかというならば、プルボックスにC型30Aコンセントを取り付けるためです。C型30Aコンセントを取り付けるには角穴を空けなければなりませんが、すでに箱になっている物の横っ腹に角穴を空けるのは案外難しい。手元の工具ならPROXXONのフライスマシン、ジグソー、トリマーなどが候補となりますが、どれも平板や角材などの原材の加工には便利なものの箱を相手にするのは苦手です。
 マルチツールはその名の通り1台で何役も兼ねる工具ですが、基本の一つであるノコ刃を使えば平面の途中に切れ目を入れることが出来ます。これで四角を描けば角穴になるワケです。フリーハンドで当ててもそれなりに切れるそうですが、ネジ穴との位置関係も重要ですし、ケガく手間も減らせるものなら減らしたいので、ガイド(治具)を作って効率を上げてみましょう。
 現物の到着は数日後ですが、同じ頃に箱も入荷しますので試し切りをしてみたいですね。

#ガチ工作 #器具の製作
Icon of admin
 主幹電源入力をコンセント出力にするボックスは単相三線でも三相四線でも使える様にしたい。最小公倍数的に6出力が単位となりますが、2出力について入力経絡を切り替えたいワケです。
 切り替えるならばスイッチを使います。コレまでは2Pの切替カバースイッチを用いていましたが、今回は30Aまで流せるトグルスイッチを使います。NKKスイッチズさんの「S-822」です。カバースイッチより小さくパネル加工も楽だと思われます。
20231112135101-admin.png
#ガチ工作 #器具の製作
Icon of admin
 マルチツールと箱が届いたので我慢できず加工してみました。
20231113143716-admin.jpg 202311131437161-admin.jpg
 6口は長手方向に補強を入れないと抜き差しで箱が歪んでしまいそうですが、補強材を入れるのではなく、中央部に箱とフタをネジ止めするアングルを入れれば良さそうです。
 マルチツールは便利ですねぇ~。これまで使わなかった自分がアホに思えるほどです。
 塩ビは電動工具で切り進めると発熱して切削というより溶解してしまいます。材と刃物を冷やしながら進めると良いのですが、安いパーツクリーナーが後始末も楽で良いようです。吹きかけると結露するほど冷えるので「切削」になります。

追記
 塗ったらこうなった。
 それっぽい?
20231113232359-admin.jpg 202311132323591-admin.jpg
 脱脂、ミッチャクロンを塗布、艶消し黒ラッカーです。
 塩ビは表面処理をせずラッカーを塗るとパリパリ取れてしまうのですがどうでしょう。
 4-5日放置して様子をみます。

#ガチ工作 #器具の製作
Icon of admin
 デスクワークの合間に別な箱も加工しました。
20231114114454-admin.jpg
 吊るしてミッチャクロンを塗布した後です。

 物はミニカムロック(E1015)入力、C型30A×6出力です。丸端子を取り付ける端子台はありませんが、単相三線、三相四線を切り替えて使えます。
 20年経過しても痛みが無い重装備なC型ボックスに比べたら貧弱ですが、工具と段取りさえ整理しておけば比較的簡単に作れる箱なので寿命が短くてもいいでしょう。サンテナーのB#50に入る小型軽量品ですから機動性重視です。

 次の作業は来週以降になりますが、先行して塗っておけば塗装を十分に乾かすことが出来ます。1日あれば乾きますが、塗料を十分に硬化させるには一週間は放置したいところです。

追記
 黒くしてみた。
20231114192213-admin.jpg

追記
 塩ビに塗装するとシンナーの匂いが抜ける時間が短い様子。36時間経過で匂いがほぼ抜けています。
 木材ですと繊維に浸み込みますし、鉄やアルミだと材の温度が低い傾向があるからかな?
 ラッカーを塗布する際は厚塗りせず軽く捨て吹きする感覚で回数をかけるのが良さそうです。厚塗り2回より捨て吹き5回ってイメージです。我慢が必要になりますが、3回吹いてようやく全体が色付く感じです。捨て吹きの感じなら厚塗りの半分以下の時間で表面が乾くので、回数が多くても塗装時間も少なくて済みます。

#ガチ工作 #器具の製作
Icon of admin
 未来工業さんのカタログを見直していたら良い箱を見つける。
 PVK-AOP
20231115125537-admin.jpg
 防水仕様でサイズは108×108×51.5です。残念ながら黒はありませんが使い出がありそうな予感。
 C型ケーブルの分岐にも使えそうですが、先ずは棚上げ中のTRUE1分岐に使ってみます。

#ガチ工作 #器具の製作
Icon of admin
 そうそう、マルチツールの使い心地について。
 今のところノコ刃しか使っていませんが今までに無い使い心地です。
 切断ならこれ一本!ってことはありませんが、丸ノコとジグソウのイイトコ取りって感じがします。適材適所で使うのは当然としても、抑えドコロが他とは違う道具だと思います。切断電動工具の1本目にお勧めはしませんが、カユイ所に手が届かない感じがしたら試す価値があると思います。
 直線切りは治具が無くてもケガキ線に沿っていけます。一発仕上げにはなりませんが、刃が暴れる感じが少ないので隠れる所ならコレで切りっぱなしでも問題ありません。材をキチンと固定することは言うまでもありませんけど。

#工具や資材 
Icon of admin
 PVK-AOPが随分早く納品されたので試し切りをしました
20231116213837-admin.jpg 202311162138371-admin.jpg
 方向性はコレで良さそうですが、ホールソーの径を調整しないといけません。
 塩ビは-0.5mmくらいのホールソーを使った方が目的の寸法になるようです。冷却しながらでもホールソーの径丁度には仕上がらない為です。剛性の高いボール盤を使えばいいのでしょうけど。

#ガチ工作 #器具の製作
Icon of admin
 ラッカー塗装の乾燥を毎日チェック。
 不思議なことに、1日おきにシンナーの匂いがしなくなったり強くなったりを繰り返します。
 塗装2日経過で匂いが弱くなったと思ったら3日目は強くなり、4日目は無くなるといったことです。
 1日ズレで塗装した二品が同じところに吊るしてあり、片方が匂って片方は匂わないが交互に繰り返されますので、私の鼻のせいでもなさそうです。
 さて、これはどういうことなのでしょう。
 先行の物は今日で一週間です。組み立てに入る頃合いではありますが、本業が忙しくて作業が出来ませんので、またしばらく匂いの変化を見てみましょう。

#ガチ工作
Icon of admin
 時間が無いので特急で音源編集してました。夜ナベすると数日影響が出てしまうお年頃なので早く寝たいのですけど。
 ダンス演目の音源ですが、今更コンプレッサーの使い方がわかってきて驚いた。音の粒立ちをコントロールするのに凄く便利。今まであり得ないと思っていたパラメータが効くこと効くこと。マスタリングの達人にとっては当たり前過ぎることでしょうけど、わかったらちょっと感動。
 試しにパライコとコンプとリバーブだけでやってみましたが、余計なことするよりこの方がいいかも。特定の弦にインタビューしているようなピアノ音源は別ですけどね。
 ということで今日は終りにします。

#本業
Icon of admin
 ライトアップのために灯体を取り付ける架台を作っています。ほぼ完成しましたが、塗装の都合で撮影が出来ないので写真はありません。
 ナゼ架台を作るかというと、お寺さんの山門のバルコニー状のところに灯体を置きたいのですが、寸法や固定の都合で舞台照明用のオプションやイントレ関連が使えないからです。余程のリクエストに応える場合でなければビス打ちは出来ませんからね。そんなところに置かせてもらえるだけ凄いことですし。

 で、久しぶりに溶接機を使いまくったワケです。所有機は「SUZUKID Buddy80」です。100vのDIY向けですがイイんですよ。ただ、材の条件によってはアークが不安定でスパッタが大量発生して困っていました。
 DIY向けのノンガスの100vだから仕方ないのかと半ばあきらめていたのですが、ある方のyoutube動画で解決。大事なのは溶接の「音」だそうです。高音のパチパチは良くない音で、ちょっと低めのトーンで一定の音が続くのがいいとのこと。
 このご意見を参考にアークの見た目ではなく音で条件を探ってみました。マニュアルには推奨設定が書かれていますので電流も電圧もその値からスタート。電流を決めてから電圧を調整するといいらしいとのご意見もありましたので、電流をメインに調整して一定の音が続くところを探り、電圧を調整して高音のパチパチを抑えた流れです。
 私の腕では溶接機が良くなっても限度がありますが、以前よりもキレイなビードが引けてスパッタが激減しました。スラグも取れやすい。
 時間が無かったため現物を作りながら調整していったので最初のビードは恥ずかしい仕上がりですが、条件の出し方が見えて来たのは有難い。

#ガチ工作
Icon of admin
 トヨタは凄いですね。

 全個体電池が凄いと思っていたらTOSHIBAがその上を行く電池を開発し、トヨタが負けたかぁ~と思っていたら更にその上が発表されました。
 EVで使われるであろうモーターと電池に関する核心技術と特許の大半を日本企業が持っていることはゴールポストを動かすことがお得意の白人様にとっては皮肉ですね。
 ちなみに、特許出願数に関して日本が弱くなっているとか言われますが、実際はその昔の実用新案に等しい商品デザイン寄りの特許出願を乱発している国や企業が多いだけで、核心技術の特許数は相変わらずUSAに続いて日本が多いらしい。
 トヨタは新しい価値観を作ることを大事にしているんだなと思ったりしますが、日本の技術停滞は過去の常識感で理解可能な範囲で革新的な技術や製品を作れとするおバカな方が多いためではないかと想像しています。革新的なアイデアが試されることなく埋もれてしまったとしたら大きな損失です。

#雑談
Icon of admin
 某お寺さんのライトアップで架台を作ってきました。
 山門のバルコニーにスポットを取り付ける為の物です。
20231129163601-admin.jpg 202311291636011-admin.jpg
 50角の角パイプをL字にし単クランプを溶接した物を脚にし、単管パイプを渡しています。
 こんだけで結構な強度になりますが材料費は安い。
 貰い物ですが、パイプクランプハンガーもこういった仕込みでは便利です。

#ガチ工作 #器具の製作
Icon of admin
 A2Bと呼ばれる技術らしい。
 DTM STATION
 これはナカナカです。

#電子工作
 
Icon of admin
 ここ数か月全く進んでいませんが、Art-Netパッチを作っています。
 で、思い付く。
 回路名のプロファイルを使えたらどうかと。パッチ画面に回路の名称も併記するのです。パッチ操作ではDMXアドレスだけより名称もあった方が扱いやすいと思うからです。仮設現場でも回路名が表示されていればメンテナンス性がいいでしょうし。
 あと、パッチマシンはC言語で全部書くのではなく、受送信パッチ処理はC言語で書き、ユーザーフロントエンドの部分はPythonで書いた方が良さそうです。C言語でドライバを作りPythonで操作する感覚です。繋げる部分の記述は面倒っちゃ面倒ですが、C言語とPtyhonで得意分野を分けた方が生産性がいいかもしれません。

#[Art-Net] #器具の製作

2023年12月 この範囲を新しい順で読む この範囲をファイルに出力する

Icon of admin
 これでもか!
 と言わんばかりに本業が忙しい。
 現場が週に6日続いたり、1週間に段取りモノが3本あったり、気力体力が試されている今日この頃。
 なんとか乗り切っておりますが、50を越えると体力というか回復が衰えていることを実感。喰って寝たら翌朝完全リセット!なんてことはありえません。
 体の機能を維持するには「血液」のコンディションが大事だなぁ~なんて思います。体の隅々に酸素と栄養を送り届け老廃物を回収するのは血液であり、どんな部位も血液が滞れば数分もせずに壊死が始まるのですから、血液がより良いことは健康の基本かと思うのです。
 健康になれるなら死んでもいいなどとは考えませんが、少しの工夫で良い血液に出来るなら取り組むべきだと思います。
 ちなみに健康な若者の血を年配者に輸血すると元気になるんだそうですよ。大っぴらには出来ませんが、そんな治療が陰で行われているとかいないとか。吸血鬼さんの理屈は正しいのかもしれません。

#雑談
Icon of admin
 ディナーショーの段取りをしていて思い出す。クセノンピンが不調なことを・・・。
 症状はダウザーの動きが悪いこと。レバーが重く引っかかる。ダウザーでのフリッカーなど絶対無理なコンディション。ダウザーでフリッカーをするのが良いか悪いかはさておき。
 バラすしかないのでバラしました。アイリスをバラすのは職人技なのでやりませんが、ダウザーならナンとかいけます。
 で、バラして驚いた。正直不良です。購入したのは20年前ですから今更クレームは出しませんが、設計ミスと組み立てミスです。
 不良部位は2つ。
 1つ目はダウザーのブレード。1枚が2枚の鉄板をリベットで貼り合わせて構成されていますが、そのリベットがほんのわずかに出張っていました。アルミ製の筐体には擦れた跡というより溝が掘られており、クロームメッキしてある円盤にも擦れた跡がありました。リベットと削れたアルミ面をサンドペーパーで均し、クロームメッキされた円盤を清掃して解消しましたが、錆びて固着しないことを祈るばかりです。
 2つ目は、ちょっと説明が難しいのですが、操作レバーと円盤を繋ぐアングルを止める皿ネジのアタマがアルミ製の筐体と干渉していたことです。円盤に皿穴が掘ってあるのですがコレがほんの少し浅いらしくネジのアタマがわずかに出張っていてアルミ製の筐体と擦れるのです。出張りはクロームメッキの塗膜分って感じです。擦れていたアルミ筐体側を削ることで解決しましたが、黒い塗装が剥げアルミがガッツリ掘られていました。これは設計不良としか言いようがありません。更に、2台の内1台はこの皿ネジの頭がナメてバリが出ていました。皿ネジはプラス穴ですが、初めてバラした部位にも関わらずです。これは明らかな組み立て不良です。
 ウシオさんに喧嘩を売る気はありませんが、ここは正直に書こうと思った次第です。時間に追われていたので写真を撮ってませんから証拠はありませんケド。

追記
 修理したダウザーは絶好調でした。
 削ったところにサビが出てこないか今後の心配はありますが、ブレードはステンレスっぽいし、筐体はアルミ、円盤は肉厚のクロムメッキですから大丈夫かなと。
 間違ってもブレードに塗っちゃいけませんが、円盤の外周と筐体が接する部分にはウェアグリスを少しだけ塗布しています。近所のホームセンターで手に入る最も耐熱性の高い(200℃)物です。グリスは温度条件を越えると柔らかくなって垂れるか固着するので選択や用法に注意が必要です。
 一般的な印象としてはモリブデン系のグリスは耐熱性高いと思われがちですが、モリブデンそのものは耐熱性が高いものの、それを含ませている油分の耐熱性がそれほど高くない製品(120℃程度が一般的)が多いので注意です。モリブデングリスはモリブデンの粒子が球状のために細かなベアリングとなって面の間の平滑を行いますから一般的なグリスとは機能が違うのです。
 ウェアグリスは耐熱性の割りに安価で汎用的に使えて便利です。高速回転系にはあまり向いていないようですけどね。何にしてもムービングライト等のスポットライトのメンテナンスでは汎用的に使えます。もちろん、受熱を考えずに油分を塗布するのはいけませんケド。

#器具の修理
Icon of admin
 どこまで本当の話なのか。

 本当なら再生不可能エネルギーですね。
 つか、意識高い系の白人って表面のキレイごとしか見えないアホなのかな?その昔はアジアやアフリカから奪うことで辻褄を合わせていたけど、今はそれが無理だからアホさ加減が表に出てきたのかな?
 無生産な人たちが権力と財力を握ると良くないことになるのは何度も何度も繰り返されてきたことだと思う。白人と華人抜きで世界を再構成するのが最もエコかもしれない。

#雑談
Icon of admin
 久しぶりにディナーショー。
 小屋付でもないのに細々した宴会場の機構まで対応させられるので気疲れしますケド。
 そんなこんなでやっていると色んなイメージが出てきます。
 今回は使っていませんが、DMXの信号主幹にはEoC(同軸ケーブルでEthernetをやり取りする規格)によるArt-Netが良いことには自信が持てました。もちろん、確実性、安定性、汎用性などの大雑把に言えば「使い心地」は実際に使ってみないとわからんですけどね。
 全体をArt-Net化するのが主軸の話ですが、Wi-fi中継器も併用出来ると汎用性が高くなります。Art-Netは10MbpsのEthernetでも10ユニバースくらい扱えるようですから、今時のWi-fiなら実用レベルかな?と。ホテルの宴会場のサスバトンにはDMXの回線が出ていないことが多いですし、客導線のためにケーブルを敷設出来ないこともありますので。これらをプルボックスに内蔵してハンガー吊り出来るパッケージにしておくといいでしょう。沢山のスマホが集まる場所でWi-fiを使うこと自体怖いですけど、自動チャンネル変更機能が良いWi-fi中継器を使えば良いかなと。先日試したWi-fi中継器は本番中の大ホールでも普通に動いていましたのでこのメーカー・シリーズで試す予定です。
 他にもイロイロありますが、今後の検討課題です。

#照明器具
Icon of admin
 JANDS ESPⅡ 24ch が手元にあります。
 シンプルで芸はありませんが、ちょっとした現場には便利な調光卓です。ただ齢30歳ともなりますと物理的に寿命です。フェーダーのスライドボリュームにガリが出てるのはもちろんですが、プリント基板の銅箔が腐食して断線しているところもあります。
 不調のためここ数年使っていませんでしたが、苦楽を共にしてきた相棒ですので捨てるのは忍びなく修理というかリビルドしてあげようかなと思い始めました。
 メイン基板には痛みはありませんので、主にフェーダー基板の再生です。使われている日本抵抗器製のスライドボリュームは随分前に廃番になっていますし、基板もやられているので、入手可能なスライドボリュームを使ったフェーダー基板を丸々新造するのが現実的な対策です。
 問題は費用です。pcbgogoさんで見積もったら400x400mm(仮のサイズ)の両面基板が1枚52USDくらい。スライドボリュームは千石電商さんで580円くらいだけど、中華電機なら60円くらい。手間はともかく案外安く済みそう。
 最近は一般照明卓の選択肢が少なくなり、手に入っても機械的に廉価な物ばかりなので、JANDS ESPⅡ が10万以下で復活するならアリですね。

#器具の修理
Icon of admin
 同業の貴兄たちもそうだと思いますが異様に忙しい。
 コロナが明けての解放感から沢山のイベントが開催されることは嬉しいことですが、コロナの期間中に廃業・転職された方が多いのもあって軒並み人手不足のようです。
 私は事前の段取り作業や現場に合わせた製作物が多いため、員数合わせの現場にも関わるとシンドイ状況が続いております。あと一週間こなせば少し落ち着きますのでもうひと踏ん張り。

 日程が落ち着いたらアホかと思うくらいモノ造りをしたいです。
 ストレス解消のためか基礎設計と部品購入だけ進めてしまった案件の部品が山と積まれている惨状をナンとかしたいのもありますけどね・・・。
 お世話になっている鉄工所さんからの依頼物が数か月遅れているという不義理をしているので年末年始にナンとかして新年早々に納品しないといけません。ちょっと特殊なウェブカメラとその周辺機器ですが、アタマを全振りしないと作れない代物なので空き時間に少しずつ進めることが出来ないんですよ。自分の思考容量の小ささに閉口してますけど・・・。
 これがあれば現場が快適になるのに!という欲望から構想しているネタが多すぎるようです。自分自身の発想が自分自身の首を絞めている気もしますが、自社・他社に関わらず、現場の度にアイデアが湧いてくるのは止められません。。。

 話は変わりますが、最近は初心者を抜け出そうな部下の指導も困難を極めています。
 「今どきの若者は・・・」って文言はギザのピラミッドにすら書かれている愚痴ですが正にそう思います。
 自分を棚に上げて言いますが、今どきの若者は打たれ弱い。
 経験が少ない故に出来ないことは仕方ないと思いますが、狭い視野を広げてあげることは重要だと思っています。目先の舞台作りをどうするかは大切だしそれが主な役目ですが、観客や出演者も含めた関わるすべての人をイメージして自分の立ち位置を把握して取り組まないといけません。簡単に言うなら、照明だけ見てたんではダメなんです。
 ところがです、出来なったことや失敗したことをやんわり指摘しても、打たれ弱いために内に入ってしまい、「自分の未熟さが迷惑をかけた。迷惑をかけないように頑張らなくては!」と奮起しないのです。奮起するならヒントも与えられますが、失敗から更に視野が狭くなるので先に進めません。変な表現ですが、オールラウンド自分が主人公なワケです。特に幼い頃から叱らることがなかった子にはその傾向が強く、自分の未熟さが誰かに迷惑かけていると発想すら出来ないのです。
 あまり厳しくすると主人公様は物語から降りてしまうし、甘やかすだけでは仕事を成り立たせる人材にはなりません。自分が初心者の頃にご指導くださった諸先輩方に改めての感謝を感じつつ、どうしたものかと思案にふけるオッサンであります。

#雑談
Icon of admin
 JANDS ESPⅡ をリペアするのにスライドボリュームとツマミを手配しました。もちろん中華電機です。スライドボリューム1本が送料込みで74円でツマミは45円、これを100セットです。
 重要な部品ですから安かろう悪かろうは避けたいのですが、間違いない国内メーカーですとアルプスさんくらいしかやってませんがスライド長60mmの物はありません。中華製がダメだとは言いませんが、現物確認せずに買うのは少し戸惑います。けれど、他に選択肢はありませんし、お試し価格と思える範囲ですからいいかなと。国内手配でも結局は中国か東南アジア製ですので手に入るのは同等の製品になりますから、ダメならダメでESPⅡのリペアを諦めればいいし。
 中身を開いて現物の計測はしていませんが、外見から判断するに基板は大きくても270×150mmくらいです。PCBGOGOさんですと送料別5枚で100USDとのこと。本体が1台しかありませんので最低ロッド5枚分が1台当たりのコストとなりますが、基板としては4種類必要ですので400USDです。1USD140円として56,000円ですが、スライドボリュームやツマミを合わせても予算内でしょう。問題は会社が費用を出してくれるか?ですけどね。出してくれなきゃ自腹ですが、長年の相棒のためと思えば許容範囲内です。
 とまぁ、こんなことをするので手付かずの部品が積みあがってしまうのですけど・・・。

#器具の修理
Icon of admin
 JANDS ESP Ⅱ の為に仕入れたスライドボリュームとフェーダーツマミは思ったより良い品です。価格の割には、、、ではなく動きはスムーズで普通良い。廃番になった日本抵抗器さんの物に比べたら強度は劣りますが、日本抵抗器さんのが丈夫過ぎただけだしね。
 基板デザインするのも一苦労ですが、やってやりましょう。

#器具の修理
Icon of admin
 大晦日です。
 今年も沢山の方々にお世話になりました。
 本当にありがとうございます。
 新年も皆様にとって良い年になることを祈っております。

 お約束のご挨拶をさせて頂きましたが、副業の製作が終わりません。納期が1/8なのでどうしたものか。
 製作が終わらないというより、過密業務で疲弊した心身を回復させていたので進められなかったところです。
 大晦日の今日になってようやく回復した感じですが、こりゃ正月もノンビリしていられなさそうです。
 
#器具の製作
Icon of admin
 JANDS ESP Ⅱ のレストアを考えていて思ったのですが、Art-NetパッチとJASCIIオフラインを専用ハードウェアで一本化出来ないでしょうか。すでに廃番になった SmartFade にこれらの機能を付与したイメージです。
 これまではArt-NetパッチやJASCIIオフラインをPC上で構成して簡易PC卓にもしようと思っていましたが、CmsEditorがPCのOSのアップデートを受けて使えなくなったこともあり、専用ハードウェアで構成した方がいいのかなと思うようになったのです。CmsEditorは10年以上前にWindowsXP_32bitを前提として作っていますので致し方ないのですが、それほど遠くない将来、今回の案件も旧式のパソコンでないと使えなくなるなら専用ハードウェアで作っても同じかなと思うのです。
 ただ、専用ハードウェアは維持をするのが楽じゃありません。何時でも手に入ると思っていた重要部品がディスコンになることも珍しくありませんし、アフターケアを考えると部品のストックをしなければなりませんが資金にも保管場所にも限度があります。
 どの選択肢をとっても「あちらを立てればこちらが立たず」であり、いずれは維持できなくなると言えばそれまでですが、今のOS事情を見る限りWindowsやMacよりLinuxを母体にした専用ハードウェアの方が長く維持できそうな気がします。
 イメージを固める段階ですが、全方位で製作するのは能力的にも時間的にも不可能ですのでどうしたもんかな?って感じです。

#器具の製作
Icon of admin
 年越しは副業の製作です。
 小型の製品を組むので暖かいところで作業しています。数年前、プロジェクタを屋外に設置するための箱を作っていたときは寒さとの闘いでしたら天国の様です。
 大晦日なのに車で20分の実家にも帰らず何してんだって話ですが、ようやっと心身が回復しつつあるので頑張るしかありません。品物は3種ありますので1日1品やっつけても間に合うのか・・・。
 本業に追われる日々が落ち着いたらこの有り様です。シンドイですねぇ。

 愚痴っても終わらせるしかありませんので手を進めましょう。
 今は基板のハンダ付けが終わったので休憩です。慣れるとリフローハンダは楽です。
 この後は基板の配線をチェックし、RaspberryPiと接続して全体の動作チェックと進めます。
 除夜の鐘までに今の品物を終わりにすれば少し気が楽になるかな・・・。

 そんな作業をしながら Art-Netパッチ のイメージも進めています。
 基板の製作は高度になりますが、PaspberryPi-CM4を2-3枚使った構成がいいかなと思ってきました。複数のRaspberryPiをEthernet、I2C、SPIなどで協調動作させるのです。
 デスクトップOSが走ってI2CやSPIを扱える条件ですと高価な工業用PCかRaspberryPiしか選択肢にありません。工業用PCは信頼性が高いものの高価で比較的電力も喰います。
 アマチュアDIYの延長で考えるならRaspberryPiしかないのかなぁ~って感じです。
 キー操作やフェーダーセンシングにはPICを使います。元々そういう用途のマイコンですから、I2CやSPIを使えばRaspberryPiと比較的容易に高速な通信が可能です。

#器具の製作