gnuplotのフリーズについて

質問

C++で作成したプログラムでgnuplotを呼び出し、リアルタイムで描画をさせています。
データを計測しつつその変化をgnuplotのグラフで確認しているのですが、時折gnuplotの描画が止まってしまいます。
フリーズの状況は規則性がないようで、開始してすぐであったり、しばらくしてから止まったりです。
プログラム内で同時に命令しているデータの記録は継続されるので、gnuplotのフリーズのみの症状となります。

プログラムソースは長くなるのでとりあえず省きますが、プログラムの流れとしては
データをサンプリング→プログラム内で計算→cｓｖ形式で出力→ｃｓｖファイルを読み込んでgnuplotで描画
という形の繰り返しです。
動作環境はWindowsXPでプログラムはC++ Builder6で作成しました。

サンプリング間隔・描画間隔の変更、描画データの間引きなどを試しましたが改善できていません。
同様の症状、その解決策をご存じの方がいらっしゃいましたら、教えて頂けないでしょうか。
参考までに実行画面の画像を添付しました。縦軸がデータ値、横軸が経過時間です。
不足している情報などありましたら合わせてご連絡ください。
どうぞよろしくお願いします。

回答No.1

ki073 · ベストアンサー

gnuplotがデータをファイルで読んでいることが何か怪しそうです。ファイルが完全に閉じられないうちに、gnuplotが読み始めて破綻しているような気もします。
ともかくデータもパイプで渡された方が安全だと思います。
安定性とは関係ありませんが、CSVではなく空白で区切ったデータの方が良いと思います。

パイプで渡して破綻しないか試してみましたが、安定していますよ。
Windowsで同じ環境をつくるのが大変なので、Mac+Rubyでの例を書いておきます。Windowsの場合はパイプ対応のgnuplotは別になっているようなことを見た覚えがあります。

x=(0..100).collect{|a| a*0.01}
open("|gnuplot", "w"){|gp|
10000.times{
y=x.collect{|a| rand()}.sort
gp.puts "plot '-'"
x.zip(y){|x1, y1| gp.puts "#{x1} #{y1}"}
gp.puts "e"
sleep 0.1
}
}

お礼

回答ありがとうございます。

ただ、パイプでやる方法も以前試したのですが、動作はしたものの同様の症状が発生していました。
その際に「データ数が多い場合、パイプ方法よりcsv書き出し・読み込み方法の方が安定する」という話を聞いたため現在の流れにしています。

とにかくご指摘の部分を試してみたいと思います。
試行までしていただきありがとうございます。

回答No.3

ki073

sleepで改善がみられましたか。
＞ただ私のプログラムの場合、描画指令の後ではなく前でないと効果がありませんでした。
＞環境あるいはプログラム構成の違いのせいでしょうか。

多分環境でしょう。描画命令の前に入れて効果が出る方が自然なように思います。こちらはなぜか後ろに入れないと効果がありませんでした。

sleepの挿入が許される程度の時間待ちがあっても良いのでしたら、そうゆう解決法も良いのではないかと思います。
多分ディスクアクセス速度に依存するはずですので、余裕を持たせた値にしましょう。

パイプを使う方がそのような問題が出にくいので安心なのですが、環境によってパイプに起因するような問題点があるのかもしれません。

お礼

丁寧な回答、試行ありがとうございました。
頂いた回答をもとにより良いものにしていきたいと思います。

回答No.2

ki073

No.1のお礼欄をもとにもう少しテストをしてみました。
ファイルに書き出すのもやってみました。フリーズはしませんでしたが見事にデータの読み込みがおかしく警告がでます。

gnuplotの後ろにsleepを入れて待たせてやると大丈夫なようです。（gnuplotの前では効果がなかった）
どうもディスクアクセスが絡んでいるようです。パイプの方はデータ数をかなり増やしてみました問題はありませんでした。
あくまでもMacでの結果ですので、OS依存があるかも知れません。

パイプを使ったもの、正常に動きました。
x=(0..1000).collect{|a| a*0.01}
open("|gnuplot", "w"){|gp|
10000.times{|i|
gp.puts "plot '-' with lines, '-' with lines, '-' with lines, '-' with lines, '-' with lines, '-' with lines, '-' with lines, '-' with lines"
8.times{|j|
y=x.collect{|a| rand()*j}.sort
x.zip(y){|x1, y1| gp.puts "#{x1} #{y1}"}
gp.puts "e"
}
puts i
}
}

ディスクに書き出すもの、sleepが無いと駄目です。USBメモリなどに書き出すと、もっと待たないと駄目。
x=(0..1000).collect{|a| a*0.01}
open("|gnuplot", "w"){|gp|
10000.times{|i|
data=8.times.collect{|j|
x.collect{|a| rand()*j}.sort
}
data=data.transpose
open("data.txt", "w"){|fo|
x.zip(data){|x0, y|
fo.print "#{x0} "
fo.puts y.join(" ")
}
}
gp.puts "plot 'data.txt' using 1:2 with lines, 'data.txt' using 1:3 with lines, 'data.txt' using 1:4 with lines, 'data.txt' using 1:5 with lines, 'data.txt' using 1:6 with lines, 'data.txt' using 1:7 with lines, 'data.txt' using 1:8 with lines, 'data.txt' using 1:9 with lines"
puts i
sleep 0.5
}
}

お礼

試行までしていただきありがとうございます。
おっしゃるように書き出し方式でSleep関数を入れるとかなり改善しました。
詳しい知人と検討したところ「データのサンプリングと書き出し・読み込み・描画のタイミングが合っていなかったのでは？」という話が出ました。
Sleepを入れることでそのあたりが解消されるのかもしれません。

ただ私のプログラムの場合、描画指令の後ではなく前でないと効果がありませんでした。
環境あるいはプログラム構成の違いのせいでしょうか。