Displaying report 1-1 of 1.
Reports until 16:09, Tuesday 28 June 2016
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 16:09, Tuesday 28 June 2016 - last comment - 18:09, Tuesday 28 June 2016(28025)
CDS maintenance summary

omc_pi model change. WP5957

Kiwamu, Carl, Dave:

h1omcpi was modifed to read in the two new ADC channels. Two new 64kHz channels were added to the commissioning frame, 8 existing 2kHz channels were added to the science frame for permanent archival (H1:OMC-PI_DOWNCONV[1-4]_DEMOD_[I,Q]_OUT_DQ)

h1 SUS PI model changes

Ross, Carl, Dave:

new h1susitmpi,h1susetm[x,y]pi models were installed.

DAC card replacement in SUS B123 and H2A WP5954, WP5953

Richard, Fil, Dave, Jim

h1susb123 and h1sush2a were powered down. The first DAC card in each IO Chassis were replaced. The new DAC cards both pass the autocal. The ADCs were power cycled at the same time.

BSC ISI code change WP5961

Brian, Jim W, Jim, Dave

a new isi2stagemaster.mdl file were installed. All BSC ISI models were rebuilt and restarted. (h1isi[bs, itmx, itmy, etmx, etmy]). Part of this change was to remove the user model's DACKILL part. Since this part registers itelf with the IOP model on startup, the code change required a restart of all the models on h1seib[1,2,3,ex,ey] to resync the IOP with the DAC clients.

We also found that the HEPI watchdog reset button does not work on newer Ubuntu 14 machines. This was tracked to the perl script wd_dackill_reset.pl script requires the CAP5 module, not loaded on newer machines. Perhaps these old PERL scripts should be replaced with newer PYTHON scripts.

DAQ upgrades and new QFS server WP5964

Dan, Carlos  Jim, Dave:

Dan upgraded the QFS servers h1ldasgw0, h1ldasgw1 and h1dmtqfs0 Solaris machines. These were fully patched, and the QFS file sysem they control was file-system-checked.

Dan installed a new QFS server called h1ldasgw2. This is a Sun X2200, with redundent fiber channel ports which directly connect to the two Qlogic switches.

In the new configuration, h1ldasgw0 only exports /ldas-h1-frames to h1fw0 on the private LAN (no longer exports to h1nds0). h1ldasgw1 only exports /cds-h1-frames to h1fw1 on the private LAN (no longer exports to h1nds1). h1ldasgw2 NFS exports both /ldas-h1-frames and /cds-h1-frames to both nds machines in read-only mode.

The hope is that the frame writers will be more stable if their NFS/QFS server is not also serving NDS requests.

h1nds1's RAM was doubled from 24GB to 48GB by the insertion of 3*8GB SIMM cards harvested from x1work.

ASC new code

Jenne, Jim, Dave

new h1asc model was installed. We were surprised that an excitation was started immediately once the model got running. This looks like a script constantly running the excitation of H1:ASC-POP_X_PZT_YAW_EXC

Does anyone know what is doing this?

DAQ Restart

Daniel, Dave:

The DAQ was restarted to support all of the above model changes. Latest Beckhoff INI files were installed.

Tesing Scientific Linux 7.2 on LHO DMT WP5969

Dan:

Dan is upgrading h1dmt2 from SL6.5 to SL7.2 as a test bed for the new OS in preparation for a pre-ER9 upgrade.

cdswiki upgrade WP5956

Jonathan, Carlos:

work is underway to upgrade the cdswiki machine

Comments related to this report
david.barker@LIGO.ORG - 18:04, Tuesday 28 June 2016 (28031)

mysterious ASC excitation found, the ASC is running a special awg_tp_man process to provide more than 35 testpoint channels. The restart of the model did not restart the awgtpman process, so the running excitation was immeditely applied to the new system. Jim is investigating to see how this can be prevented, for now the process was restarted by hand.

david.barker@LIGO.ORG - 18:07, Tuesday 28 June 2016 (28032)

h1fw1 is unstable again.

After being stable since last Friday, following today's maintenance h1fw1 is now very unstable. We tried the power cycle of the h1ldasgw1 solaris box, which did not fix the stability problem unlike last Friday. h1fw0 also restarted itself since the last DAQ restart, but just the once compared with h1fw1's many.

david.barker@LIGO.ORG - 18:09, Tuesday 28 June 2016 (28033)

here is an interesting error in h1fw1's log file on the last attemped restart

[Tue Jun 28 18:07:42 2016] ->3: start profiler
[Tue Jun 28 18:07:42 2016] ->3: # comment out this block to stop saving data
[Tue Jun 28 18:07:42 2016] ->3: # Write commissioning (full) frames
[Tue Jun 28 18:07:42 2016] frame saver started
[Tue Jun 28 18:07:42 2016] main profiler thread thread - label dqpmain pid=10592
[Tue Jun 28 18:07:42 2016] ->3: start frame-saver
[Tue Jun 28 18:07:42 2016] waiting on frame_saver semaphore
[Tue Jun 28 18:07:42 2016] Full frame saver thread - label dqfulfr pid=10593
[Tue Jun 28 18:07:42 2016] Full frame saver thread priority error Operation not permitted
[Tue Jun 28 18:07:43 2016] waiting on frame_saver semaphore
[Tue Jun 28 18:07:44 2016] waiting on frame_saver semaphore
[Tue Jun 28 18:07:45 2016] waiting on frame_saver semaphore
[Tue Jun 28 18:07:46 2016] waiting on frame_saver semaphore

 

Displaying report 1-1 of 1.