Displaying report 1-1 of 1.
Reports until 18:31, Friday 18 October 2013
LHO General
patrick.thomas@LIGO.ORG - posted 18:31, Friday 18 October 2013 - last comment - 09:04, Monday 21 October 2013(8164)
Testing bug fix to dust monitor code
Dave B., Jim B., Patrick T., Richard M., Robert S.

This was an experiment to test a fix to the 'noise' documented in alog 8076.

The problem may be that the sampling method used in the previous code (device support met_one_227b-1.0.1) may have initiated a short stage to purge the air path through the dust monitor before the start of each sample, and this was not happening with the new code (device support met_one_227b_comp_ctrl-1.0.0).

The previous code used this command:
"d" Start Counting (counter controlled): The counter will begin counting and control the count cycle based on the front-panel setting for period (sample time).

From Robert's comments in his original iLIGO code (http://blue.ligo-wa.caltech.edu/apps/epics/3.12.2.pem.llo/release/r3.12.2.PEM.LLO/base/src/drv/ansi/drvDustMetOne227.c):
The sample time is set in the dust monitor. This routine uses the "d" command (dust monitor control) rather than the "c" command (computer control). The advantage is that you can start several monitors almost simultaneously rather than sequentially. The monitor purges for two seconds before starting the sample - important for time stamping the sample. 

The new code uses the following command:
"c" Start Counting (computer controlled): The counter will begin counting without waiting for an even second boundary (quick start). Counting will continue until stopped by the computer. The count cycle should be controlled by the computer.
It may be that the "c" command does not run a purge prior to counting.

I added the following separate command with a short sleep after it before the "c" command and started testing it with the dust monitors in the optics labs:
"g" Active Mode: The counter will enter a mode that prepares it for counting. For example, the air pump may turn on to purge the air path.
It is unclear if this runs for a set period or until it receives the next command.

I added a one second sleep after each iteration through the dust monitors to address the code's high CPU use as well. I also added one second sleeps after caught exceptions in drv227b.cpp to provide some time to read the printed error message.

13:30: I stopped the dust monitor code for the optics labs and started the modified code. The sleep after the "g" command was set to 2 seconds.
14:00: I stopped the modified code, changed the sleep to 5 seconds, and restarted it.
14:14: I stopped the modified code again, changed the sleep back to 2 seconds, and restarted it.
15:00: I stopped the modified code.
- I checked the modified code into subversion. -
18:03: I restarted the modified code in 'screen' on h0epics from /ligo/apps/linux-x86_64/epics-3.14.12.2_long_sc/iocs/dust/dust_met_one_227b_comp_ctrl-1.1.0.

I have attached a plot of the dust counts in the Vacuum Prep Lab over this period. The change appears to have helped.

I will let this run over the weekend.
Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 08:39, Monday 21 October 2013 (8186)

Long story short - for those of us trending particulate from these channels, do we trust the magnitude of the signal, even though many signals are always showing ~80 cts?

patrick.thomas@LIGO.ORG - 08:54, Monday 21 October 2013 (8187)
No, do not trust the counts since October 8.
betsy.weaver@LIGO.ORG - 08:59, Monday 21 October 2013 (8188)

Brilliant.

patrick.thomas@LIGO.ORG - 09:04, Monday 21 October 2013 (8189)
It appears that it core dumped around Oct 19 2013 11:35:33 PDT. I'm going to restart it outside of 'screen' to see if I can reproduce the error and get better diagnostics.
Displaying report 1-1 of 1.