電装工芸日記
- 舞台照明機器の製作とか -
全年全月27日の投稿(時系列順)［36件］（3ページ目）
2022年12月 この範囲を新しい順で読む この範囲をファイルに出力する
ライトアップのご依頼が多くなっています。
自家製の制御システムがあるので安く提供出来るのが強みですが、このところはリレーやタイマーが手に入らず難儀してました。
今月に入ってダメもとでモノタロウさんを見直したところ在庫あり。メーカーのサイトを見ると「供給量が少ないのでご注意ください」とはあれど供給は復活している。
速攻でオーダー。
リレーはOMRONさんのG7L-2A-BUBですが、フランジ形状なので取り付けが楽で、小型で動作電流も少なく、20A流せるので使い勝手が良いリレーです。AC100vで駆動する物を主に使いますが、制御用のDC電源が不要だし、横繋ぎで動かせるし、既設のタイマーで動いているAC100v負荷があれば制御信号として電源を盗み出して使うことも出来ます。
タイマーも数量限定ながら手に入りました。近い将来IoT化するつもりですが、電源の制御はシンプルなタイマーリレーに限ります。
#本業 #ガチ工作
自家製の制御システムがあるので安く提供出来るのが強みですが、このところはリレーやタイマーが手に入らず難儀してました。
今月に入ってダメもとでモノタロウさんを見直したところ在庫あり。メーカーのサイトを見ると「供給量が少ないのでご注意ください」とはあれど供給は復活している。
速攻でオーダー。
リレーはOMRONさんのG7L-2A-BUBですが、フランジ形状なので取り付けが楽で、小型で動作電流も少なく、20A流せるので使い勝手が良いリレーです。AC100vで駆動する物を主に使いますが、制御用のDC電源が不要だし、横繋ぎで動かせるし、既設のタイマーで動いているAC100v負荷があれば制御信号として電源を盗み出して使うことも出来ます。
タイマーも数量限定ながら手に入りました。近い将来IoT化するつもりですが、電源の制御はシンプルなタイマーリレーに限ります。
#本業 #ガチ工作
Ｃ言語を習得する壁として代表的な機能は、
１）ポインタ
２）構造体、共有体
３）typedef（自分なりの変数の型を定義する）
でしょうか。
ポインタは以前も書きましたが、変数をアドレス値で読み書きする方法です。CPU、メモリ、デバイスというハードウェアの基本要素が頭に入ってないと捉えにくいのですが、わかればシンプルだと思います。
構造体はPythonで言うところのタプルみたいなものです。
共有体は機能はわかっても意味がイマイチピンときませんが、高度なことを書く際に便利なのでしょう。
typedefにはじんわりとオブジェクト指向を感じますが、データベースにアクセスするなど、構造体を多用する際に便利な気がします。
他は計算記述とループコマンドですが、これらは方言のレベルで受け入れればいいようです。配列に対する計算はPythonと少し違うみたいなので整理が必要です。
要所の基本は理解できたっぽいので、とにかく書いて慣れることですね。
呆れる程書いて体に馴染ませたPICのアセンブラ並にＣ言語を書けるようになれたら御の字です。
実習はこれからですが、共有メモリも見えてきました。
名前のままですが、複数のプロセスからアクセス(共有)できるメモリ領域を定義する方法です。
mmap(メモリマップドファイル)とかpipeに似ていますが、mmapはRAMディスク上のファイルを共有するイメージで、pipeは変数の内容をシステムを通じて送受信するイメージです。どれもプロセス間で情報を共有する手段ですが、共有メモリはこの中でもローレベルでシンプルな方法だと思います。ローレベルすなわち速度が期待でき、最初の定義は面倒だけど定義さえ済めば単なる変数として扱えます。
今時のOSは特定のプロセスがアクセスできるメモリ領域を制限することで動作の安定とセキュリティ(セキュア)を担保します。このため、別プロセスの領域にある変数(メモリ)にはポインタを使ってもアクセス出来ないのです。
MS-DOSなどの初期のＯＳではありえなかった制限ですが、利便性とセキュアは矛盾するシステム要件ですから、抜け道として共有メモリが用意されたのしょう。アクセスが許可されたプロセスからはただのメモリ領域ですからポインタで普通に読み書き出来ます。動作速度が通常変数と大差ないのも嬉しい。
共有メモリを定義して得られる情報はID、先頭アドレス、メモリサイズ、パーミッションだけです。OSやコンパイラがマネージしてくれない変数ですから、メモリに展開する構造体を手作業で管理しなければなりません。読み書きもマネージしれくれませんので、プロセス間で動作が衝突して誤動作に繋がる可能性があるので、セマフォを使うなり、データを一方通行にするなりして対策する必要もあります。この辺りはPICのアセンブラと同じですけどね。
学んでて思うのですが、Ｃ言語はアセンブラを抽象化して書きやすくしたものだとするのが私には自然です。アセンブラを補助するマクロ集を膨らませていったらマクロ命令だけでもプログラムソースが書けるようになってしまい、ならばマクロの内容を整理したら更に便利ぢゃね？となったんじゃないかと勝手に想像しています。プログラム言語としてJAVAやPythonと同類に位置付けされますが、性根のところでは別分野の代物なんですよ。学ぶ側にとっては、俗に言う高級言語に分類するから逆に理解し難いんだと思うのです。ハードウェアが直に読むマシンコードを便利マクロだけで書くと思えばポインタなどは超お気楽な便利機能に見えてきます。
つーて、アセンブラとかマシンコードって何？って聞かれてしまうと困ります。色彩をカラーフィルターの番号と光源のレベルで例えてしまう照明屋の言葉が一般には通じないことと同じです。
#Ｃ言語
１）ポインタ
２）構造体、共有体
３）typedef（自分なりの変数の型を定義する）
でしょうか。
ポインタは以前も書きましたが、変数をアドレス値で読み書きする方法です。CPU、メモリ、デバイスというハードウェアの基本要素が頭に入ってないと捉えにくいのですが、わかればシンプルだと思います。
構造体はPythonで言うところのタプルみたいなものです。
共有体は機能はわかっても意味がイマイチピンときませんが、高度なことを書く際に便利なのでしょう。
typedefにはじんわりとオブジェクト指向を感じますが、データベースにアクセスするなど、構造体を多用する際に便利な気がします。
他は計算記述とループコマンドですが、これらは方言のレベルで受け入れればいいようです。配列に対する計算はPythonと少し違うみたいなので整理が必要です。
要所の基本は理解できたっぽいので、とにかく書いて慣れることですね。
呆れる程書いて体に馴染ませたPICのアセンブラ並にＣ言語を書けるようになれたら御の字です。
実習はこれからですが、共有メモリも見えてきました。
名前のままですが、複数のプロセスからアクセス(共有)できるメモリ領域を定義する方法です。
mmap(メモリマップドファイル)とかpipeに似ていますが、mmapはRAMディスク上のファイルを共有するイメージで、pipeは変数の内容をシステムを通じて送受信するイメージです。どれもプロセス間で情報を共有する手段ですが、共有メモリはこの中でもローレベルでシンプルな方法だと思います。ローレベルすなわち速度が期待でき、最初の定義は面倒だけど定義さえ済めば単なる変数として扱えます。
今時のOSは特定のプロセスがアクセスできるメモリ領域を制限することで動作の安定とセキュリティ(セキュア)を担保します。このため、別プロセスの領域にある変数(メモリ)にはポインタを使ってもアクセス出来ないのです。
MS-DOSなどの初期のＯＳではありえなかった制限ですが、利便性とセキュアは矛盾するシステム要件ですから、抜け道として共有メモリが用意されたのしょう。アクセスが許可されたプロセスからはただのメモリ領域ですからポインタで普通に読み書き出来ます。動作速度が通常変数と大差ないのも嬉しい。
共有メモリを定義して得られる情報はID、先頭アドレス、メモリサイズ、パーミッションだけです。OSやコンパイラがマネージしてくれない変数ですから、メモリに展開する構造体を手作業で管理しなければなりません。読み書きもマネージしれくれませんので、プロセス間で動作が衝突して誤動作に繋がる可能性があるので、セマフォを使うなり、データを一方通行にするなりして対策する必要もあります。この辺りはPICのアセンブラと同じですけどね。
学んでて思うのですが、Ｃ言語はアセンブラを抽象化して書きやすくしたものだとするのが私には自然です。アセンブラを補助するマクロ集を膨らませていったらマクロ命令だけでもプログラムソースが書けるようになってしまい、ならばマクロの内容を整理したら更に便利ぢゃね？となったんじゃないかと勝手に想像しています。プログラム言語としてJAVAやPythonと同類に位置付けされますが、性根のところでは別分野の代物なんですよ。学ぶ側にとっては、俗に言う高級言語に分類するから逆に理解し難いんだと思うのです。ハードウェアが直に読むマシンコードを便利マクロだけで書くと思えばポインタなどは超お気楽な便利機能に見えてきます。
つーて、アセンブラとかマシンコードって何？って聞かれてしまうと困ります。色彩をカラーフィルターの番号と光源のレベルで例えてしまう照明屋の言葉が一般には通じないことと同じです。
#Ｃ言語
2023年1月 この範囲を新しい順で読む この範囲をファイルに出力する
ANSI-CというかLinuxのＣ言語ではキー入力は「待ち」が基本です。何かキーが入力されるとか、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から１文字取得
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を使って標準入力から１文字取得
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でも同様の処理を書いたことがありますが、Ｃ言語の方が圧倒的にレスポンスがいいです。
矢印キーがANSIエスケープシーケンスのコードで取得できたことには驚きましたが、ファンクションキーも含め、getcharでは取得できないこともあるキーも取得出来て満足。
ただし、シフトキーなどの装飾キーを単体で取得することは出来ません。
#Ｃ言語
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から１文字取得
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を使って標準入力から１文字取得
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でも同様の処理を書いたことがありますが、Ｃ言語の方が圧倒的にレスポンスがいいです。
矢印キーがANSIエスケープシーケンスのコードで取得できたことには驚きましたが、ファンクションキーも含め、getcharでは取得できないこともあるキーも取得出来て満足。
ただし、シフトキーなどの装飾キーを単体で取得することは出来ません。
#Ｃ言語
2023年2月 この範囲を新しい順で読む この範囲をファイルに出力する
中華電機ムービングの筐体が割れています。アッパーボックスの樹脂パネルです。これを修理します。
樹脂の補修は材質を把握するのが第一歩です。材質によって治し方が違うからです。
材質の判断は匂いで見当を付けて溶剤もしくは接着剤で溶解具合いを見るのが基本です。今回のはABSでした。
ABSどうしの接着ならコレが基本でしょう。セメダインの「ABS用」です。
接着には様々な方法がありますが、これは「溶着」です。材を溶かして結合させます。
面積のあるABSどうしの接着ならコレを両側に塗って貼り合わせればほとんど場合十分です。
今回のブツは肉薄なので肉盛りして補強した方がいいみたいです。破断面がキチンと嚙み合いませんので歪みというか応力がかなり残っているようです。今回の破損も衝撃が引き金だとしても応力のために割れやすくなっていたとも思われます。加熱して応力を取ることも出来るそうですが、職人技なので私には無理です。
こういう時にはプラリペアです。樹脂材全般に使えますが、ABSとは相性が良いので裏側に盛って補強にします。
ただ、単にプラリペアを盛るより接合面に谷を掘って盛るのがお勧めです。
こんな時、ミニルーターが便利です。私はPROXXONのミニルーターを使っています。
ABS用で形を戻し、裏側の目立たないところにプラリペアを盛って補強します。
#器具の修理
樹脂の補修は材質を把握するのが第一歩です。材質によって治し方が違うからです。
材質の判断は匂いで見当を付けて溶剤もしくは接着剤で溶解具合いを見るのが基本です。今回のはABSでした。
ABSどうしの接着ならコレが基本でしょう。セメダインの「ABS用」です。
接着には様々な方法がありますが、これは「溶着」です。材を溶かして結合させます。
面積のあるABSどうしの接着ならコレを両側に塗って貼り合わせればほとんど場合十分です。
今回のブツは肉薄なので肉盛りして補強した方がいいみたいです。破断面がキチンと嚙み合いませんので歪みというか応力がかなり残っているようです。今回の破損も衝撃が引き金だとしても応力のために割れやすくなっていたとも思われます。加熱して応力を取ることも出来るそうですが、職人技なので私には無理です。
こういう時にはプラリペアです。樹脂材全般に使えますが、ABSとは相性が良いので裏側に盛って補強にします。
ただ、単にプラリペアを盛るより接合面に谷を掘って盛るのがお勧めです。
こんな時、ミニルーターが便利です。私はPROXXONのミニルーターを使っています。
ABS用で形を戻し、裏側の目立たないところにプラリペアを盛って補強します。
#器具の修理
2023年4月 この範囲を新しい順で読む この範囲をファイルに出力する
ふと思いついてこんなん試作ってみました。
塩ビ水道管のＴ分岐にTRUE1のレセプタクルを取り付ける方法です。
TRUE1の取付部は３Ｄプリンタで作っています。何の仕上げもしてないのはご愛嬌。
塩ビ水道管の接着剤(エスロン)はABSも溶かすようです。ABS接着剤と臭いが似てるので試したところビンゴでした。
溶着なら水漏れの心配はありませんし接着強度も十分です。
先日作ったのはＹ分岐で、これはＴ分岐です。
どちらがいいというより使い分けです。
サスバトンに鈴蘭ケーブルごとく横繋ぎしていくならこれの方がいいかも。
寸法の手直しがあるので、もう１セット作って評価しましょう。
Ｙ分岐もそうですが、意外な問題点はケーブルの仕舞い方です。
ハウジングにはレセプタクルの取付穴しか開口部がありませんので、ケーブルの先端が取付穴から顔を出さないと結線が出来ません。この顔を出すための余長が思った以上に仕舞い難いのです。
出来るだけ柔らかく、出来るだけ細いケーブルが望ましいのですが、KIVではなくHKIVなら太さを１ランク落とせます。KIV2.0スケアとHKIV1.25スケアの許容電流はほぼ同じです。
#３Ｄプリンタ #器具の製作
塩ビ水道管のＴ分岐にTRUE1のレセプタクルを取り付ける方法です。
TRUE1の取付部は３Ｄプリンタで作っています。何の仕上げもしてないのはご愛嬌。
塩ビ水道管の接着剤(エスロン)はABSも溶かすようです。ABS接着剤と臭いが似てるので試したところビンゴでした。
溶着なら水漏れの心配はありませんし接着強度も十分です。
先日作ったのはＹ分岐で、これはＴ分岐です。
どちらがいいというより使い分けです。
サスバトンに鈴蘭ケーブルごとく横繋ぎしていくならこれの方がいいかも。
寸法の手直しがあるので、もう１セット作って評価しましょう。
Ｙ分岐もそうですが、意外な問題点はケーブルの仕舞い方です。
ハウジングにはレセプタクルの取付穴しか開口部がありませんので、ケーブルの先端が取付穴から顔を出さないと結線が出来ません。この顔を出すための余長が思った以上に仕舞い難いのです。
出来るだけ柔らかく、出来るだけ細いケーブルが望ましいのですが、KIVではなくHKIVなら太さを１ランク落とせます。KIV2.0スケアとHKIV1.25スケアの許容電流はほぼ同じです。
#３Ｄプリンタ #器具の製作
2023年5月 この範囲を新しい順で読む この範囲をファイルに出力する
2023年7月 この範囲を新しい順で読む この範囲をファイルに出力する
Table のカラム幅の自動調整で少し悩む。
初期サイズからウィンドウ枠をドラックするサイズ変更を１回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が１回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。
あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
フォントの指定も列ごとに出来るといいのですけどね。
#Python
初期サイズからウィンドウ枠をドラックするサイズ変更を１回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が１回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。
あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
フォントの指定も列ごとに出来るといいのですけどね。
#Python
まだまだ途中ではあるものの使えるっちゃ使える LTC_Player で本業の音源チェックをしています。
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
2023年8月 この範囲を新しい順で読む この範囲をファイルに出力する
とある中堅企業さんの労働組合さんの納涼祭でした。お盆もとうに過ぎているのに納涼祭？とか思ったりしますが、中堅の工場はお盆前後が忙しいので時期をずらすのはアリアリでしょう。勤務日数が少ない８月を乗り切ったぞー！ってヤツも含まれていそうです。
そんな現場でしたが、MAdot2 を使ったので LTC Player のランニングテストも同時に実施。本番でこんなことをするのは不謹慎ちゃ不謹慎ですが、LTC が途切れることなく受信されるかを確認するには丁度よい。普段なら卓をずっと眺めていることは難しいですが、目の前の卓を操作するのが仕事なら無理はありません。LTC で卓を動かすのでははく長時間の認識のテストですから時計を表示するのと同じ。LTC のデータが間違っていたり途切れたりして卓が止まることはまずありません。なんでかんで MA の製品ですから。
８時間ほど実施しましたが問題は発生セズ。バグではなく設計(デザイン)のミスを見つけたので今後対策しますが、音源に沿った LTC で止まることなく卓がカウントを刻むのは気持ちがイイ。
プレイリストの保存機能も構成しなければなりませんし、修正もまだまだありますが、間違いなく β版 に昇格しています。この達成感と安堵感は暑さという調味料以上にビールを美味しくしてくれています。オタク冥利とはこのことでしょうか。
#タイムコード #Python
そんな現場でしたが、MAdot2 を使ったので LTC Player のランニングテストも同時に実施。本番でこんなことをするのは不謹慎ちゃ不謹慎ですが、LTC が途切れることなく受信されるかを確認するには丁度よい。普段なら卓をずっと眺めていることは難しいですが、目の前の卓を操作するのが仕事なら無理はありません。LTC で卓を動かすのでははく長時間の認識のテストですから時計を表示するのと同じ。LTC のデータが間違っていたり途切れたりして卓が止まることはまずありません。なんでかんで MA の製品ですから。
８時間ほど実施しましたが問題は発生セズ。バグではなく設計(デザイン)のミスを見つけたので今後対策しますが、音源に沿った LTC で止まることなく卓がカウントを刻むのは気持ちがイイ。
プレイリストの保存機能も構成しなければなりませんし、修正もまだまだありますが、間違いなく β版 に昇格しています。この達成感と安堵感は暑さという調味料以上にビールを美味しくしてくれています。オタク冥利とはこのことでしょうか。
#タイムコード #Python
今回の LTC Player と LTC Generator のパソコン側のシステムは全て Python で書いています。
その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとＣ言語でやってきたこともＣ＋＋にしてみたくなる。時間と脳味噌に空きが無くて１年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、Ｃ＋＋で書いたらスマートに書けそうな気がしてきています。
Ｃ＋＋と言っても ANSI の Ｃ言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の Ｃ言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。Ｃ言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。
#Ｃ言語
その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとＣ言語でやってきたこともＣ＋＋にしてみたくなる。時間と脳味噌に空きが無くて１年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、Ｃ＋＋で書いたらスマートに書けそうな気がしてきています。
Ｃ＋＋と言っても ANSI の Ｃ言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の Ｃ言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。Ｃ言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。
#Ｃ言語