---+ Dec2016 FNAL Test Beam Log back to FermilabTestbeam <br />%TOC% ---++ 12/4 * ドミトリーの鍵の受け取り@Communication Center * Fermi Test Beam Facility(FTBF)の下見 * 行なうべきWebトレーニングのうち終わっていないもの(Radiological Workerなど)の消化 ---++ 12/5 * Fermilab IDを取得<br /><br />User's Officeにてパスポートと海外保険の証明書を提示→承認メール受信→Key and ID Officeにて写真撮影し交付<br /><br />※海外保険は必ず入っておくこと。また、クレジットカード付帯のものは証明書発行まで1週間ほどかかる上に保障額が少ない。出張費扱いになるので必ず入るように。<br /><br />なお、緊急の場合、出国後でも加入できる保険がある。( https://www.worldnomads.com/travel-insurance/ )<br /><br /> * 届いている荷物を回収、確認<br /><br />EMSで11/28に送ったもの以外は届いていた。<br /><br />EMS日本郵便追跡番号リスト EJ228871277JP EJ228871246JP EJ228871285JP EJ228871263JP [[EJ228871229JP][EJ228871229JP<br /><br />]]12/5 13:16に届いていることを確認<br /><br /> * 借りるべきものの手配<br /><br /> * SVX4 telescope, FEI-4, FE65p2のintegration ---+++ *TLU* * LVDS以外は動作確認(LVDSは確認手段がないので、とりあえずFE65のアダプターカードにはLVCMOSを入れている)。 * 磁場テストのFirmwareを改造。扱う信号とdaughter card分の信号を拡張および変更した。TriggerをエミュレートしてTriggerを配るテストを実施。 * SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。<br />矢島さんに相談。<br />結局、Triggerのレートを上げることでこの問題は解消した。 * FE65 Adaptor cardへLVCMOSレベルの信号を配り、extriggerでの動作確認を実施。<br />→Triggerに反応していない模様。<br />→Trigger INとOUTが逆になっていた。FirmwareをTimonに修正してもらう。<br />→Triggerに対する反応を確認。<br />→ただしBusyが見えない。Firmware段階でのミス。 ---+++ HSIO2 ---+++ SVX * SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。<br />矢島さんに相談<br />→SEABAS2のBUSY信号が原因。<br />Preamp reset(2usec)とパイプラインリセットの長い信号が出ていることが原因。<br />特にパイプラインリセットの長い方のBUSY信号に引っかかっている。<br />これはBUSY信号がトリガーレートに同期してしまっているため。<br />トリガーレートを例えば100Hzや200Hzにするとこの問題は解決した<b>。</b> * 上記の問題に関して、SEABAS2のファームウェア上でPreampリセットをOFFにする機能がある。<br />top.vのL720で、SetPerstVetoParam()からリセットの長さを指定できる。 <br />top.vのファイルはsctjdaqp/FPGACodes/TLUの中にある。要求があれば対応可能。 * Daughter Boardは3.3Vで良いのか?(SVXの仕様上は2.5Vだが)<br />→良い。レギュレータで調整している。3.4VくらいまではOK。<br />わざわざ3.3Vと高くしているのは、レギュレータがヘタっているため(by矢島さん) ---++ 12/6 ---+++ TLU * 宇宙線を用いてMPPCが4つ全て動作すること、正常にcoincidenceが取れNIM信号が発行されていることを確認した。線源欲しい。 ---+++ HSIO * TriggerはNIM1,2でBusyはNIM3,4となっている * Busy信号は200nsec程度 * Cosmic GUiをExt Triggerで動作確認 → 1kHzでイベントが進むことを確認 ---+++ SVX * SEABAS2に入れる、TLUからのタイムスタンプ用のクロックはNIMの100kHzクロックにする。<br />この際ズレることは考えられてはいない。 * SCTJDAQのオンラインプロットのヒストグラムのデータを処理するPostProcessingを使えるようにした。<br />細かく言うと、オンラインプロットの結果は一時的にsvx_ana.rootという名前で保存されるが、リネームせずに次のRUNを走らせると上書きされてデータが消えてしまう。そこで、リネームする機能をpostProcess.pyによって実装している。<br />pythonスクリプトが不必要なファイルを読み込もうとしてTracebackを出し続けていたが、修正して正しく動作するようにした。 * 解析プログラムhitmakerでのスレッショルドの値の設定が気になっている。hitmakerの出力ファイルが空であったため。<br />telehitmakermethod.cppのなかでスレッショルド決めている。L158のIsOverThreshold()あたりを探る。 ---++ 12/7 ---+++ セットアップ * ビームテストに必要なものをビームラインへ移し、組み立てた * inspectionが行われ、受理された * ネットワーク環境<br />ビームラインの隣にSw-Hubを設置し、各FPGAを接続。イーサネットケーブルはビームラインの隣の壁面状のPatch Panelに接続(P1Q1)<br />Control Roomへ繋がっており、室内のPatch PanelからSw-Hubへ接続。このSw-Hubから各DAQ PCへと繋がっている。<br />IP Adress | *name* | *IP adress* | | KEKSiPC (Main DAQ) | 192.168.7.15 | | atlassi01 | 192.168.7.77 | | atlasj | 192.168.7.43 | | SVX PC | 192.168.7.22 | | Raspberry pi | 192.168.7.35 | <br /><br /><br /> ---+++ HSIO * HSIOの番号の対応 * <p>HSIO module Chip</p> * <table border="1" cellpadding="0" cellspacing="1"> <tbody> <tr> <td>HSIO</td> <td>module</td> <td>chip</td> </tr> <tr> <td>A0</td> <td>KEK83</td> <td> </td> </tr> <tr> <td>A1</td> <td>KEK114</td> <td>4</td> </tr> <tr> <td>A2</td> <td>KEK101</td> <td>2</td> </tr> <tr> <td>A3</td> <td>KEK104</td> <td>3</td> </tr> <tr> <td>A4</td> <td>KEK113</td> <td>1</td> </tr> <tr> <td>A5</td> <td>KEK113</td> <td>2</td> </tr> <tr> <td>A6</td> <td>KEK113</td> <td>3</td> </tr> <tr> <td>A7</td> <td>KEK113</td> <td>4</td> </tr> <tr> <td>B0</td> <td>KEK115</td> <td>1</td> </tr> <tr> <td>B1</td> <td>KEK115</td> <td>2</td> </tr> <tr> <td>B2</td> <td>KEK115</td> <td>3</td> </tr> <tr> <td>B3</td> <td>KEK115</td> <td>4</td> </tr> <tr> <td>B4</td> <td>KEK112</td> <td>1</td> </tr> <tr> <td>B5</td> <td>KEK112</td> <td>2</td> </tr> <tr> <td>B6</td> <td>KEK112</td> <td>3</td> </tr> <tr> <td>B7</td> <td>KEK112</td> <td>4</td> </tr> </tbody> </table> * このうち使うのは、KEK83(single chip), KEK114(RJ4), KEK101(RJ2), KEK104(RJ3), KEK113(RJ2), KEK115(RJ3), KEK112(RJ3) である。 ---+++ SVX * ビームライン上への設置は終了。 * リモートコントロール環境が整った。<br />SEABAS2 ←→ Sw-Hub ←→ Patch Panel ← | → Patch Panel ←→ Sw-Hub ←→ SCTJDAQ PC * Control RoomからSVXとの通信環境は確立した。configは通っているので接続は大丈夫と判断する。 * Timestamp用100kHzクロック信号のNIMケーブルはまだ挿さっていない。<br />他のDAQはTimestamp情報を付与しないようなので、SVXのみTimestampをつけることにしたい。 ---++ 12/8 ---+++ Summary ---++++ HV settings | *Sensor* | *HV source* | *GPIB Adress* | *cable #* | | FEI4 | 6517 | 28 | A4 | | FE65 | 6517 | 29 | A2 | | MPPC | 2410 | 24 | A3 | | SVX | 2410 | 10 | A1 | ---+++ LV settings ---+++ TLU Trigger Logic | *Signal* | *Connector* | *comment* | | MPPC Trig 0 | | - | | MPPC Trig 1 | | - | | MPPC Trig 2 | | - | | MPPC Trig 3 | | - | | ROI Trig HitOr | | - | | Trig for HSIO2 | | - | | Trig for SPEC | | - | | Trig for SVX | | | | Busy from HSIO2 | | | | Busy from SPEC | | | | Busy from SVX | | | | LVCMOSout1 | LVCMOSout1 | | | LVCMOSout2 | LVCMOSout2 | picoscope A | | LVCMOSout3 | LVCMOSout3 | picpscope B | | LVCMOSout4 | LVCMOSout4 | picoscope C | ---+++ HSIO ---+++ SVX * 9時ごろ、HDDの容量が残り少ないので,外付けHDDに一部データのバックアップを実行。 * 午前中、SVXの動作確認テストを行った。SCTJDAQではなくtele_softを使用。<br />configが本当に通っているのか、ペデスタルの設定を変えて見て変化が現れるかをチェックした。<br />1208_optest : 適当に走らせたデータ。動作チェック。<br />1208_optest_2 : Telescope No.0のRampRngを000に設定。ペデスタルの値40程度。<br />1208_optest_3 : Telescope No.0のRampRngを010に設定。ペデスタルの値90程度。<br />1208_optest_4 : Telescope No.0のRampRngを001に設定。ペデスタルの値65程度。<br />1208_optest_5 : Telescope No.0のRampRngを011に設定。ペデスタルの値128程度。 * 午後、気になっていたHV Currentの再チェック。<br />壊れている可能性があるTelescopeはNo.2<br />保護抵抗なしでDirectにHVをかける。<br />No.2 TelescopeのHVケーブルを外す → I < 3μA at 80V<br />No.2 TelescopeのHVケーブルを接続 → 10VでCurrent Limitを超える。limit値の105μA以上流れ始める。<br />→ No.2 Telescopeが確実に悪い。 * No.2 Telescopeを取り外してワイヤーボンドを顕微鏡で確認した。<br />Rear側センサーとASICの間のボンディングがぐしゃぐしゃ。前に山元くんがここから8本ピンセットで外した。ただしここはHVとは直接関係しない場所である。 * 花垣さん、No.2 TelescopeのRear側センサーのHVワイヤーボンドをカッターナイフで切断。 * その後、10Vかけたところで結局105μA以上流れてしまって先ほどと結果が変わらない。センサーのどこかに異常があるのは確かだと思われるが詳しい原因はこの時点では不明。 * (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。 <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> * 残り3枚のTelescopeのHV Currentをチェック。HVケーブルには保護抵抗が入っている。<br />Current Limitは10μAに設定。 | HV[V] | Current[μA] | | 10 | ~1 | | 20 | ~1.2 | | 40 | ~1.3 | | 80 | ~1.6 | 大体以前のビームテストの時と同じようなCurrentで、流れすぎるという問題は起きていない。 * (18:00頃)残りのテレスコープ3枚でDAQを走らせることを考え始める。 * 4枚の時のままのconfigをそのまま通すとERROR。そのままではダメなようだ。DaughterBoadのフラットケーブルの位置を変えても同じ。 * ---++ 12/9 ---+++ SVX * テレスコープ3枚でDAQを走らせることが可能に。死んだと思われるNo.2 Telescopeは調査できるようになった。<br />解決方法はsctjdaq/SVXTools/tele_soft/include/svxcommon.hのTELESCOPE_NUMを書き変えること。<br />4枚に戻すとき、あるいは5枚以上追加するときもこの部分をいじることで対応できる。 ---++ 12/10 ---+++ 山元より Cooling BoxとSVXのGas flowについて シフターのすべき事をまとめました  [[http://osksn2.hep.sci.osaka-u.ac.jp/~yamamoto/Dec2016_FNAL_TB/][gas operation]] *次回のタンク交換は12/12月曜日午前中です。* --- ---+++ TLU 現状:ROI triggerも受けられるようなFirmwareのエミュレートが完了。 *have to do list* * SiTCP 経由でdataをよむ。(タイムスタンプ付きで) * runのstart stopを統合する。現在のままでは各DAQシステムのスタートを揃える為には、全てのDAQを開始した状態でFirmwareをやくという手段を取らざるをえない。 * Tree形式で Event Number, Hit point(x, y), の情報を持ったファイルを出力しそれらを読み込んでEvent displayを作る。 <p> </p> ---+++ HSIO 現状:12/9にtuningが完了し特に問題が見られなかったのでMaskし始めた。 問題点:Noiseが全体に広がる問題が起こり、全てのchでMaskされる可能性がある。 方針:HV, 温度などの条件が変わるとtunigし直さないといけない。 12/7のlogにまとめてある表のうち、使用するチップは <b>KEK114(RJ4), KEK101(RJ2), KEK104(RJ3), KEK113(RJ2), KEK115(RJ3)</b> となった。 ---+++ SVX 現状:Mask Scan, Threshold Scan完了。 online monitorを作るためのrootファイル(Tree)の出力を試みた。 問題点:run中にTreeConverterを走らせるとDAQが止まる。 16:40頃から、特に操作せずともDAQが止まる問題(18:34〜Meeting中に問題が再現するか確認。40秒ほどで止まる事が2回中2回確認された)が生じた。 TCPの接続が不安定な事が原因(?) 方針:SVXのDAQ PCをビームラインにおき、SVXのSEABAS2をDAQ PCに直接つなげる。 ---+++ FE65 現状:500eでtunig完了。 問題点:noise scanにおいて、leakage current compensationがないところでnoiseが多い。 方針:極めてnoisyなpixelのみMaskをかけるようにした。 ---++ 12/11, 12/12 ---+++ beam status *今年中にFTBFエリアにビームが出る可能性は極めて低い。* ビームを曲げるためのワイヤが切れたことが主な理由である。 ワイヤの交換を行うにはビームを止める必要があるが、DOEの要請からニュートリノ実験のためにビームは止めることができないとのこと。 ---+++ TLU 現状:TimeStampを発行し、各検出器でEvent Numberのずれがないかを確認するため、SVX以外にもTimeStampを配れるように変更。 問題点:書き込みに時間がかかるため現在のtriggrt rateの1 kHzに追いつかない。 方針:rootファイルへの書き出しをやめてbinaryファイルにすることでこの問題を解消する。 ---+++ HSIO * HSIOからのデータをオンラインモニター用にCnvertするようにプログラムを書き換え中。 * 解析プログラムの雛形は完成した。 * Cosmic GUIは走らせ続けている。 * Thresholdは昨日から安定している。以前にThresholdが崩れた(ダブルピークになるなど)のはHV環境が原因と推測。 ---+++ SVX * 12/10のlogにあるDAQが止まる問題は、SVXとの接続を変更することで解消。<br /><br />DAQ PCとSEABAS間のEthernetケーブルの長さの問題、またはSwitching HUBが原因と推測。<br /><br />優先度はともかく、この推測を確かめるテストを行う予定。<br />TreeConverterをDAQ中に走らせるとDAQが止まる問題は、datファイルにread accessすることが直接的な原因ではないことがわかった。<br />おそらく、ConvertすることでSVXとDAQ PC間の通信に負荷をかけることになるのでDAQが止まったのだと推測した。<br /><br /> * オンラインモニター用のデータ出力を可能にするよう編集中。<br />datファイルにする前の段階で hitch や pipelineIDをFillしている行があるので、そこで標準出力またはテキストファイルに書き込みできるように編集する方針。 ---+++ FE65 オンラインモニター用のデータ出力のためのConverterは準備完了。 ---+++ Gas flow およそ見積もり通りであったが、12/12 9:08~17:28までほとんどN2タンクの残量が変わっていないことが疑問である。 それまでの残量の記録をまとめる。 <table align="center" border="1" cellpadding="0" cellspacing="1" style="border-color: #0ae2f4; border-width: 1px; height: 317px; width: 1085px;"> <tbody> <tr> <td>記録時間</td> <td>TUBE3 残圧(N2タンク1次圧)</td> <td>TUBE8 残圧(N2タンク1次圧)</td> <td>comment</td> </tr> <tr> <td>12/9 18:03</td> <td>10.9 MPa</td> <td>14.6 MPa</td> <td>TUBE3のみOPEN 流量は3 SCFH~1.5 L/min</td> </tr> <tr> <td>12/10 10:23</td> <td>8.4 MPa</td> <td>14.6 MPa</td> <td> </td> </tr> <tr> <td>12/11 10:31</td> <td>4.7 MPa</td> <td>14.6 MPa</td> <td>10:50頃CMSのグループから流量を下げるよう言われたので、1.75 SCFH~0.9 L/minに変更。</td> </tr> <tr> <td>12/11 12:27</td> <td>4.6 MPa</td> <td>14.6 MPa</td> <td> </td> </tr> <tr> <td>12/11 17:05</td> <td>4.2 MPa</td> <td>14.6 MPa</td> <td> </td> </tr> <tr> <td>12/12 9:08</td> <td>2.7 MPa</td> <td>14.4 MPa</td> <td> </td> </tr> <tr> <td>12/12 15:21</td> <td>2.6 MPa</td> <td>14.4 MPa</td> <td>ほとんど減っていないので、 12日にタンク交換予定であったが13日に変更。</td> </tr> <tr> <td>12/12 17:28</td> <td>2.6 MPa</td> <td>14.4 MPa</td> <td> </td> </tr> </tbody> </table> SVXのHVカレントはほとんど安定しているので、N2 flowとしては 1.75 SCFHで十分だと判断した。 HV:80 V, ~2 uAに対して、LV:3.3 V, ~4Aであるので、発熱量としてはLVが優勢である。 実際、12/11 19:51から行ったSVX DAQ長期安定テスト中は、0.3uAほど(10%強)HV currentが増えている。 ---++ 12/13 ---+++ FE65 温度-25degCで再チューニング Thresholdを下げようとするとanalogの応答が返ってこなくなるピクセルが多数<br />→ PrmpVbp を100にあげることで解決(以前Timonから頂いたアドバイス) 500eでtuning成功 データ:<br />digital 123<br />analog 121<br />threshold 122<br />tuning 120<br />noise 125 ---+++ SVX * SCTJDAQにオンラインモニター用にバイナリデータをデコードしてrootファイルを作る部分を参考にして、テキストファイルで出力することを試みている。<br />sctjdaq/SVXTools/tele_soft/src/logger.cpp<br />sctjdaq/SVXTools/tele_soft/include/logger.h<br />に関数を追加。<br />動作テストをするにはSCTJDAQをコンパイルしてDAQを再試行しながら見る必要がある。<br />DAQが遅くなるようならば別の方法を考える。<br />例えば、ファイルの更新があることを毎回判定してバイナリデータをデコードして保存する等。やり方は調べないといけない。 * 上の方針はやろうとしていることに合わない。現状のTreeConverterにgetterメソッドを追加する程度で良い。 ---++ 12/14 ---+++ beam status ---+++ TLU ---+++ HSIO ---+++ FE65 ---+++ SVX * OnlineMonitor 用にバイナリデータのデコーダを書いている。設計方針はfixされた。<br />確認のために書いておくと、EventNumber, Timestamp, hit ch X, hit ch Y, adc, pipelineIDのデータを出力して、他の検出器とのCorrelationを同時に見られるようにすること。 * class SVXconverter {<br />private:<br /> string filename;<br /> ifstream infile;<br /> int xx;<br /> int EventNumber;<br /> <p>public:<br /> SVXconverter(string filename);<br /> ~SVXconverter();</p> <p>void GetAnEvent (int &eventnum, int *xx);<br /> void GetEvent (int EventNumber);<br /> void GetNextEvent ();<br />};<br />のようなテンプレートクラスに沿って設計。現在のTreeConveterとは異なるが、getterはひとまず実装済み。<br />イベントナンバーを指定してイベント情報をgetできるようなメソッドを実装する。これが結構難しいというか面倒な部分。</p> [Remain Task] * LANケーブルの長さ?によるTCP connectionエラーの再現性のチェック * 死んだNo.2 SVX Telescopeの原因調査 * 解析プログラムTestBeamAnaの改良。 ---+++ Gas flow 流量とタンク残圧に関するまとめ。 [[http://osksn2.hep.sci.osaka-u.ac.jp/~yamamoto/Dec2016_FNAL_TB/gas_tank_summary.pdf][gas_tank_summary]] ---+++ Cooling box 環境 box内の温度、湿度、気圧に関する簡単なまとめ。 [[http://osksn2.hep.sci.osaka-u.ac.jp/~yamamoto/Dec2016_FNAL_TB/coolingbox_enviroment.pdf][cooling_enviroment]] ---++ 12/15 ---+++ beam status ---+++ TLU ---+++ SVX * SEABAS2とSCTJDAQ PCとのTCP connection errorの原因調査を行なった。<br />[ [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161215/20161215_TCPconnection_003.png][安定している環境]]]<br />8ポートのうち、PATCH PANEL;SCTJDAQ PC;KEKSiPC;RaspberryPiが接続されている。<br />2本は先に何も繋がっていない、テスト用ポート。<br />[ [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161215/20161215_TCPconnection_001.png][構成1]]]<br />SEABAS2をSw-Hubに、SCTJDAQ PCもSw-Hubに接続した。<br />この時のSw-Hubはビームホール内の物(阪大から持参)である。LANケーブルの長さは2本とも7m程度のものである。<br />SVXのデータはSCTJDAQ PCの外付けハードディスクに保存され、これをKEKSiPCから見られるようにNFSクライアントを立ち上げて参照できるようにしている。<br />そのため、SEABAS2とSCTJDAQの2接続が必要になるのでSCTJDAQ PCから2本のLANケーブルを伸ばしている。なお、ethernetポートが1つしかないので、SEABAS2にはLANポートを、共有NetworkにはUSB Ethernet Adapterで接続している。<br />[結果1]<br />上の状況では、SCTJADAQ PCとSEABAS2のTCP connectionの確立までに10秒程度時間がかかる。<br />11:20にDAQをstartしたが、その3分後イベントが増えなくなる。TCP connectionが途切れる。この時約42000eventsほど。<br />[ [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161215/20161215_TCPconnection_002.png][構成2]]]<br />共有Networkに接続せず、Sw-Hubのみ経由でSCTJDAQ PCとSEABAS2を接続する。<br />[結果2]<br />TCP connectionは意外にもあっさり通った。<br />11:24にDAQをstartした。1分後TCP connectionが途切れた。<br />[結論]<br />Sw-Hub経由でSCTJDAQ PCとSEABAS2との通信を行うと、通信が不安定になることがある。<br />[考察]<br />Sw-Hubを介すると通信が不安定になるのはなぜか?<br />一つ考えられるのはrootingの不具合。なぜおこるのかはハブの仕様を知らないとわからない。<br />また、SOIグループではSEABAS2をSw-Hub経由でDAQ PCと通信しているが、このような通信の不安定性は見られないという。<br />ファームウェアの問題という可能性もあるが、これは調査に知識と時間がかかる。<br />何が問題かはもう一度阪大で精査する必要がある。<br />[問題の回避策]<br />SEABAS2とSCTJDAQ PCは直接イーサネットケーブルで接続するようにする。 * OnlineMonitor の開発<br />SCTJDAQで出力されるバイナリファイルのデコーダを開発中。EventNumberを引数にすればそのイベントの情報を出力するメソッドは実装したがデバッグがまだ必要。<br />telescopeごとにhitchとadcの値を出力するが、全部同じになってしまっているバグ。早く直す。<br />今のところバイナリデータを前からreadしながらストリームの位置をシークしているが、イベントヘッダからイベントデータサイズ(byte単位)のみ取得してその分だけストリームの位置をシークするようなコードの方がスマートな気がするので、動作速度に問題、余裕があればその方針でも考えて見る。<br /> [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161215/SVXconverter.hh][SVXconverter.hh]](未修正版)<br /> <p>[Remain Task]</p> * 死んだNo.2 SVX Telescopeの原因調査 * 解析プログラムTestBeamAnaの改良。 ---+++ Gas flow 流量とタンク残圧に関するまとめ。更新しました。 [[http://osksn2.hep.sci.osaka-u.ac.jp/~yamamoto/Dec2016_FNAL_TB/gas_tank_summary.pdf][gas_tank_summary]] ---+++ Cooling box 環境 box内の温度、湿度、気圧に関する簡単なまとめ。更新しました。 [[http://osksn2.hep.sci.osaka-u.ac.jp/~yamamoto/Dec2016_FNAL_TB/coolingbox_enviroment.pdf][cooling_enviroment]] ---++ 12/16 午前:Fermilabのピクセル開発グループの研究室ツアー 午後17時以降:SeaQuest実験の施設見学 ---+++ TLU ---+++ SVX * SCTJDAQ PCとSEABAS2の通信の検証<br />外川さんと小野さんが居るのでいろいろ聞いてみました。<br /><br />設定<br />IP address<br />- RaspberryPi: 192.168.7.35<br />- SCTJDAQ PC: 192.168.7.20<br />- SVX SEABAS2:192.168.10.16(デフォルト)<br />- KEKSiPC: 192.168.7.15<br />- TLU SEABAS2:192.168.7.16<br /><br />一つのハブに上の全てを集約した状態[ [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161215/20161215_TCPconnection_001.png][構成1]]]。<br />まず、SCTJDAQ PCが192.168.10.16と通信している時、つまりDAQが走っている時に、<br />sshで192.168.7.xと通信しようとすると、観測したところでは必ず通信が止まることを確認した。<br />システムログを見ても,パケット受信量は止まってから増加していない。<br />外川さん曰く、192.168.10.x系列と通信している時に、192.168.7.x系列が入ってくることが問題ということだそうです。<br />それが原因なら、突然通信が止まったという前日の記録を説明するには、止まった時に192.168.7.xと何らかの通信があったと考えるべき。NFSで共有ディレクトリを作っていて、そこに192.168.7.x系からアクセスがあるとまずいのか?<br /><br />じゃあ全部192.168.10.x系列に揃えてしまえばいいのでは?となるが、TLUのSEABAS2とSVXのSEABAS2のIPがデフォルトのもので重複しているのでSVX SEABAS2のIPアドレスをEEPROMに書き込まれた値に変える必要がある。SEABAS2はデフォルト値(192.168.10.16)か、EEPROMに書き込まれた値(?)のどちらを使うかをジャンパーピンで変更できるので、重複させないためにはEEPROMに書き込まれた値の方を指定すれば良いということ。<br /><br />ですが、その値が不明で矢島さんに聞いている途中。<br />pingで192.168.10.xxxを255通り試したが届いてない状態。<br />もしもIPアドレスが192.168.10.16しか設定されていないのなら、一つのハブにSEABAS2を直接つなぐ構成はやはりやめたほうがよさそう。 ---++ 12/17 ---+++ TLU ---+++ SVX * SEABAS2のEEPROMにセットされたIPアドレス情報を得るためには、内部レジスタにUDPでアクセスすれば良いとのこと。<br />アクセスするにはsctjdaq/SVXTools/tele_soft/src/comm.cppの中の関数<br />int Comm::read_udp_data(unsigned int address, unsigned char* data, int array_size, int length, int output)<br />を使えば良い。<br />第1引数:最初のアドレス、第2引数:1byte情報を詰める配列へのポインタ、第3引数:配列要素数、第4要素:読み込むバイト列の長さ、第5引数:出力関係<br /><br />間違ったアドレス空間を読んでいたので、後日やり直しする。<br />そもそもなんで記録されていないんだろう。<br /><br /> * SiTCP Utilityを使ってアクセスしてみる。<br />デフォルト: [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161217/DSC_0515.JPG][写真]]<br />EEPROM: [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161217/DSC_0516.JPG][写真]]<br />デフォルトの情報は納得できるが、EEPROMの情報はうーん?ソフトウェアの実装方法を知らないのでなんとも言えない。<br /><br /> * [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161217/SVXconverter.hh][SVXconverter.hh<br />]]テレスコープごとのhitchとadc valueを表示できるようにした。<br /><br /> * ネットワーク接続問題は何もできていない。 ---++ 12/18 * 実働時間2時間ほど ---+++ SVX * SVXconverter.hhの整備をした。 ---++ 12/19 11:00〜12:30 徳武さん空港送り 13:00〜14:00 FNAL打ち合わせ 15:00〜17:30 g-2、D0の測定器見学 ---+++ SVX * SVX4に使っているSEABAS2の固有MACアドレスとIPアドレスは何だろう問題<br />(発端は、TLUのSEABAS2とIPアドレスが被っている事による。KEKのSEABAS2はデフォルト) * UDP通信でEEPROMにアクセスできるので、書き込まれている値を見に行く事ができる。<br />→Software側、SVXTools/tele_soft/src/util.cppに以下のように追加して確かめる。<br /> <p>MAC ADDRESS: ff:ff:ff:ff:ff:ff<br />IP ADDRESS: 192.168.10.111<br /><br />MACアドレスはおかしい。IP ADDRESSの値はそれっぽいが、実は昨日SiTCP utilityで書き換えした値で、元々は255.255.255.255だったもの。<br /><br /></p> * J7ジャンパーピンを抜くことで、Default Mode(MACアドレス:02:00:C0:A8:00:10、IPアドレス:192.168.10.16)からEEPROMに書き込まれている情報を使うモードを切り替えられる機能がある。 * 以下、SEABAS2とPCはダイレクトで接続されている状態での話です。 * SEABAS2のJ7ジャンパーピンを抜くと、PCとSEABAS2との間のコネクションが取れなくなる。Linuxから見えない。Ethernetに何も挿さっていないように見える。<br />・PC側のネットワーク設定が間違っているから見えないということが原因では無い。<br />・SEABAS2の赤色LED(通常TCP通信ができていると早く点滅(0.5Hzくらい?))が遅い周期(1Hzくらい)で点滅。<br /> SEABAS2がそもそもEthernet通信をしようとしていないとの小野さんの見解。<br />・ジャンパーピンを抜いた状態では、LVカレントが1.819A〜1.751Aの間を1Hzくらいで振動している(@LV=3.3V)<br /> ジャンパーピンを挿した状態では、2.37A程度で安定している。<br /> この時、DaughterBoardのLVカレントは3.45Aでジャンパーピン挿していない状態と同じ値で安定(@LV=3.3V) * ジャンパーピンを挿した状態に戻す(DefaultMode)と、通常通りコネクションが取れてDAQも走る。 * SOIグループのSEABAS2を使用してSiTCP utilityで正しい情報が読めるかのテスト(12/17でSiTCP utilityの返す値が正しいかの確認)<br />設定したIPアドレス、MACアドレスにアクセスできるので、ソフトウェアは正しい。EEPROMの中身もきちんと見られる。 * SEABAS2のEEPROMの中身が何も書き換わっていない疑い、あるいは誰かが何か設定してしまった可能性? * EEPROMの中身が壊れている可能性。<br />→解決策としては、EEPROMを書き直す。<br /> SiTCP utilityでIP address、TCP Port、UDP Portは書き換えられる。<br /> MACアドレスは簡単には書き換えられない。ただ、書き換えられる方法はある。<br /> 購入したMACアドレスが保存されたbinaryファイルとBeeBeansがCDで配布しているソフトウェアを使えば書き換えられる。j-tagじゃなくてEthernetで。 * 20日朝からMACアドレスを書き込むテストを行ってみる。 * <p>[Remain Task]</p> * SVXconverter.hhにsvxの情報のみを持ったクラスを付け加える。 * 死んだNo.2 SVX Telescopeの原因調査→阪大で * 解析プログラムTestBeamAnaの改良→阪大で ---++ 12/20 DAQのIntegration Test *17:35 TLU run_number = 000008* | | Run Number | Event Number | | SPEC | 144 | 1100836 | | SVX | 15 | 100074 | | HSIO2 | 90 | 100076 | デバッグモード(1枚でもシンチが鳴ったらトリガーが出るモード)がオンになっていたのでオフにした。 *17:45 Run_number = 000009* | | Run Number | Event Number | | SPEC | 145 | 1100033 | | SVX | 16 | 100001 | | HSIO2 | 91 | 100003 | Comment: *17:50 Run_number = 000010* | | Run Number | Event Number | | SPEC | 146 | - | | SVX | 17 | 120143 | | HSIO2 | 92 | - | Comment:SPECが途中で落ちた。 *17:54 Run_number = 000011* | | Run Number | Event Number | | SPEC | 147 | 1735070 | | SVX | 18 | 157445 | | HSIO2 | 93 | 157447 | Comment:TLUがEvent Number=157413から後、値がおかしい。 *18:06 Run_number = 000012* | | Run Number | Event Number | | SPEC | 148 | 1730388 | | SVX | 19 | 157306 | | HSIO2 | 94 | 157308 | Comment:さっきと同じ。 *18:22 Run_number = 000013* | | Run Number | Event Number | | SPEC | 149 | 1730454 | | SVX | 20 | 157312 | | HSIO2 | 95 | 157284 | Comment:TLUがEventNumber=157000くらいでDAQが飛んだ。改良。 *18:40 Run_number = 000014* ゴミ。 *18:44 Run_number = 000015* | | Run Number | Event Number | | SPEC | 151 | 2200219 | | SVX | 22 | 200018 | | HSIO2 | 97 | 200020 | Comment:200000イベントより多いのは、while文を抜けてもトリガーをまだ送っていたから。<br />SVXとHSIO2は常に2イベントずれてる。SPECは11倍くらい。なんでや。 *18:56 Run_number = 000016* | | Run Number | Event Number | | SPEC | 152 | 2200220 | | SVX | 23 | 200018 | | HSIO2 | 98 | 200020 | Comment:200000イベントより多いのは、Softwareが200000イベントきたと判断してからstop信号を送るため、その間に20msecラグがあるから?<br />stop run(トリガーを止める)ならトリガーの数で決まるので良いのでは? *19:06 Run_number = 000017, TLU Ev_Num=103278* | | Run Number | Event Number | | SPEC | 153 | 1141305 | | SVX | 24 | 103753 | | HSIO2 | 99 | 103755 | Comment:SVXのイベントナンバーがHSIO2よりも2だけ少ないのは常に見えてる。これが常なら後で合わせればいい。TLUとSVX,HSIO2とが500くらいずれているのは謎。 とりあえず動くDAQはできた。とりあえず。 ---+++ MPPC 一番下流側は死んでいた。3枚線源を当てて生存確認。 ---+++ TLU ---+++ HSIO ---+++ SVX * SVX4の読み出しに使っているSEABAS2のEEPROMの中のMACアドレスを変更した。<br />MAC ADDRESS : 7C:F0:98:01:08:DE<br />IP ADDRESS : 192.168.7.20 (temporary)<br />TCP Data Port : 24<br />UDP Port : 4660 * SCTJDAQ SoftwareのIPアドレスの部分だけを変更してコンパイルしても、Iinitializeはできるがconfigを通そうとするあたりで通信先を見失う。<br />しばらく待つとsegmentation fault。 [[http://osksn2.hep.sci.osaka-u.ac.jp/~sawada/sendto/20161220/20161220_seglog.txt][ログ]]。<br />とりあえずこの件は保留。<br />他にもEEPROMの設定値を設定し直さないといけないのかもしれない。TCP command Port番号が65535のままとかが悪さをしている?<br />ソースコードを調べないとわからない。保留。 * DAQは、SEABAS2とDAQ PCを直接繋いでデータを取ることにする。 * SCTJDAQのRUN NUMBERの出力先の変更<br />(sctjdaq/gui/sctgui.pyの中で設定します。DAQはpythonスクリプトを走らせるだけなのでコンパイルは不要。)<br />変更前 : sctjdaq/gui/run_number.txt<br />変更後 : //media/SVX_TELE/svx_data/data/run_number.txt * SVXのDAQの流れ<br />1.DAQの立ち上げ<br />2.configファイルの読み込み<br />3.setupボタンを押す(initialize)<br />4.statusに全てLOADEDが表示されていることを確認する。DEAD, Noneが出たらプロセスが走っていないか通信ができていない。<br />5.configボタンを押す<br />6.statusが全てCONFIGUREDになっていることを確認する。<br />7.startボタンを押すことでDAQがスタート。statusがRUNNINGになっていることを確認する。最初のトリガーが来るまではEvent NumberとData Rateが変な値を表示しているがこれは仕様。run_numberはこの時点で+1増える。<br />8.stopボタンを押すとDAQがストップ。<br />9.この後もう一度startボタンを押すとDAQが走るかに思えるが、なぜかバグる仕様。Kill DAQボタンを押して3に戻ってください。 ---++ 12/21 <b>片付け予定日</b><br />午前中、β線源を当ててヒットマップを見てみるテスト。タイミングスキャンも。<br />午後、片付け、何を持って帰るか決める。 *Run_number = 000017 /* *Start : 20:14 20/12/2016 /* *Stop : 09:20 21/12/2016* *TLU Ev_Num = 46672186* | | Run Number | Event Number | | SPEC | 154 | 46672251 | | SVX | 25 | 46672266 | | HSIO2 | 101 | 46672271 | *Run_number = 000022 /* *11時頃 21/12/2016* *TLU Ev_Num =* | | Run Number | Event Number | | SPEC | | | | SVX | | | | HSIO2 | | | Comment:全てタイミングスキャンなし。FE65にβ線源(Sr90)を当てた場合。ヒットっぽいものが見えた。 *Run_number = 000023 /* *11時頃 21/12/2016* *TLU Ev_Num =* | | Run Number | Event Number | | SPEC | | | | SVX | 30 | 38983 | | HSIO2 | 106 | 39012 | Comment:<br />シンチのみにβ線源(Sr90)を当てた場合。ヒットっぽいものが見えた。<br />FE65以外はビームでのタイミングスキャンがやはり必要。β線源でそれをやるのは非効率的。 ---+++ TLU ---+++ HSIO ---+++ SVX * タイミングスキャン無しではやはりβのヒットは見えなかった。当然と言えば当然。 ---+++ 片付け 各グループ持って帰るものリスト * SVX<br />・冷却器以外全部。<br />参照:持ち物リスト  https://docs.google.com/spreadsheets/d/16LxTLwdshbWzZ36rONitM8Lx8_qjKItqFMtqScNHAyc/edit#gid=0<br />理由:<br />①壊れた?SVXの検証のため必要<br />②SEABAS2を、EEPROMに保存されているIPアドレスで通信できるようにさせる ---++ 12/22 <b>帰国予定日<br /><br /></b>昼ごろまでに空港に出発。 ---++ 12/30 KEK115の動作確認開始。作業ディレクトリはatlasj note(HSIO2のオレンジのシールが無い方)の ~/Dropbox/FEI4tunings/HSIO2/test20161230 CalibGui のソースにマンチェスターエンコーディングを追加→成功。 Digital test→RJ4が通らない 抜くとうまく走り特に問題は見られない。key 1 Analog test →前回のテストビームで見られた各チップの中心に広がるノイズは確認できず。下の方がちょっと汚いが状態は悪くは無い。 tuning -2400e Digital ..,ok Analog ...RJ3に応答なしピクセル多数あり あ GAが113のままになっていた(正1243)Digital Analog ...ok key=26,27 tuning ...ok th key 47 fnalのconfig fileを調査KEK115 RJ4のGAが6になっていた。 KEK113 tuning ...ok at 2400e<br />key=20 SELF_NOISESCAN下の方に筋状にノイズがひろがる →以前から見られている問題を再現した。 原因はなんだろう。 1、レギュレータ 2、エンコーディングが悪さをしてたり・・?  → 今日調べてみる 3、フレックス固有の問題? → 正月明けにフレックス以外のモジュールでレギュレータを使ってみたりいろいろ。 マンチェスターエンコーディングの部分をコメントアウトして再度コンパイルしてみる。→まったく関係なし(コードは戻した) -- %USERSIG{AtlasjSilicon - 2016-12-06}% ---++ Comments <br />%COMMENT%
This topic: Main
>
WebHome
>
FermilabTestbeamTop
>
FermilabTestbeam
>
Dec2016TestbeamLog
Topic revision: r36 - 2017-01-17 - AtlasjSilicon
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback