[Ikeda, Yamamoto-san, Miyo-san]

K-Log#17079のDAQエラーの調査をおこなった。

1.PAYLOADとTOWERの切り分けを行う。
 K-Log#17079でDAQエラーが発生したファイルを使い再度インストールを行った。
 PAYLOAD_MASTERを更新
 optic: ETMX, ETMY, ITMX, ITMY, BS, SRM, SR2, SR3, PRM,PR2,PR3
 => 問題なく更新できた。

 GitID: release/0.1.9
 GpsTime: 1308021324

ETMXPのCPU_METER_MAXが38->37に少し小さくなった。
=> これの影響は不明。しかしDAQ再起動の度に時間の変動があるのでこれは仕様と思われる。s

以下の確認作業はここをセーブポイントして作業を行った。

2.次にTOWERモデル更新は行わずに、TOWERモデルでエラー発生時のDAQのiniファイルを上書きして不具合発生有無を確認した。
=> PRMT,PR2Tの更新では問題は発生せず、PR3Tの更新が終わったところでDAQエラーが発生した。
発生頻度は1-2分間隔でtiming errorが発生する。

3.DAQエラーが発生する状態でmasterからPRMT,PR2T,PR3TのコメントアウトしてDAQを再起動してみた。
=> エラー発生状況は変わらなかった。
　masterファイルから問題のあるiniを外しても不具合の発生状況が変わらないのでDAQ側の問題ではないと考えられる。

4.masterとiniファイルを上記1の後の状態に戻した。 

5.上記3から問題はFrontEnd側で発生していることが分かった。
 TOWERモデルが2KでDAQの出力が256,512,1024とレートが異なるのが原因ではないかと推測。
 不具合が発生したDAQのiniファイルで変更したチャンネルのレートを全て次の値にして比較を行った。
  全て2K: 10数分待ったがエラーはなかった
  全て1K: 12分後にDAQ timingerrorが１回発生
  全て512: 1-2分間隔でtiming errorが発生する。これは上記2と同じ間隔となった。
  全て256: 7-9分間隔でtimingerrorが２回発生

最後に上記1の時点のTOWERのiniファイルに戻した。

上記から分かったこと。
・DAQ Timing errorの発生はFrontEnd側で発生している。DAQは影響がない。
・Payload(16K)モデルは問題が発生していない。
  Tower(2k)モデルで問題が発生する。
・PRM,PR2,PR3を2K以外でDAQを使用するとDAQ Timing errorが発生する。
  ただしデータレートが512の場合が頻度が高い。
・PRM、PR2、PR3以外の組み合わせは今日は確認できていない。（作業時間切れ）

---
[Ikeda, Yamamoto-san, Miyo-san]

I investigated the DAQ error in K-Log#17079.

1. Isolate whether the problem is with PAYLOAD or TOWER.
 Installed again using the file that caused the DAQ error in K-Log#17079.
 Update PAYLOAD_MASTER
 optic: ETMX, ETMY, ITMX, ITMY, BS, SRM, SR2, SR3, PRM, PR2, PR3
 => Updated without problems.

 GitID: release/0.1.9
 GpsTime: 1308021324

ETMXP's CPU_METER_MAX is now a bit smaller, 38->37.
=> Not sure how this affects it. However, this seems to be a specification since the time fluctuates every time I reboot DAQ. s

I used this as a save point to do the following checks.

2.Next, without updating the TOWER model, I overwrote the ini file of DAQ at the time of the error occurrence with the TOWER model and checked whether the problem occurred or not.
=> No problem occurred when updating PRMT and PR2T, but DAQ error occurred when updating PR3T was finished.
The frequency of occurrence of the timing error is every 1-2 minutes.

3.I commented out PRMT, PR2T and PR3T from master and restarted DAQ with DAQ error.
=> The error situation did not change.
　I removed the problematic ini file from the master file, but the error status did not change, so it is not a DAQ problem.

4.Returned the master and ini files to the state after 1 above. 

5.From the above 3, I found out that the problem was occurring on the FrontEnd side.
 From the above 3, I guessed that the problem occurred on the FrontEnd side, because the TOWER model is 2K and the DAQ output rate is different from 256, 512, 1024.
 I set all the rates of the channels I changed in the ini file of the DAQ where the problem occurred to the following values for comparison.
  All 2K: waited 10+ minutes, no error
  All 1K: 1 DAQ timingerror after 12 minutes
  All 512: timing error occurs every 1-2 minutes. This was the same interval as 2 above.
  All 256: 2 timing errors occur every 7-9 minutes

Finally, I reverted to the TOWER ini file as of 1 above.

What I found out from the above.
DAQ Timing error occurs on the FrontEnd side, DAQ is not affected.
Payload (16K) model has no problem.
  No problem with Payload(16K) model, problem occurs with Tower(2k) model.
DAQ Timing error occurs when using DAQ with PRM, PR2, PR3 other than 2K.
  DAQ timing error occurs when using DAQ with PRM, PR2 and PR3 other than 2K, but the frequency is high when the data rate is 512.
The combination other than PRM, PR2, and PR3 has not been confirmed today. (Work time is up)