Dec2016 FNAL Test Beam Log

back to FermilabTestbeam


12/4

  • ドミトリーの鍵の受け取り@Communication Center
  • Fermi Test Beam Facility(FTBF)の下見
  • 行なうべきWebトレーニングのうち終わっていないもの(Radiological Workerなど)の消化

12/5

  • Fermilab IDを取得

    User's Officeにてパスポートと海外保険の証明書を提示→承認メール受信→Key and ID Officeにて写真撮影し交付

    ※海外保険は必ず入っておくこと。また、クレジットカード付帯のものは証明書発行まで1週間ほどかかる上に保障額が少ない。出張費扱いになるので必ず入るように。

    なお、緊急の場合、出国後でも加入できる保険がある。( https://www.worldnomads.com/travel-insurance/

  • 届いている荷物を回収、確認

    EMSで11/28に送ったもの以外は届いていた。

    EMS日本郵便追跡番号リスト EJ228871277JP EJ228871246JP EJ228871285JP EJ228871263JP EJ228871229JP

    12/5 13:16に届いていることを確認

  • 借りるべきものの手配

  • SVX4 telescope, FEI-4, FE65p2のintegration

TLU

  • LVDS以外は動作確認(LVDSは確認手段がないので、とりあえずFE65のアダプターカードにはLVCMOSを入れている)。
  • 磁場テストのFirmwareを改造。扱う信号とdaughter card分の信号を拡張および変更した。TriggerをエミュレートしてTriggerを配るテストを実施。
  • SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。
    矢島さんに相談。
    結局、Triggerのレートを上げることでこの問題は解消した。
  • FE65 Adaptor cardへLVCMOSレベルの信号を配り、extriggerでの動作確認を実施。
    →Triggerに反応していない模様。
    →Trigger INとOUTが逆になっていた。FirmwareをTimonに修正してもらう。
    →Triggerに対する反応を確認。
    →ただしBusyが見えない。Firmware段階でのミス。

HSIO2

SVX

  • SVXへNIMレベルの疑似Triggerを1Hzで配り、イベント収集に取りこぼしがないか確認。→7分の1位lossしている。
    矢島さんに相談
    →SEABAS2のBUSY信号が原因。
    Preamp reset(2usec)とパイプラインリセットの長い信号が出ていることが原因。
    特にパイプラインリセットの長い方のBUSY信号に引っかかっている。
    これはBUSY信号がトリガーレートに同期してしまっているため。
    トリガーレートを例えば100Hzや200Hzにするとこの問題は解決した
  • 上記の問題に関して、SEABAS2のファームウェア上でPreampリセットをOFFにする機能がある。
    top.vのL720で、SetPerstVetoParam()からリセットの長さを指定できる。
    top.vのファイルはsctjdaqp/FPGACodes/TLUの中にある。要求があれば対応可能。
  • Daughter Boardは3.3Vで良いのか?(SVXの仕様上は2.5Vだが)
    →良い。レギュレータで調整している。3.4VくらいまではOK。
    わざわざ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クロックにする。
    この際ズレることは考えられてはいない。
  • SCTJDAQのオンラインプロットのヒストグラムのデータを処理するPostProcessingを使えるようにした。
    細かく言うと、オンラインプロットの結果は一時的にsvx_ana.rootという名前で保存されるが、リネームせずに次のRUNを走らせると上書きされてデータが消えてしまう。そこで、リネームする機能をpostProcess.pyによって実装している。
    pythonスクリプトが不必要なファイルを読み込もうとしてTracebackを出し続けていたが、修正して正しく動作するようにした。
  • 解析プログラムhitmakerでのスレッショルドの値の設定が気になっている。hitmakerの出力ファイルが空であったため。
    telehitmakermethod.cppのなかでスレッショルド決めている。L158のIsOverThreshold()あたりを探る。

12/7

セットアップ

  • ビームテストに必要なものをビームラインへ移し、組み立てた
  • inspectionが行われ、受理された
  • ネットワーク環境
    ビームラインの隣にSw-Hubを設置し、各FPGAを接続。イーサネットケーブルはビームラインの隣の壁面状のPatch Panelに接続(P1Q1)
    Control Roomへ繋がっており、室内のPatch PanelからSw-Hubへ接続。このSw-Hubから各DAQ PCへと繋がっている。
    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



HSIO

  • HSIOの番号の対応
  • HSIO module Chip

  • HSIO module chip
    A0 KEK83
    A1 KEK114 4
    A2 KEK101 2
    A3 KEK104 3
    A4 KEK113 1
    A5 KEK113 2
    A6 KEK113 3
    A7 KEK113 4
    B0 KEK115 1
    B1 KEK115 2
    B2 KEK115 3
    B3 KEK115 4
    B4 KEK112 1
    B5 KEK112 2
    B6 KEK112 3
    B7 KEK112 4
  • このうち使うのは、KEK83(single chip), KEK114(RJ4), KEK101(RJ2), KEK104(RJ3), KEK113(RJ2), KEK115(RJ3), KEK112(RJ3) である。

SVX

  • ビームライン上への設置は終了。
  • リモートコントロール環境が整った。
    SEABAS2 ←→ Sw-Hub ←→ Patch Panel ← | → Patch Panel ←→ Sw-Hub ←→ SCTJDAQ PC
  • Control RoomからSVXとの通信環境は確立した。configは通っているので接続は大丈夫と判断する。
  • Timestamp用100kHzクロック信号のNIMケーブルはまだ挿さっていない。
    他の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を使用。
    configが本当に通っているのか、ペデスタルの設定を変えて見て変化が現れるかをチェックした。
    1208_optest : 適当に走らせたデータ。動作チェック。
    1208_optest_2 : Telescope No.0のRampRngを000に設定。ペデスタルの値40程度。
    1208_optest_3 : Telescope No.0のRampRngを010に設定。ペデスタルの値90程度。
    1208_optest_4 : Telescope No.0のRampRngを001に設定。ペデスタルの値65程度。
    1208_optest_5 : Telescope No.0のRampRngを011に設定。ペデスタルの値128程度。
  • 午後、気になっていたHV Currentの再チェック。
    壊れている可能性があるTelescopeはNo.2
    保護抵抗なしでDirectにHVをかける。
    No.2 TelescopeのHVケーブルを外す → I < 3μA at 80V
    No.2 TelescopeのHVケーブルを接続 → 10VでCurrent Limitを超える。limit値の105μA以上流れ始める。
    → No.2 Telescopeが確実に悪い。
  • No.2 Telescopeを取り外してワイヤーボンドを顕微鏡で確認した。
    Rear側センサーとASICの間のボンディングがぐしゃぐしゃ。前に山元くんがここから8本ピンセットで外した。ただしここはHVとは直接関係しない場所である。
  • 花垣さん、No.2 TelescopeのRear側センサーのHVワイヤーボンドをカッターナイフで切断。
  • その後、10Vかけたところで結局105μA以上流れてしまって先ほどと結果が変わらない。センサーのどこかに異常があるのは確かだと思われるが詳しい原因はこの時点では不明。
  • (17:30)ビームラインへ伸びていたNo.2 TelescopeへのHVケーブルの先は養生テープで覆って使用不可能にした。もうHVをかけて使わないので。

    * 残り3枚のTelescopeのHV Currentをチェック。HVケーブルには保護抵抗が入っている。
    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は調査できるようになった。
    解決方法はsctjdaq/SVXTools/tele_soft/include/svxcommon.hのTELESCOPE_NUMを書き変えること。
    4枚に戻すとき、あるいは5枚以上追加するときもこの部分をいじることで対応できる。

12/10

山元より

Cooling BoxとSVXのGas flowについて

シフターのすべき事をまとめました  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を作る。

HSIO

現状:12/9にtuningが完了し特に問題が見られなかったのでMaskし始めた。

問題点:Noiseが全体に広がる問題が起こり、全てのchでMaskされる可能性がある。

方針:HV, 温度などの条件が変わるとtunigし直さないといけない。

12/7のlogにまとめてある表のうち、使用するチップは

KEK114(RJ4), KEK101(RJ2), KEK104(RJ3), KEK113(RJ2), KEK115(RJ3)

となった。

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との接続を変更することで解消。

    DAQ PCとSEABAS間のEthernetケーブルの長さの問題、またはSwitching HUBが原因と推測。

    優先度はともかく、この推測を確かめるテストを行う予定。
    TreeConverterをDAQ中に走らせるとDAQが止まる問題は、datファイルにread accessすることが直接的な原因ではないことがわかった。
    おそらく、ConvertすることでSVXとDAQ PC間の通信に負荷をかけることになるのでDAQが止まったのだと推測した。

  • オンラインモニター用のデータ出力を可能にするよう編集中。
    datファイルにする前の段階で hitch や pipelineIDをFillしている行があるので、そこで標準出力またはテキストファイルに書き込みできるように編集する方針。

FE65

オンラインモニター用のデータ出力のためのConverterは準備完了。

Gas flow

およそ見積もり通りであったが、12/12 9:08~17:28までほとんどN2タンクの残量が変わっていないことが疑問である。

それまでの残量の記録をまとめる。

記録時間 TUBE3 残圧(N2タンク1次圧) TUBE8 残圧(N2タンク1次圧) comment
12/9 18:03 10.9 MPa 14.6 MPa TUBE3のみOPEN 流量は3 SCFH~1.5 L/min
12/10 10:23 8.4 MPa 14.6 MPa
12/11 10:31 4.7 MPa 14.6 MPa 10:50頃CMSのグループから流量を下げるよう言われたので、1.75 SCFH~0.9 L/minに変更。
12/11 12:27 4.6 MPa 14.6 MPa
12/11 17:05 4.2 MPa 14.6 MPa
12/12 9:08 2.7 MPa 14.4 MPa
12/12 15:21 2.6 MPa 14.4 MPa ほとんど減っていないので、 12日にタンク交換予定であったが13日に変更。
12/12 17:28 2.6 MPa 14.4 MPa
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の応答が返ってこなくなるピクセルが多数
PrmpVbp を100にあげることで解決(以前Timonから頂いたアドバイス)

500eでtuning成功

データ:
digital 123
analog 121
threshold 122
tuning 120
noise 125

SVX

  • SCTJDAQにオンラインモニター用にバイナリデータをデコードしてrootファイルを作る部分を参考にして、テキストファイルで出力することを試みている。
    sctjdaq/SVXTools/tele_soft/src/logger.cpp
    sctjdaq/SVXTools/tele_soft/include/logger.h
    に関数を追加。
    動作テストをするにはSCTJDAQをコンパイルしてDAQを再試行しながら見る必要がある。
    DAQが遅くなるようならば別の方法を考える。
    例えば、ファイルの更新があることを毎回判定してバイナリデータをデコードして保存する等。やり方は調べないといけない。
  • 上の方針はやろうとしていることに合わない。現状のTreeConverterにgetterメソッドを追加する程度で良い。

12/14

beam status

TLU

HSIO

FE65

SVX

  • OnlineMonitor 用にバイナリデータのデコーダを書いている。設計方針はfixされた。
    確認のために書いておくと、EventNumber, Timestamp, hit ch X, hit ch Y, adc, pipelineIDのデータを出力して、他の検出器とのCorrelationを同時に見られるようにすること。
  • class SVXconverter {
    private:
    string filename;
    ifstream infile;
    int xx;
    int EventNumber;

    public:
    SVXconverter(string filename);
    ~SVXconverter();

    void GetAnEvent (int &eventnum, int *xx);
    void GetEvent (int EventNumber);
    void GetNextEvent ();
    };
    のようなテンプレートクラスに沿って設計。現在のTreeConveterとは異なるが、getterはひとまず実装済み。
    イベントナンバーを指定してイベント情報をgetできるようなメソッドを実装する。これが結構難しいというか面倒な部分。

[Remain Task]
  • LANケーブルの長さ?によるTCP connectionエラーの再現性のチェック
  • 死んだNo.2 SVX Telescopeの原因調査
  • 解析プログラムTestBeamAnaの改良。

Gas flow

流量とタンク残圧に関するまとめ。

gas_tank_summary

Cooling box 環境

box内の温度、湿度、気圧に関する簡単なまとめ。

cooling_enviroment

12/15

beam status

TLU

SVX

  • SEABAS2とSCTJDAQ PCとのTCP connection errorの原因調査を行なった。
    [ 安定している環境]
    8ポートのうち、PATCH PANEL;SCTJDAQ PC;KEKSiPC;RaspberryPiが接続されている。
    2本は先に何も繋がっていない、テスト用ポート。
    [ 構成1]
    SEABAS2をSw-Hubに、SCTJDAQ PCもSw-Hubに接続した。
    この時のSw-Hubはビームホール内の物(阪大から持参)である。LANケーブルの長さは2本とも7m程度のものである。
    SVXのデータはSCTJDAQ PCの外付けハードディスクに保存され、これをKEKSiPCから見られるようにNFSクライアントを立ち上げて参照できるようにしている。
    そのため、SEABAS2とSCTJDAQの2接続が必要になるのでSCTJDAQ PCから2本のLANケーブルを伸ばしている。なお、ethernetポートが1つしかないので、SEABAS2にはLANポートを、共有NetworkにはUSB Ethernet Adapterで接続している。
    [結果1]
    上の状況では、SCTJADAQ PCとSEABAS2のTCP connectionの確立までに10秒程度時間がかかる。
    11:20にDAQをstartしたが、その3分後イベントが増えなくなる。TCP connectionが途切れる。この時約42000eventsほど。
    [ 構成2]
    共有Networkに接続せず、Sw-Hubのみ経由でSCTJDAQ PCとSEABAS2を接続する。
    [結果2]
    TCP connectionは意外にもあっさり通った。
    11:24にDAQをstartした。1分後TCP connectionが途切れた。
    [結論]
    Sw-Hub経由でSCTJDAQ PCとSEABAS2との通信を行うと、通信が不安定になることがある。
    [考察]
    Sw-Hubを介すると通信が不安定になるのはなぜか?
    一つ考えられるのはrootingの不具合。なぜおこるのかはハブの仕様を知らないとわからない。
    また、SOIグループではSEABAS2をSw-Hub経由でDAQ PCと通信しているが、このような通信の不安定性は見られないという。
    ファームウェアの問題という可能性もあるが、これは調査に知識と時間がかかる。
    何が問題かはもう一度阪大で精査する必要がある。
    [問題の回避策]
    SEABAS2とSCTJDAQ PCは直接イーサネットケーブルで接続するようにする。
  • OnlineMonitor の開発
    SCTJDAQで出力されるバイナリファイルのデコーダを開発中。EventNumberを引数にすればそのイベントの情報を出力するメソッドは実装したがデバッグがまだ必要。
    telescopeごとにhitchとadcの値を出力するが、全部同じになってしまっているバグ。早く直す。
    今のところバイナリデータを前からreadしながらストリームの位置をシークしているが、イベントヘッダからイベントデータサイズ(byte単位)のみ取得してその分だけストリームの位置をシークするようなコードの方がスマートな気がするので、動作速度に問題、余裕があればその方針でも考えて見る。
    SVXconverter.hh(未修正版)

    [Remain Task]

    • 死んだNo.2 SVX Telescopeの原因調査
    • 解析プログラムTestBeamAnaの改良。

Gas flow

流量とタンク残圧に関するまとめ。更新しました。

gas_tank_summary

Cooling box 環境

box内の温度、湿度、気圧に関する簡単なまとめ。更新しました。

cooling_enviroment

12/16

午前:Fermilabのピクセル開発グループの研究室ツアー

午後17時以降:SeaQuest実験の施設見学

TLU

SVX

  • SCTJDAQ PCとSEABAS2の通信の検証
    外川さんと小野さんが居るのでいろいろ聞いてみました。

    設定
    IP address
    - RaspberryPi: 192.168.7.35
    - SCTJDAQ PC: 192.168.7.20
    - SVX SEABAS2:192.168.10.16(デフォルト)
    - KEKSiPC: 192.168.7.15
    - TLU SEABAS2:192.168.7.16

    一つのハブに上の全てを集約した状態[ 構成1]。
    まず、SCTJDAQ PCが192.168.10.16と通信している時、つまりDAQが走っている時に、
    sshで192.168.7.xと通信しようとすると、観測したところでは必ず通信が止まることを確認した。
    システムログを見ても,パケット受信量は止まってから増加していない。
    外川さん曰く、192.168.10.x系列と通信している時に、192.168.7.x系列が入ってくることが問題ということだそうです。
    それが原因なら、突然通信が止まったという前日の記録を説明するには、止まった時に192.168.7.xと何らかの通信があったと考えるべき。NFSで共有ディレクトリを作っていて、そこに192.168.7.x系からアクセスがあるとまずいのか?

    じゃあ全部192.168.10.x系列に揃えてしまえばいいのでは?となるが、TLUのSEABAS2とSVXのSEABAS2のIPがデフォルトのもので重複しているのでSVX SEABAS2のIPアドレスをEEPROMに書き込まれた値に変える必要がある。SEABAS2はデフォルト値(192.168.10.16)か、EEPROMに書き込まれた値(?)のどちらを使うかをジャンパーピンで変更できるので、重複させないためにはEEPROMに書き込まれた値の方を指定すれば良いということ。

    ですが、その値が不明で矢島さんに聞いている途中。
    pingで192.168.10.xxxを255通り試したが届いてない状態。
    もしもIPアドレスが192.168.10.16しか設定されていないのなら、一つのハブにSEABAS2を直接つなぐ構成はやはりやめたほうがよさそう。

12/17

TLU

SVX

  • SEABAS2のEEPROMにセットされたIPアドレス情報を得るためには、内部レジスタにUDPでアクセスすれば良いとのこと。
    アクセスするにはsctjdaq/SVXTools/tele_soft/src/comm.cppの中の関数
    int Comm::read_udp_data(unsigned int address, unsigned char* data, int array_size, int length, int output)
    を使えば良い。
    第1引数:最初のアドレス、第2引数:1byte情報を詰める配列へのポインタ、第3引数:配列要素数、第4要素:読み込むバイト列の長さ、第5引数:出力関係

    間違ったアドレス空間を読んでいたので、後日やり直しする。
    そもそもなんで記録されていないんだろう。

  • SiTCP Utilityを使ってアクセスしてみる。
    デフォルト: 写真
    EEPROM: 写真
    デフォルトの情報は納得できるが、EEPROMの情報はうーん?ソフトウェアの実装方法を知らないのでなんとも言えない。

  • SVXconverter.hh
    テレスコープごとのhitchとadc valueを表示できるようにした。

  • ネットワーク接続問題は何もできていない。

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アドレスは何だろう問題
    (発端は、TLUのSEABAS2とIPアドレスが被っている事による。KEKのSEABAS2はデフォルト)
  • UDP通信でEEPROMにアクセスできるので、書き込まれている値を見に行く事ができる。
    →Software側、SVXTools/tele_soft/src/util.cppに以下のように追加して確かめる。

    MAC ADDRESS: ff:ff:ff:ff:ff:ff
    IP ADDRESS: 192.168.10.111

    MACアドレスはおかしい。IP ADDRESSの値はそれっぽいが、実は昨日SiTCP utilityで書き換えした値で、元々は255.255.255.255だったもの。

  • J7ジャンパーピンを抜くことで、Default Mode(MACアドレス:02:00:C0:A8:00:10、IPアドレス:192.168.10.16)からEEPROMに書き込まれている情報を使うモードを切り替えられる機能がある。
  • 以下、SEABAS2とPCはダイレクトで接続されている状態での話です。
  • SEABAS2のJ7ジャンパーピンを抜くと、PCとSEABAS2との間のコネクションが取れなくなる。Linuxから見えない。Ethernetに何も挿さっていないように見える。
    ・PC側のネットワーク設定が間違っているから見えないということが原因では無い。
    ・SEABAS2の赤色LED(通常TCP通信ができていると早く点滅(0.5Hzくらい?))が遅い周期(1Hzくらい)で点滅。
     SEABAS2がそもそもEthernet通信をしようとしていないとの小野さんの見解。
    ・ジャンパーピンを抜いた状態では、LVカレントが1.819A〜1.751Aの間を1Hzくらいで振動している(@LV=3.3V)
     ジャンパーピンを挿した状態では、2.37A程度で安定している。
     この時、DaughterBoardのLVカレントは3.45Aでジャンパーピン挿していない状態と同じ値で安定(@LV=3.3V)
  • ジャンパーピンを挿した状態に戻す(DefaultMode)と、通常通りコネクションが取れてDAQも走る。
  • SOIグループのSEABAS2を使用してSiTCP utilityで正しい情報が読めるかのテスト(12/17でSiTCP utilityの返す値が正しいかの確認)
    設定したIPアドレス、MACアドレスにアクセスできるので、ソフトウェアは正しい。EEPROMの中身もきちんと見られる。
  • SEABAS2のEEPROMの中身が何も書き換わっていない疑い、あるいは誰かが何か設定してしまった可能性?
  • EEPROMの中身が壊れている可能性。
    →解決策としては、EEPROMを書き直す。
     SiTCP utilityでIP address、TCP Port、UDP Portは書き換えられる。
     MACアドレスは簡単には書き換えられない。ただ、書き換えられる方法はある。
     購入したMACアドレスが保存されたbinaryファイルとBeeBeansがCDで配布しているソフトウェアを使えば書き換えられる。j-tagじゃなくてEthernetで。
  • 20日朝からMACアドレスを書き込むテストを行ってみる。
  • [Remain Task]

    • 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文を抜けてもトリガーをまだ送っていたから。
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ラグがあるから?
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アドレスを変更した。
    MAC ADDRESS : 7C:F0:98:01:08:DE
    IP ADDRESS : 192.168.7.20 (temporary)
    TCP Data Port : 24
    UDP Port : 4660
  • SCTJDAQ SoftwareのIPアドレスの部分だけを変更してコンパイルしても、Iinitializeはできるがconfigを通そうとするあたりで通信先を見失う。
    しばらく待つとsegmentation fault。 ログ
    とりあえずこの件は保留。
    他にもEEPROMの設定値を設定し直さないといけないのかもしれない。TCP command Port番号が65535のままとかが悪さをしている?
    ソースコードを調べないとわからない。保留。
  • DAQは、SEABAS2とDAQ PCを直接繋いでデータを取ることにする。
  • SCTJDAQのRUN NUMBERの出力先の変更
    (sctjdaq/gui/sctgui.pyの中で設定します。DAQはpythonスクリプトを走らせるだけなのでコンパイルは不要。)
    変更前 : sctjdaq/gui/run_number.txt
    変更後 : //media/SVX_TELE/svx_data/data/run_number.txt
  • SVXのDAQの流れ
    1.DAQの立ち上げ
    2.configファイルの読み込み
    3.setupボタンを押す(initialize)
    4.statusに全てLOADEDが表示されていることを確認する。DEAD, Noneが出たらプロセスが走っていないか通信ができていない。
    5.configボタンを押す
    6.statusが全てCONFIGUREDになっていることを確認する。
    7.startボタンを押すことでDAQがスタート。statusがRUNNINGになっていることを確認する。最初のトリガーが来るまではEvent NumberとData Rateが変な値を表示しているがこれは仕様。run_numberはこの時点で+1増える。
    8.stopボタンを押すとDAQがストップ。
    9.この後もう一度startボタンを押すとDAQが走るかに思えるが、なぜかバグる仕様。Kill DAQボタンを押して3に戻ってください。

12/21

片付け予定日
午前中、β線源を当ててヒットマップを見てみるテスト。タイミングスキャンも。
午後、片付け、何を持って帰るか決める。

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:
シンチのみにβ線源(Sr90)を当てた場合。ヒットっぽいものが見えた。
FE65以外はビームでのタイミングスキャンがやはり必要。β線源でそれをやるのは非効率的。

TLU

HSIO

SVX

  • タイミングスキャン無しではやはりβのヒットは見えなかった。当然と言えば当然。

片付け

各グループ持って帰るものリスト

12/22

帰国予定日

昼ごろまでに空港に出発。

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
key=20

SELF_NOISESCAN下の方に筋状にノイズがひろがる

→以前から見られている問題を再現した。

原因はなんだろう。

1、レギュレータ

2、エンコーディングが悪さをしてたり・・?  → 今日調べてみる

3、フレックス固有の問題? → 正月明けにフレックス以外のモジュールでレギュレータを使ってみたりいろいろ。

マンチェスターエンコーディングの部分をコメントアウトして再度コンパイルしてみる。→まったく関係なし(コードは戻した)

-- Atlasj Silicon - 2016-12-06

Comments


Edit | Attach | Watch | Print version | History: r36 < r35 < r34 < r33 < r32 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r36 - 2017-01-17 - AtlasjSilicon
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback