2008年
10月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

setup diary

2007|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|06|08|11|
2015|01|02|03|04|05|06|07|08|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|

2008-10-16 タイムアウト処理

_ RS232Cのエラー

この間、装置が暴走してしまった。その原因はまだはっきりしないが、一番状況を説明できるのが、RS232Cの読み取りで止まってしまったという可能性だ。GPIBなどでは、長い間読み取りできないと、タイムアウトエラーになるので、そのエラートラップをかけておけばよいが、RS232Cにはデフォルトではタイムアウトがない。また、パリティーぐらいしかチェックしていないので、通信ミスでうまく命令が伝わらなくても、それに気づかないで、読み取ろうとしていつまでもデータが戻ってこない。そうなると、その部分でずっとプログラムが止まってしまう。 それを防止するために、RS232Cでもtime outができるように、読み込みのmethodをこんなふうにしてみた。
def read()
  @rs.write(sprintf("L\x0d\x0a"))
  t=Thread::start{@v=@rs.gets("\x0d\x0a").to_f}
  t0=Time::now
  while Time::now < t0+1
    return @v unless t.alive?
    sleep 0.01
  end
  t.kill
  print "rs232c timeout!\n"
  @v=-1.0
  return @v
end
もっとシンプルに書ける気がするが、読み取りはスレッドにまかせて、それが終了していたらその値を返して、それがいつまでも終わらなかったら、スレッドを殺すという感じである。 これで、RS232Cのエラーは無くなるはずだが、これが本当の原因なのかはまだはっきりしないので、他の部分も調べないと。

_ 2008/11/30追記

timeoutのライブラリもあるようで、
require 'timeout'
def read()
  @rs.write(sprintf("L\x0d\x0a"))
  timeout(1){
    return @rs.gets("\x0d\x0a").to_f
  }
  rescue TimeoutError
    return -1.0
  end
end
てな感じで良いのかも。