| | 1 | = Trouble Shooting - FADs = |
| | 2 | |
| | 3 | |
| | 4 | == Crate Reset |
| | 5 | |
| | 6 | There exist a script which will do the __Crate Reset__ automatically: |
| | 7 | |
| | 8 | - _.x ScriptsForDimCtrl/ResetCrate.dim C=n_ |
| | 9 | - n = number of crate you want to reset |
| | 10 | |
| | 11 | Crate Reset manually: |
| | 12 | |
| | 13 | - disable all FTUs (in the FTU tab of the GUI) |
| | 14 | - disconnect the 10 FADs in the crate, by clicking the LEDs |
| | 15 | - ftmctrl/RESET_CRATE x (x corresponding crate) |
| | 16 | - enable all FTUs (in the FTU tab of the GUI) |
| | 17 | - reconnect the 10 FADs, one by one with 3 seconds waiting in between (the FAD needs this time to boot) |
| | 18 | |
| | 19 | == start up - connection problem |
| | 20 | |
| | 21 | __Symptom__ |
| | 22 | |
| | 23 | - problem occurs usually during start up |
| | 24 | - after FAD_CONTROL/START or pushing FAD -> START button in the GUI, not all 40 FAD LEDs are green |
| | 25 | - fadctrl is in state Connecting (instead of Connected) |
| | 26 | |
| | 27 | __Solution__ |
| | 28 | |
| | 29 | - stop dimscripts |
| | 30 | - dimctrl --stop from a bash |
| | 31 | - do a __crate reset__: |
| | 32 | |
| | 33 | __Not Helping__ |
| | 34 | |
| | 35 | - disconnect / reconnect to the FAD. |
| | 36 | - waiting |
| | 37 | - reset other / all crates (might just create another of these bugs in another FAD) |
| | 38 | - stopping or killing fadctrl |
| | 39 | - power cycling the camera (might just create another of these bugs in another FAD) |
| | 40 | |
| | 41 | == In-run-FAD-loss |
| | 42 | |
| | 43 | __Symptom__ |
| | 44 | |
| | 45 | - during a run: |
| | 46 | - 4 adjacent *strange* patches in the events tab of the GUI |
| | 47 | - orange warnings in fadctrl-console (eventbuilder realises, that one FAD stopped sending data) |
| | 48 | - trigger rate drop to 0 |
| | 49 | - when the run ended and a new one is started |
| | 50 | - MCP hang in state Configuring3 |
| | 51 | - fadctrl hang in state Configuring2 |
| | 52 | |
| | 53 | __Solution__ |
| | 54 | |
| | 55 | - find out which FAD board is disconnected |
| | 56 | - the one board in the FAD tab which has the strange behaviour |
| | 57 | - the one without a thick on its LED in the GUI (is only possible to see, when a new run is started and the system hangs in ConfiguringN) |
| | 58 | - stop dimscript (by dimctrl --stop from a bash) |
| | 59 | - only possible when dimctrl was started as a server instance (dimctrl --server) |
| | 60 | - otherwise you have to kill dimctrl via ctrl + c |
| | 61 | - reset MCP (MCP/RESET) |
| | 62 | - Disconnect the problematic FAD (clicking on the corresponding LED in the GUI |
| | 63 | - wait 3 to 5 sec |
| | 64 | - Reconnect the problematic FAD (again clicking) |
| | 65 | |
| | 66 | __Not Helping__ |
| | 67 | |
| | 68 | - waiting |
| | 69 | - reset any crates (might just create another start up connection problem) |
| | 70 | - stopping or killing fadctrl |
| | 71 | - power cycling the camera (might just create another start up connection problem) |
| | 72 | |
| | 73 | == DRS underflow problem |
| | 74 | |
| | 75 | __Symptom__ |
| | 76 | |
| | 77 | - happens usually during start up |
| | 78 | - during first data taking one single patch in the events tab appears different (e.g. all dark blue) |
| | 79 | - after the 3 calibration runs are taken by the system, the calibration constants behave different: |
| | 80 | - the magenta line (normally around +1000mV) has pretty long error bars and is curved over the whole canvas |
| | 81 | |
| | 82 | __Solution__ |
| | 83 | |
| | 84 | - stop dimscript |
| | 85 | - dimctrl --stop from a bash |
| | 86 | - Reset crate (see <A HREF="#tscratereset">above</A>) |
| | 87 | - this doesn't helped often, but it doesn't need so much time as the power cycle |
| | 88 | - if the problem appears again: __power cycle__ the camera (see <A HREF="#tshardware">below</A>) |
| | 89 | |
| | 90 | __Not Helping__ |
| | 91 | |
| | 92 | - all the rest |
| | 93 | |
| | 94 | == startup - no proper connection problem |
| | 95 | |
| | 96 | __Symptom__ |
| | 97 | |
| | 98 | - happens usually during start up |
| | 99 | - several FADs are in state "Waiting" (orange in the GUI) |
| | 100 | |
| | 101 | __Solution__ |
| | 102 | |
| | 103 | - disenable the corresponding FADs by clicking in the GUI on them |
| | 104 | - wait a short time |
| | 105 | - enable the corresponding FADs by clicking again on them (wait 3 seconds between two clicks) |
| | 106 | |
| | 107 | __Not Helping__ |
| | 108 | |
| | 109 | - killing / quiting of fadctrl |
| | 110 | |
| | 111 | == fadctrl hangs in state configuring by taking an external lp run |
| | 112 | |
| | 113 | __Symptom__ |
| | 114 | |
| | 115 | - fadctrl hangs in state configuring when it starts the external lp run during datataking (point 17. under [[datatakingdetails#normaldata normal datataking procedure]] the 9. run) |
| | 116 | - all FADs are connected (if not all FADs are connected it is a FAD connection loss (see above) |
| | 117 | |
| | 118 | __Solution__ |
| | 119 | |
| | 120 | - normally the shifter just forgot to open the lid, so |
| | 121 | - stop script |
| | 122 | - open the lid (see [[preparation#startup Start Up procedure]] , point 9) |
| | 123 | |
| | 124 | __Not Helping__ |
| | 125 | |
| | 126 | - all the rest |
