9:08 local filter turned red. Both .caendat and   LF .adf files still incrementing. Stopped run 44, started run 45, looks OK.

after run 45 I reset all spectrums and number_Ge_15 dedector not taking data.

i check the fans_monitor_scaler (EAGLE_array_monitor) monitor and number 15 Ge, number ACS 5 never change the color just staying white there is a problem.

14:30 pm to 15:00 run 45 crashed and stopped

There was a problem with the beam from 20:19 to 20:30.

Now it is fine.

The beam was unstable from 7:18 to 7:25.

The beam was unstable from 7:55. Stabilized around 8:03.

Counting rates are higher, EAGLE det4 went to ~2.5kHZ from ~2kHz (attached).

According to the operator, a bit of a tuning was done, current is 1nA.

run control = 48

run data =  /onlineNEDA_00/xData/hil099/run_0048_08-03-2023_01h08m57s/needleRU_i48_0048_0041.caendat

RU =  10.4 MB/s

LF =   4.3 MB/s

Counting rates continued to increase (det4 > 3kHz). Beam current looked fine on the beam dump, but beam is fluctuating, and can reach 2nA on the collimator.  Asked for improved focusing.

Attached screenshots and Ge spectra from before changing anything.

run control = 49

run data = /onlineNEDA_00/xData/hil099/run_0049_08-03-2023_09h31m08s/needleRU_i49_0049_0020.caendat

RU =  13.3 MB/s

LF =   6.15MB/s

plunger:

plunger run = 603

actual distance =  382.7 um

supposed distance = 382.7 um

micrometer =   385.9 um

position =  150.0 um

voltage =  2.146 V

Beam dump 0.7 nA

Collimator ~1.5-2nA when the generator retunes itself (prob the beam gets defocused at those moments)

no beam in 15:52 - 16:21 due to power supply problem

longer break during chane of plunger distance due to technical problem, you can not move plunger to larger distances, so now we are choosing smaller distance in the morning we ask the specialists
 

rate of ch4 above 2kHz, too big beam intesivity, highier data rate from: 07:51
 

the beam was lost at 20:46. The operator is working to solve the problem.

the beam is not the best focused. The operator works on this problem.

the daq crashed at 22:43 -- problem with Local Filter

the run 53 - stopped

at 11:34:50 sek on 11 march a spike in counting rate of some Ge detectors is observed. Buffers not cleared properly?

As in the title, see below.
The data are still being constantly written on the disks with usual rate (also visible on grafena).
Greware is also seeing data.

beeper output:
no new data about the growth for 37 s !!!
Noticed at Sun Mar 12 02:50:42 2023
and weirdo scream followed.


LF output:

write: Broken pipe
  0-LF_neda_2:        98 ev ( 107153)*30   Tot=26234475   2253/s
write: Broken pipe
  0-LF_eagle_1:      881 ev ( 120281)*31   Tot=295856141  24268/s
write: Broken pipe
write: Broken pipe
  0-LF_neda_3:         3 ev (   3909)*5980 Tot=375647125  30917/s
write: Broken pipe
  0-LF_neda_1:        92 ev (  92962)*40   Tot=32523205   2820/s
write: Broken pipe
write: Broken pipe
  0-LF_neda_0:       104 ev ( 117997)*33   Tot=38078515   3323/s
  0-LF_eagle_0:      720 ev (  63994)*31   Tot=268339966  22243/s
write: Broken pipe
write: Broken pipe
write: Broken pipe
write: Broken pipe
write: Broken pipe
write: Broken pipe
  0-LF_neda_2:        72 ev (  87376)*31   Tot=26236761   2274/s
write: Broken pipe
  0-LF_eagle_1:      714 ev ( 104681)*35   Tot=295880265  23988/s
write: Broken pipe
write: Broken pipe
  0-LF_neda_3:         9 ev (   3988)*5870 Tot=375677518  30545/s
write: Broken pipe
  0-LF_neda_1:        93 ev (  98610)*34   Tot=32525919   2698/s

For a split second a red "NO DATA" notification appeared in the top right corner of Counting rates dashboard.

It looks like it did not change anything in data collection.

Notes of the measurements with different conditions are attached.

Conclusion:
What is read out by the operators on the blue cable should be multiplied by 7 to get a real value in enA.

Current readout issues from beamdump. Beam stopped from 17:46-17:52, run 36 ongoing.

MP & GJ checking the grounding and connection the beamdump readout. No visible issue found in the exp hall, but copper grounding wire was tightened, which seemingly resolved the issue (stability of beamdump readout).   

Beam back on 05:15