MPS Minutes 20210610: Difference between revisions

From MPS Wiki
Jump to navigation Jump to search
(Created page with "==Post Mortem / HV trips == ==Second stage trip== ==Fibre update== *MA, AT worked on things last Friday. Better setup on the table now. *Got black cloth to cover certain are...")
 
No edit summary
 
Line 1: Line 1:
Present: HH, AD, RN, MR, RC, MA, KL, AL (recorder)
==Post Mortem / HV trips ==
==Post Mortem / HV trips ==
*More trip tests were performed this week.
*It turns out, trips occur once update button on diagnostics page is activated
*This trips HV for all detectors that were biased and HV cannot be restored without crate power cycle afterwards
*It seems that data lines are held by either IOC or BLM, when data is read
*IOC reading from BLM memory seems to be source of hold-up
*Then an unexpected value is written to the iseg board. Why do we write to the iseg?
*That value has emergency bit ON
*Could it be that there are spurious writes to other modules as well? Issue needs to be resolved!
*Possible solution: Could we not write continuously, but introduce "sleeps" to prevent holding up of data line?
*HH: Block reads are not allowed. Could this be a speed issue since BLM didn't have time to release bus? IOC is fast, could readouts be slowed down?
*RN: Add "non-blocking" read time.
*MR: Essentially introducing 2 new "sleeps"
*Give CPU time for back lane
*Ricky will setup test crate to scope VMEbus and trouble shoot


==Second stage trip==
==Second stage trip==
*HH got things working
*Got testing both parts together working
*Now waiting for Ricky. Code needs to be completed
*Roll out once this is done and appropriate time window can be found.


==Fibre update==
==Fibre update==

Latest revision as of 18:26, 10 June 2021

Present: HH, AD, RN, MR, RC, MA, KL, AL (recorder)

Post Mortem / HV trips

  • More trip tests were performed this week.
  • It turns out, trips occur once update button on diagnostics page is activated
  • This trips HV for all detectors that were biased and HV cannot be restored without crate power cycle afterwards
  • It seems that data lines are held by either IOC or BLM, when data is read
  • IOC reading from BLM memory seems to be source of hold-up
  • Then an unexpected value is written to the iseg board. Why do we write to the iseg?
  • That value has emergency bit ON
  • Could it be that there are spurious writes to other modules as well? Issue needs to be resolved!
  • Possible solution: Could we not write continuously, but introduce "sleeps" to prevent holding up of data line?
  • HH: Block reads are not allowed. Could this be a speed issue since BLM didn't have time to release bus? IOC is fast, could readouts be slowed down?
  • RN: Add "non-blocking" read time.
  • MR: Essentially introducing 2 new "sleeps"
  • Give CPU time for back lane
  • Ricky will setup test crate to scope VMEbus and trouble shoot


Second stage trip

  • HH got things working
  • Got testing both parts together working
  • Now waiting for Ricky. Code needs to be completed
  • Roll out once this is done and appropriate time window can be found.

Fibre update

  • MA, AT worked on things last Friday. Better setup on the table now.
  • Got black cloth to cover certain areas
  • Some confusion on specs for PMT. Unclear if photons are counted individually.
  • Looks like there are no issues with light leaking in so far
  • Next steps, looking into how to measure wavelength dependence
  • Next measurements with beam, unclear when that will be
  • Thinking about putting mirror on the other side of the fibre to figure out how well position can be determined.
  • May purchase new PMTs, but need to determine for which wavelength first.

AOB

  • MA got covers for BLM cables on floor from OH&S. Can just cut them to length now
  • Issue with EPICS start-up after trip or IOC reboot. Even though threshold, delta and HV values are set to default, one has to toggle each slider before the readback matches the set value. HV won't start ramping before toggle.
  • Rod and Alex to discuss solution for this offline.
  • Default value for LED driver channels should be changed to 5V, presently zero which is not practical.