tkinter

事例

【PyFMI】最小構成のMBD事例 第2章 その134【リアルタイム描画㉘】

Pipeの受信処理のコードを提示。 受信自体は一関数だが、byte配列からdoubleに直すのに手間がかかってる感じ。 Pipeの受信確認。 受信関数自体は受信が来るまで戻ってこないので、無条件では呼びたくない。 よって、poll関数で受信有無を確認した後に実際の受信処理をする。 次回から実際のコードと動作確認。
事例

【PyFMI】最小構成のMBD事例 第2章 その133【リアルタイム描画㉗】

Pythonでサブプロセスの生成と開始について説明。 Process関数を呼ぶだけ。 引数にサブプロセス開始時に呼び出す関数とそれに対する引数を渡せる。 今回はPipeを渡しておく。 Pipeによる送信について説明。 send_bytesを呼ぶだけ。 dequeのままでは渡せないのでdouble型のarrayにする。
事例

【PyFMI】最小構成のMBD事例 第2章 その132【リアルタイム描画㉖】

Pythonでマルチプロセスをする上での手順確認。 Pipeを使ったプロセス間通信が面倒そう。 追加コードについては今回は触り程度。 要importのライブラリ。 multiprocessingのProcessとPipe。 Pipeの生成。 送受信の2つが取得できる。 引数自体で双方向、片方向が切り替わる。
事例

【PyFMI】最小構成のMBD事例 第2章 その131【リアルタイム描画㉕】

スレッド以外で処理分散を検討。 マルチプロセスでやれば分散できるかもしれない。 マルチプロセスを実現するにはプロセス間通信が必要。 Queue、Pipe、共有メモリとあるが、今回はPipeを使用してみる。 ただし、通常の文字列送信方式ではなく、バイナリ方式。 文字列方式は型を維持できて便利だがオーバーヘッドが大きい。
事例

【PyFMI】最小構成のMBD事例 第2章 その130【リアルタイム描画㉔】

描画を止める以外で負荷低減方法を検討してみた。 スレッドの利用案が出たが以下の理由で不可。 GIL(Global Interpreter Lock)仕様の影響で期待するスレッドのコンテキストスイッチにならない。 よって、負荷はほぼ減らない。 下手したら増える可能性もある。 というわけで対策としては見送り。
事例

【PyFMI】最小構成のMBD事例 第2章 その129【リアルタイム描画㉓】

前回の負荷を安定化する方法を検討。 描画に処理時間を持っていかれているっぽからpauseで描画だけ停止していた。 案の定、負荷安定化。 上記より、フェーズを分けた利用法が考えられる。 デバッグフェーズは波形を見ながら。 ある程度デバッグが完了したら波形無しの高精度状態で検証する。
事例

【PyFMI】最小構成のMBD事例 第2章 その128【リアルタイム描画㉒】

修正コードでとりあえず動作させてみた。 問題無く動作した。 負荷確認実施。 カクついているが人間の操作のせいの可能性もある。 sin波の自動入力で確認。 やはりカクついている。 よって、操作の問題ではない。 CPU負荷を見て、さらにmatpotlibの波形拡大で詳細確認。 FMU処理以外の処理負荷大きそう。
事例

【PyFMI】最小構成のMBD事例 第2章 その127【リアルタイム描画㉑】

実験用Pythonコードのクラス化。 基本、関数横断変数をメンバ変数にした。 つまり、メンバ変数になっているものが暗黙的なグローバル変数だった。 「実はグローバル変数だったのかー!」ってのはあるある。 前回と同様の動きはしていそうなので、このコードをベースに実験を継続する。 特に負荷関連が残っている。
事例

【PyFMI】最小構成のMBD事例 第2章 その126【リアルタイム描画⑳】

現状のソースコード確認。 暗黙的なものも含めてグローバル変数が点在している。 GUIイベントとかタイマハンドラで関数が分離しているので仕方ない面もある。 折角なのでクラスとしてまとめてみようと試みる。 基本的なロジックは出来ているのでそれほど修正時間はかからない見込み。
事例

【PyFMI】最小構成のMBD事例 第2章 その125【リアルタイム描画⑲】

現状のコードで動作確認をしてみた。 FMUの波形表示OK。 Scaleで指令値変更OK。 まだ以下の課題が残っている。 ソースコードがちょっとヤッツケ。 負荷関連の評価が出来ていない。 実際の負荷状態。 描画処理の影響有無の評価。 なんとなく現状でも負荷の影響が見え隠れはしている。