| ID |
Date |
Author |
Subject |
|
168
|
Tue Mar 8 12:11:56 2016 |
CG, AE | RIKEN maintenance progress |
| Quote: |
|
07/03/16
The new snout doesn't fit due to the screw holes being misaligned. I am going to try modifying the old one (that was in conflict with some material in the base) over the next couple of days. It is too long by 11mm, so if I can remove that it should then fit..
So after some modifications to the supports, the PSUs and NIM crates are now fully isolated from the frame.
I am currently working through changing all the guide pins for the new plastic ones and adding the shielding gasket.
Shunji made an interesting comment when we were discussing isolating the FEEs yesterday, in that, the ground connections for the chiller and the power we provide to our PSUs are connected to the same network.
- I measure the resistance between the chiller ground and the power ground to be 2.5 Ohms.
- The resistance between the chiller ground and the main Cu water pipe is ~2.2 kOhms.
- We have three possible options here (that we have come up with so far):
* disconnect the chiller ground from the network -> potentially very dangerous
* put a large resistance in between the chiller and the ground
* Shunji has available a noise cut trans with up to 30A capability that could be used for our NIM crates and power supplies (I think we draw < 30A IIRC) [photos attached]
I will carry out some short pulser tests with a DSSSD connected via the most recent kaptons this afternoon to see what effect the isolation and gasket has had so far.
|
Have you identified a specific noise issue with the Julabo recirculating chiller?
The STFC DL T9 test system has the recirculating chiller and AIDA PSUs connected to the same ac mains extender.
|
|
663
|
Thu Jun 15 07:44:41 2017 |
OH | RIKEN Cable Inventory | List of the type and quantity of cables we have at RIKEN that are not currently in use. |
| Attachment 1: 170615_Cable_Inventory.xlsx
|
|
286
|
Mon Jun 6 15:57:51 2016 |
TD, ML & YS | R1121 (AIDA) |
R1120 stalled shortly after DAQ GO
'unable to connect' etc
power cycle & reboot FEE64s
R1121 currently running
AIDA SYNCs currently but rates <100Hz in many FEE64s - see attachment 2
link64 processes consuming large fraction of available CPU - see attachment 1 |
| Attachment 1: 43.png
|
|
| Attachment 2: 44.png
|
|
|
285
|
Mon Jun 6 15:06:22 2016 |
1TD, ML & YS | R1119 | R1118 ended OK
R1119 DAQ GO, check AIDA SYNCs OK, toggle merge input etc
Merge then halted with the usual unable to connect to COUNTER, nnaida1, nnaida1 etc error messages
so unable to reset, setup etc
Power-cycling and rebooting |
| Attachment 1: 41.png
|
|
| Attachment 2: 42.png
|
|
|
284
|
Mon Jun 6 14:24:07 2016 |
TD, ML & YS | R1118 (AIDA) | 22.14 R1118 starts
aidas1 has been rebooted
Changed /MIDAS/linux-ppc_4xx/startup/aidacommon from
netint DACQ_PushEnable 60
netint DACQ_FlushEnable 60
to
netint DACQ_PushEnable 10
netint DACQ_FlushEnable 10
AIDA FEE64s then power-cycled and rebooted
nnaida19 data link to merger disabled
see attachments 1-8
22.30 R1118 stops
AIDA SYNCs & good events at end of R1118 - see attachments 9-10 |
| Attachment 1: aidacommon
|
#!/bin/bash
#
UM=`umask`
umask 0
#
cd /MIDAS/linux-ppc_4xx/drivers/spi/module
./load
sleep 5
cd /MIDAS/linux-ppc_4xx/drivers/xaida/module
./load
sleep 5
cd /MIDAS/linux-ppc_4xx/drivers/aidamem/module
./load
sleep 5
MIDAS_MEMSAS_PORT=0
export MIDAS_MEMSAS_PORT
export PATH=/MIDAS/linux-ppc_4xx/bin:${PATH}
export LD_LIBRARY_PATH=/MIDAS/linux-ppc_4xx/lib:${LD_LIBRARY_PATH}
/MIDAS/TclHttpd/linux-ppc_4xx/TclHttpd-server&
sleep 10
cd /MIDAS/linux-ppc_4xx/bin
#
# define netints and access registers
#
netint Output_BufferSize 64
netint Format_Option 4
netint Xfer_Option 3
netint Xfer_NoBlock 0
netint Xfer_Overlap 0
netint Xfer_Priority 0
netint DACQ_TxInit 1
netint DACQ_StatsTime 5
netint DACQ_PushEnable 10
netint DACQ_FlushEnable 10
cd /MIDAS/Data_Acq/bin/linux-ppc_4xx
# ./ExecV1
nice ./AidaExecV8
#
umask $UM
#
|
| Attachment 2: 30.png
|
|
| Attachment 3: 31.png
|
|
| Attachment 4: 32.png
|
|
| Attachment 5: 35.png
|
|
| Attachment 6: 36.png
|
|
| Attachment 7: 37.png
|
|
| Attachment 8: 33.png
|
|
| Attachment 9: 38.png
|
|
| Attachment 10: 39.png
|
|
|
550
|
Sun Apr 2 03:32:30 2017 |
DK, OH | Pulser walkthrough | 11:32 Pulser walkthrough, 90k down to 10k, 10k steps, 1 min per step
R26
11:41 stop run R26
11:44 Pulser walkthrough, 10k to 2k in 2k steps, 90 seconds per step
R27
11:53 stop run R27
11:56 Pulser walkthrough, 2k to 10k in 2k steps (90 sec each) & 10k to 40k in 10k steps (60 sec per step)
R28
12:05 Attachment 1 shows biases ("bias_2_a.png")
12:07 stop run R28
12:15 background run, R29
12:39 stop run 29. |
| Attachment 1: bias_2_a.png
|
|
|
324
|
Tue Jul 5 13:43:02 2016 |
DK, PV | Pulser Test Run after AIDA is moved | Needed to run startx and start the TcLHttpd server on rpi
Following along here: https://elog.ph.ed.ac.uk/AIDA/242
Can now access http://nnrpi1:8015/AIDA/Rly16/
Window at first connection reads:
Using /dev/ttyUSB0 firmware version 0
Using /dev/ttyUSB1 firmware version 0901
Looks good. Sequence ALL On was selected
(By mistake, I then clicked Relay # to turn off...misread instructions...Switch all OFF, then sequence ALL on again)
7:51 they are turned on. Waiting several minutes now.
Add 4 L of water to the chiller
8:12
Save/Control Settings from Hardware Control tab:
Selected: 2016Jun13-00.53.55 and Restore. (missing from elog 242)
From Run Control, Enable Histogramming, Data Transfer: Enable #1 All (missing from elog 242)
TapeServer / Merger / Httpd started on Workspace 2
TapeServer reports
Cannot issue more Access Tokens: Claim TapeServer returned:- 3 Capability table is full
Make a new directory for storing test data: /data10/TapeData/July2016
Merger: Setup and configure
Data Statistics shows about ~5 x 10^5 events in many nnaida. Should we use a different setting file?
Now we try 2016Jun12-10.10.08
Perform ReSync
Probably event rate can be high because the SSD bias is off? We set up Putty and turn on all biases to -100 V.
Attachments 1 and 2 show the bias settings after they are turned on.
Good Events rate improves, factor 2 to 4 (now about 100k roughly)
Pulser settings: around ~900 on dial, attenuator x10, x10, x2 switches down, 5x up. Frequency ~250 Hz
21:19
Now we change the Control ASICs (select act on all ASICs, act on all FEEs)
Slow Comparator from 0x8 to 0x20
LEC/MEC Fast Comparator 0x4 to 0x80
Now the Good Events go down to about 10k to 25k roughly
TapeServer starts a run.
Merger started / paused / unpaused
Merger rate is 500k / sec. TapeServer is 4 k / sec.
AIDA Syncs shown in Attachment 3
Temps in Attachment 4
Good Events Attachment 5
Run Number 1
Setting file: 2016Jul05-21.37.20 (Note: I wrote the wrong setting file name last night...this is the right one!)
Show sample pulser peak in Attachment 6, 7, 8
July 6 - 12:29: Stop the run. 114 run files, 2.0 GB each.
Attachments 9, 10 show biases at the end of the run |
| Attachment 1: bias1-2016-07-05_21.12.png
|
|
| Attachment 2: bias2_2016-07-05_21.12.png
|
|
| Attachment 3: aida_sync.png
|
|
| Attachment 4: temps.png
|
|
| Attachment 5: good_evt.png
|
|
| Attachment 6: pulser_peak.png
|
|
| Attachment 7: pulse_2.15_nnaida13.png
|
|
| Attachment 8: pulser-nnaida3.png
|
|
| Attachment 9: bias1_run1_finish.png
|
|
| Attachment 10: bias2_run1_finish.png
|
|
|
61
|
Mon Apr 20 09:45:38 2015 |
CG, TD, Patrick Coleman-Smith | Progress 20th April + RPi procedure + reply ++ |
| Quote: |
|
| Quote: |
|
| Quote: |
|
20/04/15
1200: Complete all points on first part of check list, except checking the PSU voltages.
System now in powered and has all network/HDMI cables attached.
1300: Connect RPi to power switch but when powered on it didn't find the switch. A reliable procedure to start seems to be...
- connect USB power switch to RPI, make sure serial cable is disconnected from hub
- power up RPi and power switch
- check connection using dmesg, should see ...FT232RL for USB power switch on USB0
- check connection from aidas1 by pinging RPi inet address 10.1.1.251
- if good, Rly16 page should work from aidas1
- connect serial cable, open PuTTY session, select AIDA console settings, open
- should assign serial cable as USB1 an allow use of both the power switch and FEE console.
Currently this all works, we can control the power switch both from the RPi and aidas1, and see the FEE console via PuTTY session.
1400: Powered on system and tried to set up DAQ but received error (attachment 1) when doing the initial system reset in Run Control.
DAQ still usable for spectrum/temperature viewing, and all FEEs can be accessed to check ASIC control, but it seems timestamping will not be correct.
Tried to perform manual ReSync from master timestamp window and received similar error (attachment 2).
1430: nnaida8 running quite hot (ASIC temp ~65oC) and ASIC temp on nnaida7+15 read as 0.00oC. Otherwise, from pulser/stats data, both seem to be working correctly.
Unplugged power cable for nnaida7+8 at PSU end.
1600: Could timestamping issue originate from MACBs?
In rebuilding AIDA MACB - > FEE cabling redone. Should it follow a particular pattern/tree?
Current tree structure looks like (with MACB numbering going 1->11 L->R as you look at it):
MACB1 (setting: 0) ------- out 1: MACB2 (setting: 2) ---------- out 1: MACB3 (setting: 2) -> nnaida3+4, 11+12
&nb sp; &nb sp; ---------- out 2: MACB4 (setting: 3) -> nnaida19+20, 27+28
&nb sp; &nb sp; ---------- out 3: MACB5 (setting: 3) -> nniada1+2, 9+10
&nb sp; &nb sp; ---------- out 4: MACB6 (setting: 3) -> nnaida17+18, 25+26
&nb sp; --------- out 2: MACB7 (setting: 3) ---------- out 1: MACB8 (setting: 3) -> nnaida21+22, 29+30
&nb sp; &nb sp; ---------- out 2: MACB9 (setting: 3) -> nnaida7+8, 15+16
&nb sp; &nb sp; ---------- out 3: MACB10 (setting: 3) -> nnaida5+6, 13+14 -----> nnaida5 is the master and this comes from output2.
&nb sp; &nb sp; ---------- out 4: MACB11 (setting: 3) -> nnaida23+24, 31+32
Patrick - Is this set up OK? Do certain FEEs need to receive the MACB signal from certain MACBs or just all at the same point in the tree?
Also, MACBs 2+3 are on setting 2 on the dial, whereas the others (except MACB1, the 'grandparent') are set to 3. It seems like a hard thing to change accidentally so are they supposed to be like this or should they all be on the same setting?
1630: Voltages to nnaida7+8 OK at PSU output (+6V, +6V, +6V, -6.5V, +8V). Issue with contact to cooling rack?
With pulser input to all FEEs, only see pulser data in spectra for n-side (nnaida3+4, 7+8, 11+12, 15+16) FEEs. Other FEEs all show zero statistics.
|
The MACB system of clock and SYNC pulse distribution does have to follow some rules.
The Master needs to be in a very particular place. The rest are less important as long as they are all at the same level in the tree.
In the tree you report above and using the numbering you report. The Master should be in MACB3:out1.
The settings you have shown are correct if the Master is placed correctly ...
I will input a separate Elog entry detailing the settings for the MACB and the rules for the tree.
Thanks
Regarding nnaida7+8. I agree the issue to tackle first is the cooling plate contact to the module. Where do they feature in the layout ?
Is the plate tightened up correctly ?
As far as I am aware this module/crate has not recently been opened so the 'contact' should be as good (or bad) as it ever was.
But it would, of course, bear checking.
Regarding the P side FEE64s ... sorry about this ... but is the P pulser working ... well i did have to ask ;-
According to a DSO the positive and negative pulser inputs and cabling are OK
|
|
Regarding the P side problem.
What is the result if you change one of the N-Side FEEs to use the P-side pulser and vice-versa ?
Regarding the temperature problem.
Which position are the problem modules in ? |
|
59
|
Mon Apr 20 09:07:59 2015 |
CG, TD, Patrick Coleman-Smith | Progress 20th April + RPi procedure + reply |
| Quote: |
|
20/04/15
1200: Complete all points on first part of check list, except checking the PSU voltages.
System now in powered and has all network/HDMI cables attached.
1300: Connect RPi to power switch but when powered on it didn't find the switch. A reliable procedure to start seems to be...
- connect USB power switch to RPI, make sure serial cable is disconnected from hub
- power up RPi and power switch
- check connection using dmesg, should see ...FT232RL for USB power switch on USB0
- check connection from aidas1 by pinging RPi inet address 10.1.1.251
- if good, Rly16 page should work from aidas1
- connect serial cable, open PuTTY session, select AIDA console settings, open
- should assign serial cable as USB1 an allow use of both the power switch and FEE console.
Currently this all works, we can control the power switch both from the RPi and aidas1, and see the FEE console via PuTTY session.
1400: Powered on system and tried to set up DAQ but received error (attachment 1) when doing the initial system reset in Run Control.
DAQ still usable for spectrum/temperature viewing, and all FEEs can be accessed to check ASIC control, but it seems timestamping will not be correct.
Tried to perform manual ReSync from master timestamp window and received similar error (attachment 2).
1430: nnaida8 running quite hot (ASIC temp ~65oC) and ASIC temp on nnaida7+15 read as 0.00oC. Otherwise, from pulser/stats data, both seem to be working correctly.
Unplugged power cable for nnaida7+8 at PSU end.
1600: Could timestamping issue originate from MACBs?
In rebuilding AIDA MACB -> FEE cabling redone. Should it follow a particular pattern/tree?
Current tree structure looks like (with MACB numbering going 1->11 L->R as you look at it):
MACB1(setting: 0) ------- out 1: MACB2 (setting: 2) ---------- out 1: MACB3 (setting: 2) -> nnaida3+4, 11+12
---------- out 2: MACB4 (setting: 3) -> nnaida19+20, 27+28
---------- out 3: MACB5 (setting: 3) -> nniada1+2, 9+10
---------- out 4: MACB6 (setting: 3) -> nnaida17+18, 25+26
--------- out 2: MACB7 (setting: 3) ---------- out 1: MACB8 (setting: 3) -> nnaida21+22, 29+30
---------- out 2: MACB9 (setting: 3) -> nnaida7+8, 15+16
---------- out 3: MACB10 (setting: 3) -> nnaida5+6, 13+14 -----> nnaida5 is the master and this comes from output2.
---------- out 4: MACB11 (setting: 3) -> nnaida23+24, 31+32
Patrick - Is this set up OK? Do certain FEEs need to receive the MACB signal from certain MACBs or just all at the same point in the tree?
Also, MACBs 2+3 are on setting 2 on the dial, whereas the others (except MACB1, the 'grandparent') are set to 3. It seems like a hard thing to change accidentally so are they supposed to be like this or should they all be on the same setting?
1630: Voltages to nnaida7+8 OK at PSU output (+6V, +6V, +6V, -6.5V, +8V). Issue with contact to cooling rack?
With pulser input to all FEEs, only see pulser data in spectra for n-side (nnaida3+4, 7+8, 11+12, 15+16) FEEs. Other FEEs all show zero statistics.
|
The MACB system of clock and SYNC pulse distribution does have to follow some rules.
The Master needs to be in a very particular place. The rest are less important as long as they are all at the same level in the tree.
In the tree you report above and using the numbering you report. The Master should be in MACB3:out1.
The settings you have shown are correct if the Master is placed correctly ...
I will input a separate Elog entry detailing the settings for the MACB and the rules for the tree.
Regarding nnaida7+8. I agree the issue to tackle first is the cooling plate contact to the module. Where do they feature in the layout ?
Is the plate tightened up correctly ?
Regarding the P side FEE64s ... sorry about this ... but is the P pulser working ... well i did have to ask ;-)
|
|
60
|
Mon Apr 20 09:38:15 2015 |
CG, TD, Patrick Coleman-Smith | Progress 20th April + RPi procedure + reply |
| Quote: |
|
| Quote: |
|
20/04/15
1200: Complete all points on first part of check list, except checking the PSU voltages.
System now in powered and has all network/HDMI cables attached.
1300: Connect RPi to power switch but when powered on it didn't find the switch. A reliable procedure to start seems to be...
- connect USB power switch to RPI, make sure serial cable is disconnected from hub
- power up RPi and power switch
- check connection using dmesg, should see ...FT232RL for USB power switch on USB0
- check connection from aidas1 by pinging RPi inet address 10.1.1.251
- if good, Rly16 page should work from aidas1
- connect serial cable, open PuTTY session, select AIDA console settings, open
- should assign serial cable as USB1 an allow use of both the power switch and FEE console.
Currently this all works, we can control the power switch both from the RPi and aidas1, and see the FEE console via PuTTY session.
1400: Powered on system and tried to set up DAQ but received error (attachment 1) when doing the initial system reset in Run Control.
DAQ still usable for spectrum/temperature viewing, and all FEEs can be accessed to check ASIC control, but it seems timestamping will not be correct.
Tried to perform manual ReSync from master timestamp window and received similar error (attachment 2).
1430: nnaida8 running quite hot (ASIC temp ~65oC) and ASIC temp on nnaida7+15 read as 0.00oC. Otherwise, from pulser/stats data, both seem to be working correctly.
Unplugged power cable for nnaida7+8 at PSU end.
1600: Could timestamping issue originate from MACBs?
In rebuilding AIDA MACB - > FEE cabling redone. Should it follow a particular pattern/tree?
Current tree structure looks like (with MACB numbering going 1->11 L->R as you look at it):
MACB1 (setting: 0) ------- out 1: MACB2 (setting: 2) ---------- out 1: MACB3 (setting: 2) -> nnaida3+4, 11+12
&nb sp; &nb sp; ---------- out 2: MACB4 (setting: 3) -> nnaida19+20, 27+28
&nb sp; &nb sp; ---------- out 3: MACB5 (setting: 3) -> nniada1+2, 9+10
&nb sp; &nb sp; ---------- out 4: MACB6 (setting: 3) -> nnaida17+18, 25+26
&nb sp; --------- out 2: MACB7 (setting: 3) ---------- out 1: MACB8 (setting: 3) -> nnaida21+22, 29+30
&nb sp; &nb sp; ---------- out 2: MACB9 (setting: 3) -> nnaida7+8, 15+16
&nb sp; &nb sp; ---------- out 3: MACB10 (setting: 3) -> nnaida5+6, 13+14 -----> nnaida5 is the master and this comes from output2.
&nb sp; &nb sp; ---------- out 4: MACB11 (setting: 3) -> nnaida23+24, 31+32
Patrick - Is this set up OK? Do certain FEEs need to receive the MACB signal from certain MACBs or just all at the same point in the tree?
Also, MACBs 2+3 are on setting 2 on the dial, whereas the others (except MACB1, the 'grandparent') are set to 3. It seems like a hard thing to change accidentally so are they supposed to be like this or should they all be on the same setting?
1630: Voltages to nnaida7+8 OK at PSU output (+6V, +6V, +6V, -6.5V, +8V). Issue with contact to cooling rack?
With pulser input to all FEEs, only see pulser data in spectra for n-side (nnaida3+4, 7+8, 11+12, 15+16) FEEs. Other FEEs all show zero statistics.
|
The MACB system of clock and SYNC pulse distribution does have to follow some rules.
The Master needs to be in a very particular place. The rest are less important as long as they are all at the same level in the tree.
In the tree you report above and using the numbering you report. The Master should be in MACB3:out1.
The settings you have shown are correct if the Master is placed correctly ...
I will input a separate Elog entry detailing the settings for the MACB and the rules for the tree.
Thanks
Regarding nnaida7+8. I agree the issue to tackle first is the cooling plate contact to the module. Where do they feature in the layout ?
Is the plate tightened up correctly ?
As far as I am aware this module/crate has not recently been opened so the 'contact' should be as good (or bad) as it ever was.
But it would, of course, bear checking.
Regarding the P side FEE64s ... sorry about this ... but is the P pulser working ... well i did have to ask ;-
According to a DSO the positive and negative pulser inputs and cabling are OK
|
|
|
57
|
Mon Apr 20 06:53:24 2015 |
CG, TD | Progress 20th April + RPi procedure | 20/04/15
1200: Complete all points on first part of check list, except checking the PSU voltages.
System now in powered and has all network/HDMI cables attached.
1300: Connect RPi to power switch but when powered on it didn't find the switch. A reliable procedure to start seems to be...
- connect USB power switch to RPI, make sure serial cable is disconnected from hub
- power up RPi and power switch
- check connection using dmesg, should see ...FT232RL for USB power switch on USB0
- check connection from aidas1 by pinging RPi inet address 10.1.1.251
- if good, Rly16 page should work from aidas1
- connect serial cable, open PuTTY session, select AIDA console settings, open
- should assign serial cable as USB1 an allow use of both the power switch and FEE console.
Currently this all works, we can control the power switch both from the RPi and aidas1, and see the FEE console via PuTTY session.
1400: Powered on system and tried to set up DAQ but received error (attachment 1) when doing the initial system reset in Run Control.
DAQ still usable for spectrum/temperature viewing, and all FEEs can be accessed to check ASIC control, but it seems timestamping will not be correct.
Tried to perform manual ReSync from master timestamp window and received similar error (attachment 2).
1430: nnaida8 running quite hot (ASIC temp ~65oC) and ASIC temp on nnaida7+15 read as 0.00oC. Otherwise, from pulser/stats data, both seem to be working correctly.
Unplugged power cable for nnaida7+8 at PSU end.
1600: Could timestamping issue originate from MACBs?
In rebuilding AIDA MACB -> FEE cabling redone. Should it follow a particular pattern/tree?
Current tree structure looks like (with MACB numbering going 1->11 L->R as you look at it):
MACB1(setting: 0) ------- out 1: MACB2 (setting: 2) ---------- out 1: MACB3 (setting: 2) -> nnaida3+4, 11+12
---------- out 2: MACB4 (setting: 3) -> nnaida19+20, 27+28
---------- out 3: MACB5 (setting: 3) -> nniada1+2, 9+10
---------- out 4: MACB6 (setting: 3) -> nnaida17+18, 25+26
--------- out 2: MACB7 (setting: 3) ---------- out 1: MACB8 (setting: 3) -> nnaida21+22, 29+30
---------- out 2: MACB9 (setting: 3) -> nnaida7+8, 15+16
---------- out 3: MACB10 (setting: 3) -> nnaida5+6, 13+14 -----> nnaida5 is the master and this comes from output2.
---------- out 4: MACB11 (setting: 3) -> nnaida23+24, 31+32
Patrick - Is this set up OK? Do certain FEEs need to receive the MACB signal from certain MACBs or just all at the same point in the tree?
Also, MACBs 2+3 are on setting 2 on the dial, whereas the others (except MACB1, the 'grandparent') are set to 3. It seems like a hard thing to change accidentally so are they supposed to be like this or should they all be on the same setting?
1630: Voltages to nnaida7+8 OK at PSU output (+6V, +6V, +6V, -6.5V, +8V). Issue with contact to cooling rack?
With pulser input to all FEEs, only see pulser data in spectra for n-side (nnaida3+4, 7+8, 11+12, 15+16) FEEs. Other FEEs all show zero statistics.
|
| Attachment 1: RunControl_error.png
|
|
| Attachment 2: MasterTSControl_error.png
|
|
| Attachment 3: IMG_2841.JPG
|
|
| Attachment 4: IMG_2842.JPG
|
|
| Attachment 5: IMG_2843.JPG
|
|
| Attachment 6: IMG_2844.JPG
|
|
| Attachment 7: IMG_2845.JPG
|
|
|
369
|
Sun Oct 2 15:03:11 2016 |
CG, TD | Problems compiling AIDAsort program on aidas1 |
I have been trying to compile the sort program I have been working on in Edinburgh so I can work on it locally
while at RIKEN.
When compiling i receive the error shown in make.log (attached) saying that there are undefined reference in
DataSource.cpp.
Also attached is the make output when compiled in Edinburgh - basically just 'unused variable' warnings.
This is exactly the same DataSource.cpp I am using in Edinburgh. I have carried out 'diff' on the DataSpyLib and
DataXferLib directories which are included
in the Makefile and no differences are present. I have also done this for DataSource directory and again, there
are no differences between what I am running here and in Edinburgh.
The only difference I have been able to observe so far is that in Edinburgh I am using g++ version:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl=/builddir/build/BUILD /gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
whereas on aidas1:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile
--enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
The libraries used are all found in LD_LIBRARY_PATH.
On aidas1 this is: /MIDAS/Linux/lib64:/homes/npg/root/lib:/homes/npg/root/lib:/MIDAS/Linux/lib64:/homes/npg/root/lib
and in Edinburgh:
/Disk/ds-sopa-group/np/RIKEN/AIDAsort/MIDAS/Linux/lib64:/Disk/ds-sopa-group/np/thehubdata/thehub6/jlab_software/Linux_Scientific6-x86_64-gcc4.4.6/root/5.34.23/lib:
*********UPDATE 03/10/16 *************
The methods are defined in /MIDAS/DataPackage/DataXferLib/V4_TCP/transfer.c
This is in the expected INCLUDES path of: INCLUDES= -I/MIDAS/DataPackage/DataXferLib/V4_TCP -I/MIDAS/DataPackage/DataSpyLib |
| Attachment 1: make.log
|
aidas1> make
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -m64 -I/homes/npg/root/include -I/tmp/DataXferLib_edi/V4_TCP -I/tmp/DataSpyLib_edi -Iinclude/ main.cpp
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -m64 -I/homes/npg/root/include -I/tmp/DataXferLib_edi/V4_TCP -I/tmp/DataSpyLib_edi -Iinclude/ ./include/DataSource.h ./src/DataSource.cpp
In file included from ./src/DataSource.cpp:12:
include/c_functions.h:10: warning: unused parameter ‘id’
include/c_functions.h:10: warning: unused parameter ‘xclass’
include/c_functions.h:10: warning: unused parameter ‘level’
include/c_functions.h:10: warning: unused parameter ‘source’
include/c_functions.h:10: warning: unused parameter ‘body’
./src/DataSource.cpp: In member function ‘void DataSource::TransferBuffer(double)’:
./src/DataSource.cpp:345: warning: suggest parentheses around comparison in operand of ‘|’
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -m64 -I/homes/npg/root/include -I/tmp/DataXferLib_edi/V4_TCP -I/tmp/DataSpyLib_edi -Iinclude/ ./include/Unpacker.h ./src/Unpacker.cpp
./src/Unpacker.cpp:684:3: warning: "/*" within comment
./src/Unpacker.cpp: In member function ‘void Unpacker::Process(DataSource&)’:
./src/Unpacker.cpp:37: warning: unused variable ‘my_int’
./src/Unpacker.cpp: In member function ‘void Unpacker::LoadParameters(char*)’:
./src/Unpacker.cpp:425: warning: unused variable ‘line’
./src/Unpacker.cpp:427: warning: unused variable ‘ch_first’
./src/Unpacker.cpp:429: warning: unused variable ‘channel’
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -m64 -I/homes/npg/root/include -I/tmp/DataXferLib_edi/V4_TCP -I/tmp/DataSpyLib_edi -Iinclude/ ./include/Calibrator.h ./src/Calibrator.cpp
./src/Calibrator.cpp: In member function ‘void Calibrator::LoadParameters(char*)’:
./src/Calibrator.cpp:299: warning: unused variable ‘line’
./src/Calibrator.cpp:301: warning: unused variable ‘ch_first’
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -m64 -I/homes/npg/root/include -I/tmp/DataXferLib_edi/V4_TCP -I/tmp/DataSpyLib_edi -Iinclude/ ./include/Analysis.h ./src/Analysis.cpp
./src/Analysis.cpp:915:35: warning: "/*" within comment
./src/Analysis.cpp: In member function ‘void Analysis::CloseEvent()’:
./src/Analysis.cpp:146: warning: unused variable ‘b_beam’
./src/Analysis.cpp: In member function ‘void Analysis::WriteOutBuffer(DataSource&)’:
./src/Analysis.cpp:381: warning: comparison between signed and unsigned integer expressions
./src/Analysis.cpp: In member function ‘void Analysis::LoadParameters(char*)’:
./src/Analysis.cpp:1484: warning: unused variable ‘line’
./src/Analysis.cpp:1486: warning: unused variable ‘ch_first’
./src/Analysis.cpp:1488: warning: unused variable ‘channel’
g++ -lrt -m64 -L/homes/npg/root/lib -lGui -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -pthread -lm -ldl -rdynamic -L/usr/ucblib -lrt -lpthread -L/tmp/MIDAS/Linux/lib64 -ldataspy -o AIDAsort.v2.exe main.o DataSource.o Unpacker.o Calibrator.o Analysis.o
DataSource.o: In function `DataSource::InitDataSource(int, int, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, bool)':
DataSource.cpp:(.text+0x1159): undefined reference to `transferMultiBlockSize'
DataSource.cpp:(.text+0x1176): undefined reference to `transferMultiMode'
DataSource.cpp:(.text+0x1193): undefined reference to `transferMultiPort'
DataSource.cpp:(.text+0x11b2): undefined reference to `transferMultiInit'
DataSource.o: In function `DataSource::TransferBuffer(double)':
DataSource.cpp:(.text+0x133c): undefined reference to `transferMultiTxData'
collect2: ld returned 1 exit status
make: *** [AIDAsort.v2.exe] Error 1
|
| Attachment 2: make.logEdi
|
[s0804967@escrow order_sort_cg]$ make
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -std=c++11 -Wno-deprecated-declarations -m64 -I/usr/include/root -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataXferLib/V4_TCP -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataSpyLib -Iinclude/ main.cpp
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -std=c++11 -Wno-deprecated-declarations -m64 -I/usr/include/root -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataXferLib/V4_TCP -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataSpyLib -Iinclude/ ./include/DataSource.h ./src/DataSource.cpp
In file included from ./src/DataSource.cpp:12:0:
include/c_functions.h:10:5: warning: unused parameter ‘id’ [-Wunused-parameter]
int msgDefineMessage (u_int id, u_int xclass, u_int level, char *source, char *body) {
^
include/c_functions.h:10:5: warning: unused parameter ‘xclass’ [-Wunused-parameter]
include/c_functions.h:10:5: warning: unused parameter ‘level’ [-Wunused-parameter]
include/c_functions.h:10:5: warning: unused parameter ‘source’ [-Wunused-parameter]
include/c_functions.h:10:5: warning: unused parameter ‘body’ [-Wunused-parameter]
./src/DataSource.cpp: In member function ‘void DataSource::Close()’:
./src/DataSource.cpp:28:9: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]
int i;
^
./src/DataSource.cpp: In member function ‘bool DataSource::ReadBuffer()’:
./src/DataSource.cpp:149:9: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]
int i;
^
./src/DataSource.cpp: In member function ‘void DataSource::InitDataSource(int, int, std::string&, bool)’:
./src/DataSource.cpp:285:9: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]
int i;
^
./src/DataSource.cpp: In member function ‘void DataSource::TransferBuffer(double)’:
./src/DataSource.cpp:345:22: warning: suggest parentheses around comparison in operand of ‘|’ [-Wparentheses]
if(GetBuffOffset() > MAX_LENGTH_DATA | ts > (ts_0 + DELTA_TS )){
^
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -std=c++11 -Wno-deprecated-declarations -m64 -I/usr/include/root -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataXferLib/V4_TCP -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataSpyLib -Iinclude/ ./include/Unpacker.h ./src/Unpacker.cpp
./src/Unpacker.cpp:684:3: warning: "/*" within comment [-Wcomment]
/***************/
^
./src/Unpacker.cpp: In member function ‘void Unpacker::Process(DataSource&)’:
./src/Unpacker.cpp:37:16: warning: unused variable ‘my_int’ [-Wunused-variable]
unsigned int my_int;
^
./src/Unpacker.cpp: In member function ‘void Unpacker::LoadParameters(char*)’:
./src/Unpacker.cpp:425:8: warning: unused variable ‘line’ [-Wunused-variable]
char line[1024]; // string or char array?
^
./src/Unpacker.cpp:427:8: warning: unused variable ‘ch_first’ [-Wunused-variable]
char ch_first;
^
./src/Unpacker.cpp:429:15: warning: unused variable ‘channel’ [-Wunused-variable]
int module, channel;
^
./src/Unpacker.cpp:430:10: warning: variable ‘data’ set but not used [-Wunused-but-set-variable]
double data;
^
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -std=c++11 -Wno-deprecated-declarations -m64 -I/usr/include/root -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataXferLib/V4_TCP -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataSpyLib -Iinclude/ ./include/Calibrator.h ./src/Calibrator.cpp
./src/Calibrator.cpp: In member function ‘void Calibrator::LoadParameters(char*)’:
./src/Calibrator.cpp:299:8: warning: unused variable ‘line’ [-Wunused-variable]
char line[1024]; //
^
./src/Calibrator.cpp:301:8: warning: unused variable ‘ch_first’ [-Wunused-variable]
char ch_first; //
^
g++ -c -Wall -Wextra -DUNIX -DLINUX -DLINUX64 -DPOSIX -pthread -std=c++11 -Wno-deprecated-declarations -m64 -I/usr/include/root -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataXferLib/V4_TCP -I/Disk/ds-sopa-group/np/RIKEN/AIDAsort/DataSpyLib -Iinclude/ ./include/Analysis.h ./src/Analysis.cpp
./src/Analysis.cpp:915:35: warning: "/*" within comment [-Wcomment]
/*int m_side[32]= {1,1,0,0, /* 1:4 */
^
./src/Analysis.cpp: In member function ‘void Analysis::CloseEvent()’:
./src/Analysis.cpp:146:8: warning: unused variable ‘b_beam’ [-Wunused-variable]
bool b_beam= false;
^
./src/Analysis.cpp: In member function ‘void Analysis::WriteOutBuffer(DataSource&)’:
./src/Analysis.cpp:381:65: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for(int i= offset; i< offset+sizeof(evt_data)+sizeof(int32_t); i++){
^
./src/Analysis.cpp: In member function ‘void Analysis::LoadParameters(char*)’:
./src/Analysis.cpp:1484:8: warning: unused variable ‘line’ [-Wunused-variable]
char line[1024]; // string or char array?
^
./src/Analysis.cpp:1486:8: warning: unused variable ‘ch_first’ [-Wunused-variable]
char ch_first;
^
./src/Analysis.cpp:1488:15: warning: unused variable ‘channel’ [-Wunused-variable]
int module, channel;
^
g++ -lrt -m64 -L/usr/lib64/root -lGui -lCore -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lMultiProc -pthread -lm -ldl -rdynamic -L/usr/ucblib -lrt -lpthread -L/Disk/ds-sopa-group/np/RIKEN/AIDAsort/MIDAS/Linux/lib64 -lxfer -ldataspy -o AIDAsort.v2.exe main.o DataSource.o Unpacker.o Calibrator.o Analysis.o
|
| Attachment 3: transfer.h
|
#ifndef INCtransferh
#define INCtransferh
#define MAX_STREAM 4
#define MAXPORTS 8
typedef struct block_header { /* format of data block */
unsigned short hdr_flags; /* see below */
unsigned short hdr_stream; /* =0 for forced ack request or 1=>MAX_STREAM */
unsigned short hdr_endian; /* data byte order */
unsigned short hdr_ID;
unsigned int hdr_sequence; /* for this stream */
unsigned int hdr_blocklength; /* total length of this block including the header */
unsigned int hdr_datalength; /* length of user data in the block */
unsigned int hdr_offset; /* very large blocks may be fragmented */
unsigned int hdr_id1; /* for spy to locate header =0x19062002 */
unsigned int hdr_id2; /* for spy to locate header =0x09592400 */
} HEADER;
#define HDR_ID1 0x19062002
#define HDR_ID2 0x09592400
typedef struct mbs_block_header {
unsigned int mbs_endian;
unsigned int mbs_blocksize;
} MBS_BLKHEADER;
typedef struct ack {
unsigned short acq_flags; /* bit 0 = 1 for ack */
unsigned short acq_code; /* =0 for good ack otherwise error reason */
unsigned short acq_ts_state; /* tape server state - see below */
unsigned short acq_stream; /* =0 for forced ack ack or 1=>MAX_STREAM */
unsigned short acq_endian; /* =1 transmitted in host byte order */
unsigned short acq_ID; /* value of ID variable 0 => */
unsigned int acq_sequence; /* for stream != 0 is sequence being acked */
unsigned short acq_stream_state1; /* see below */
unsigned short acq_stream_state2; /* */
unsigned short acq_stream_state3; /* */
unsigned short acq_stream_state4; /* */
unsigned short acq_stream_window1; /* */
unsigned short acq_stream_window2; /* */
unsigned short acq_stream_window3; /* */
unsigned short acq_stream_window4; /* */
} ACK;
int transferTxData (char *, int, int);
int transferTxRestart ();
int transferBlockSize(int);
int transferMode(int);
int transferBlockMode(int);
int transferEndian(int);
int transferPort(int);
int transferInit (char *);
void transferClose ();
int transferStatus ();
int transferSetVerbose(int);
int transferSetUser(int);
int transferNice(int);
int transferUseOverlap(int);
int transferTxWait();
int transferState();
int transferSndBufSize(int);
int transferRcvBufSize(int);
/* All these have the thread ID as the first argument */
int transferMultiTxData (int, char *, int, int);
int transferMultiTxRestart (int);
int transferMultiBlockSize(int, int);
int transferMultiMode(int, int);
int transferMultiBlockMode(int, int);
int transferMultiEndian(int, int);
int transferMultiPort(int, int);
int transferMultiInit (int, char *);
void transferMultiClose (int);
int transferMultiStatus (int);
int transferMultiNice(int, int);
int transferMultiUseOverlap(int, int);
int transferMultiTxWait(int);
int transferMultiState(int);
int transferMultiSndBufSize(int, int);
int transferMultiRcvBufSize(int, int);
#ifndef OK
#define OK 0
#endif
#ifndef ERROR
#define ERROR -1
#endif
#endif
|
|
637
|
Tue Jun 6 07:44:19 2017 |
TD | Preamplifier waveforms | Preamplifier waveforms sampled by 50MSPS, 14 bit ADC
attachment 1 - nnaida13 ASIC settings (+ input)
attachment 2 - nnaida16 ASIC settings (- input)
beam on
-------
attachments 3-5 - three successive waveform updates nnaida13 asic #1 - 1000ch = 20us
attachments 6-8 - three successive waveform updates nnaida13 asic #1 - 1000ch = 2ms
attachments 9-11 - three successive waveform updates nnaida16 asic #1 - 1000ch = 20us
attachments 12-14 - three successive waveform updates nnaida16 asic #1 - 1000ch = 2ms
beam off
--------
attachments 15-18 - three successive waveform updates nnaida13 asic #1 - 1000ch = 2ms
attachments 19-21 - three successive waveform updates nnaida16 asic #1 - 1000ch = 2ms
attachments 22-23 - three successive waveform updates nnaida16 asic #1 - 1000ch = 2ms, y-scale expanded
attachments 24-25 - three successive waveform updates nnaida13 asic #1 - 1000ch = 2ms, y-scale expanded |
| Attachment 1: 100.png
|
|
| Attachment 2: 101.png
|
|
| Attachment 3: 102.png
|
|
| Attachment 4: 103.png
|
|
| Attachment 5: 104.png
|
|
| Attachment 6: 105.png
|
|
| Attachment 7: 106.png
|
|
| Attachment 8: 107.png
|
|
| Attachment 9: 108.png
|
|
| Attachment 10: 109.png
|
|
| Attachment 11: 110.png
|
|
| Attachment 12: 111.png
|
|
| Attachment 13: 112.png
|
|
| Attachment 14: 113.png
|
|
| Attachment 15: 100.png
|
|
| Attachment 16: 101.png
|
|
| Attachment 17: 102.png
|
|
| Attachment 18: 103.png
|
|
| Attachment 19: 104.png
|
|
| Attachment 20: 105.png
|
|
| Attachment 21: 106.png
|
|
| Attachment 22: 110.png
|
|
| Attachment 23: 111.png
|
|
| Attachment 24: 112.png
|
|
| Attachment 25: 113.png
|
|
|
13
|
Wed Oct 1 15:41:07 2014 |
Patrick Coleman-Smith | Power supply filters #3 | Measuring the signal at the FEE64 end.
+5v , -6v , +7v, +7v
The two other 'scope channels are connected by FET probes to the FEE64. I now see there is a ground connection.... so i will remove it and re-measure the signals in the filter.
No real difference.
Measuring at the FEE64 and the spikes when the Mux ADC is reading out have disappeared. |
| Attachment 1: RTOScreenshot_2014-10-01_17_152532.png
|
|
| Attachment 2: RTOScreenshot_2014-10-01_18_152907.png
|
|
| Attachment 3: RTOScreenshot_2014-10-01_19_152935.png
|
|
| Attachment 4: RTOScreenshot_2014-10-01_20_153021.png
|
|
| Attachment 5: RTOScreenshot_2014-10-01_21_153113.png
|
|
|
11
|
Wed Oct 1 13:28:03 2014 |
Patrick Coleman-Smith | Power supply filters | The new pcb for the power supply filter arrived.
I assembled the components ( after finding the whoops ) and connected it to the bench power supply for nnaida2.
nnaida2 functions just about the same as before but the power supply filter results seem amazing.
I have measured the signals on the power supply before and after the filter.
The 'scope is referenced to earth on the filter board and this earth is connected to earth through the +5v@10A supply.
Before the filter the average noise on the rail ( AC coupled ) is 33mV and after is ....... 5mV pretty exciting stuff.
I have attached the two 'scope pictures.
The same measurements on the +7v, -6v and 0v rails give similar improvements.
The choke on the +5v rail measures 34 degrees C so care will need to be taken.
Next I will measure the voltage drops across the filter and decide on the correct voltage settings for the AIDA switch mode power supply.
Then install the filter into the supply and check ..... and check ......
|
| Attachment 1: RTOScreenshot_2014-10-01_1_121051.png
|
|
| Attachment 2: RTOScreenshot_2014-10-01_0_121012.png
|
|
|
12
|
Wed Oct 1 15:15:32 2014 |
Patrick Coleman-Smith | Power supply filters | 2.0.L FWHM:14.26
2.15.L ( 270pF ) FWHM : 119.04
(ooops found the 'scope channel was on 20Mhz BW filter )
DC measurements.
At FEE64 :- +7.822 , -6.36, +4.937
at Filter output ( AIDA Cable input ) :- +7.96, -6.46, 5.37
at filter input:- +7.97, -6.476, +5.488
Set supply with these voltages and add filter.
Measured earth point to mains earth pin as 0.095ohms.
Power-up with nnaida2. ADCs Calibrate fine....successful boot.
Voltages at FEE64:- +7.802, -6.324, +4.887. I will adjust the power supply voltages to match the FEE64 previous setup.
2.0.L FWHM :13.83
2.15.L FWHM:116.6
So not really a difference in performance at this simple level.
Attached are some oscilloscope traces of the six voltage rails after the filter on the filter board. +5v & 0v , -6v & 0v, +7v & 0v relative to the earth on the filter board.
Attached are some oscilloscope traces of the six voltage rails before the filter on the filter board. +5v & 0v , -6v & 0v, +7v & 0v relative to the earth on the filter board.
There is a nice sine wave at 235KHz that needs to be finished off perhaps. Otherwise the filter seems to be doing well.
Next set of 'scope traces are across the three supplies. +7v, -6v, +5v.
Sine wave is present ( 220KHz ) at 80mv, 80mv, 105mv.
Next I'll try this supply on nnaida12 ( detector negative ) ...... next entry ....
|
| Attachment 1: RTOScreenshot_2014-10-01_2_145340.png
|
|
| Attachment 2: RTOScreenshot_2014-10-01_3_145424.png
|
|
| Attachment 3: RTOScreenshot_2014-10-01_4_145509.png
|
|
| Attachment 4: RTOScreenshot_2014-10-01_5_145529.png
|
|
| Attachment 5: RTOScreenshot_2014-10-01_6_145604.png
|
|
| Attachment 6: RTOScreenshot_2014-10-01_7_145655.png
|
|
| Attachment 7: RTOScreenshot_2014-10-01_8_145838.png
|
|
| Attachment 8: RTOScreenshot_2014-10-01_9_145902.png
|
|
| Attachment 9: RTOScreenshot_2014-10-01_11_150000.png
|
|
| Attachment 10: RTOScreenshot_2014-10-01_12_150025.png
|
|
| Attachment 11: RTOScreenshot_2014-10-01_13_150050.png
|
|
| Attachment 12: RTOScreenshot_2014-10-01_14_151051.png
|
|
| Attachment 13: RTOScreenshot_2014-10-01_15_151141.png
|
|
| Attachment 14: RTOScreenshot_2014-10-01_16_151223.png
|
|
|
226
|
Fri May 13 13:27:50 2016 |
patrick Coleman-Smith | Power supply changes and blowing fuses ! | Reading about the power supply changes and the requirement to replace fuses leads me to be concerned.
I think the power being changed is the AC input to the FEE64 power supplies.
Which Fuses are failing ? |
|
422
|
Fri Nov 4 08:10:46 2016 |
CG | Pb bricks upstream | Stack of Pb bricks upstream of AIDA+BRIKEN to protect from incoming beam. |
|
865
|
Wed Mar 1 16:42:06 2023 |
Further results from Mezzanine bench tests | PJCS | Carried out some further work on failed mezzanine modules.
Inspected them externally and removed the copper block, internally with a bench microscope.
Found two obvious faults ..... broken components with scrambled pcb tracks.
To help determine problems with loading control registers I've added a new menu item in the ASIC control window to allow all four ASIC return values to be checked. This is only useful at the mezzanine test system.
Tested 7 that were labelled as faulty. Failed all of them. 2 with broken components and 1 with some broken bond wires.
Tested one fresh from the cupboard. It failed with over current on the +5v psu ( > 4A! ).
I propose to create a method of testing these mezzanines which allows better access to the power supply regulators ( LT3080 ) and the associated control voltage.
|
| Attachment 1: mezz_cap_gone_resized.jpg
|
|
| Attachment 2: mezz_resistors_resized.jpg
|
|
|
849
|
Mon Jun 17 03:01:04 2019 |
CA, TD, OH | PID plot and selected isotope implantation rates | PID plot produced from 2 hours of merged data - attachment 1
Z on y-axis, A/Q on x-axis
numbers estimated by gating on each isotope and integrating
94Ag - 10584 events in 2hrs
97In - 42 events in 2 hrs
100Sn - 56 events in 2 hrs
94Pd - 383030 events in 2 hrs |
| Attachment 1: 2hrPID.pdf
|
|
|