Reports 1-1 of 1 Clear search Modify search
AdV-DAQ (Data Acquisition and Global Control)
masserot - 6:04 Friday 09 April 2021 (51363) Print this report
ALS NEB - rtpc22

This morning the rtpc20 used for ALS NEB was not receiving anymore the Tolm packets coming on its Tolm link id 1  since

  • NEB_ALS_Tpro> 2021-04-08-22h47m13-UTC>WARNING-Missing packets [CEB_ADC_ALS0_1,NEB_ADC_ALS1_0,NEB_FASTDAC_ALS_0,NEB_DEMOD_ENV_2,NEB_ADC_ALS0_1]

 The NEB_DBOX_ALS  DaqBox is still reachable from the others rtpcs connected to the same MxDx_SN19 meaning that the Tolm path between the rtpc22-link1 and the MxDx_v2_SN19_link10 is not working .As trial to recover the faulty link::

  • the ALS _BPC and power loops were opened ,
  • the rtpc22 servers were stopped
  • and the rtpc22 was rebooted

Unfortunately it did not work . Next steps:

  • in the DAQ room , MxDx rack (rack14) ,  on the MxDx_v2_SN19  link id 10, unplug the optical receiver and the fiber and then plug them
  • logon as virgorun on the rtpc22  and execute the command below to see if the path between the rtpc22 and MxDx_S19 is restored
    • /virgoApp/DaqBox/v15r6/Linux-x86_64-CL7-4.9.80-hal-4-rtai-5.1/MuxDemuxCtl.exe  -k 1 -t 0x1d
  • if the previous command is OK,
    • perform a reloadConfig of the NEB_ALS_dbox server
    • when the previous command is finished and successfull , the others servers can be restarted
Comments to this report:
masserot - 9:21 Friday 09 April 2021 (51365) Print this report

Thank to Andrea  we succeeded to recover the Tolm path between the rtpc22 and the MxDx_v2_SN19_lk10 .

Anyway it was needed to unplug and to plug-back at each part the optical tranceiver to recover it

Search Help