Search criteria
Section: H2
Task: CDS
WP 12641. "Install git and clone the vacuum repos on the vacuum machines where it has not yet been done. Update the scripts used to copy the channel lists from each of the Beckhoff vacuum machines to CDS to additionally copy the EPICS database files. Run the scripts on each of the vacuum machines. No expected downtime or impacts." I have completed the work on h0vaclx, h0vacly and h0vacmr and copied the auto generated EPICS IOC database files over. These did not need git to be installed. I did not do the remaining machines since I do not believe they are running out of the git repos and I was getting nervous. A couple of small issues. On h0vaclx I accidentally committed the change to the copy script before pulling changes from the remote repo. On h0vacmr more changes came down in the pull from the remote repo than I was expecting. h0vaclx: $ git pull remote: Enumerating objects: 15, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (5/5), done. remote: Total 15 (delta 2), reused 2 (delta 2), pack-reused 8 (from 1) Unpacking objects: 100% (15/15), 3.90 KiB | 124.00 KiB/s, done. From https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum d27c3eb..0faf5c4 main -> origin/main Merge made by the 'ort' strategy. Source/Scripts/h0vacly_create_target.ps1 | 6 ++++-- Target/H0VACLY/scp.bat | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) $ git log commit 4bc3d2a5267797ae947c596e1f5007183cf3cfd4 (HEAD -> main) Merge: f217076 0faf5c4 Author: Patrick ThomasDate: Tue Jul 1 10:34:45 2025 -0700 Merge branch 'main' of https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum commit f2170760b6c51d68eb4a1d8b32466f044a882303 Author: Patrick Thomas Date: Tue Jul 1 10:33:23 2025 -0700 Added the EPICS database file to the list of files to copy over. commit 0faf5c4aeb5c61116a5abf0573cb3d09ffdc9e7c (origin/main, origin/HEAD) Author: Patrick Thomas Date: Tue Jun 24 11:46:18 2025 -0700 Updated host name. h0vacmr: $ git pull remote: Enumerating objects: 303, done. remote: Counting objects: 100% (75/75), done. remote: Compressing objects: 100% (31/31), done. remote: Total 303 (delta 59), reused 44 (delta 44), pack-reused 228 (from 1) Receiving objects: 100% (303/303), 7.56 MiB | 8.56 MiB/s, done. Resolving deltas: 100% (89/89), completed with 11 local objects. From https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum 3687c4f..4c1c97d main -> origin/main Updating 3687c4f..4c1c97d Fast-forward Library/2010/Vacuum/Vacuum.project.~u | 4 + Library/2010/Vacuum/Vacuum.sln | 44 + Library/2010/Vacuum/Vacuum.suo | Bin 0 -> 19968 bytes Library/2010/Vacuum/Vacuum.tsproj | 13 + Library/2010/Vacuum/Vacuum.tsproj.bak | 4 + .../2010/Vacuum/Vacuum/DUTs/SmoothStateEnum.TcDUT | 12 + .../Controls/ColdCathodeGaugePowerControlFB.TcPOU | 41 + .../Vacuum/POUs/Controls/PIControllerFB.TcPOU | 96 + .../Controls/RegenHeaterTemperatureControlFB.TcPOU | 160 + .../AnnulusIonPumpMilliAmpsToLogMilliAmpsFun.TcPOU | 23 + .../AnnulusIonPumpMilliAmpsToTorrFun.TcPOU | 33 + .../AnnulusIonPumpVoltsToMilliAmpsFun.TcPOU | 19 + .../POUs/Conversions/CC10/CC10VoltsToTorrFun.TcPOU | 31 + .../ColdCathodeGaugeTorrToLogTorrFun.TcPOU | 23 + .../ColdCathodeGaugeVoltsToTorrFun.TcPOU | 23 + .../CryopumpMilliAmpsToPercentFullFun.TcPOU | 27 + ...evelControlValvePercentOpenToMilliAmpsFun.TcPOU | 27 + .../Dewar/DewarMilliAmpsToPercentFullFun.TcPOU | 27 + .../Dewar/DewarPercentFullToGallonsFun.TcPOU | 20 + ...ineMilliAmpsToPoundsPerSquareInchGaugeFun.TcPOU | 27 + ...eLineMilliAmpsToStandardLitrePerMinuteFun.TcPOU | 27 + ...FanVibrationMilliAmpsToInchesPerSecondFun.TcPOU | 27 + ...GateValveLimitSwitchesToPositionNumberFun.TcPOU | 33 + ...teValvePositionNumberToAnimationNumberFun.TcPOU | 32 + ...ateValvePositionNumberToPositionStringFun.TcPOU | 29 + .../GaugeControllerMKS937VoltsToTorrFun.TcPOU | 21 + .../Conversions/IO/EL3004CountsToVoltsFun.TcPOU | 27 + .../IO/EL3024CountsToMilliAmpsFun.TcPOU | 27 + .../IO/EL3314CountsToDegreesCelsiusFun.TcPOU | 19 + .../IO/EL4024MilliAmpsToCountsFun.TcPOU | 32 + .../Inficon/InficonBPG402TorrToLogTorrFun.TcPOU | 23 + .../Inficon/InficonBPG402VoltsToTorrFun.TcPOU | 19 + ...mentAirVoltsToPoundsPerSquareInchGaugeFun.TcPOU | 27 + .../IonPumpControllerDualVacTorrToStatusFun.TcPOU | 23 + ...nPumpControllerDualVacVoltsToKiloVoltsFun.TcPOU | 34 + .../IonPumpControllerDualVacVoltsToTorrFun.TcPOU | 25 + .../IonPumpControllerGammaAmpsToTorrFun.TcPOU | 21 + .../IonPumpControllerGammaTorrToStatusFun.TcPOU | 23 + .../IonPumpControllerGammaVoltsToAmpsFun.TcPOU | 19 + ...IonPumpControllerGammaVoltsToKiloVoltsFun.TcPOU | 34 + .../IonPumpControllerIPCMiniAmpsToTorrFun.TcPOU | 31 + .../IonPumpControllerIPCMiniTorrToStatusFun.TcPOU | 23 + .../IonPumpControllerIPCMiniVoltsToAmpsFun.TcPOU | 27 + ...nPumpControllerIPCMiniVoltsToKiloVoltsFun.TcPOU | 34 + .../IonPumpControllerMiniVacAmpsToTorrFun.TcPOU | 31 + .../IonPumpControllerMiniVacTorrToStatusFun.TcPOU | 23 + .../IonPumpControllerMiniVacVoltsToAmpsFun.TcPOU | 27 + ...nPumpControllerMiniVacVoltsToKiloVoltsFun.TcPOU | 34 + .../IonPumpControllerMultiVacTorrToStatusFun.TcPOU | 23 + ...PumpControllerMultiVacVoltsToKiloVoltsFun.TcPOU | 34 + .../IonPumpControllerMultiVacVoltsToTorrFun.TcPOU | 25 + .../POUs/Conversions/LinearConversionFun.TcPOU | 31 + .../PiraniGauge/PiraniGaugeVoltsToTorrFun.TcPOU | 55 + .../RegenHeaterDegreesCelsiusToMilliAmpsFun.TcPOU | 27 + ...aterPressureVoltsToPoundsPerSquareInchFun.TcPOU | 27 + .../Vacuum/Vacuum/POUs/Filters/DeadBandFB.TcPOU | 30 + .../2010/Vacuum/Vacuum/POUs/Filters/SmoothFB.TcPOU | 41 + Library/2010/Vacuum/Vacuum/Vacuum.plcproj | 430 ++ .../3.3.0.0/tc2_standard.compiled-library | Bin 0 -> 40065 bytes .../3.3.10.0/tc2_system.compiled-library | Bin 0 -> 145473 bytes .../3.3.10.0/tc2_utilities.compiled-library | Bin 0 -> 453424 bytes .../3.3.0.0/tc3_interfaces.compiled-library | Bin 0 -> 20041 bytes .../tc3_module/3.3.6.0/tc3_module.compiled-library | Bin 0 -> 62830 bytes .../3.5.4.0/unitconversion_itfs.compiled-library | Bin 0 -> 159574 bytes .../3.5.2.0/base_itfs.compiled-library | Bin 0 -> 14669 bytes .../system/cmpapp/3.5.6.0/cmpapp.compiled-library | Bin 0 -> 43807 bytes .../3.5.5.0/cmpbitmappool.compiled-library | Bin 0 -> 10128 bytes .../3.5.3.50/cmpdynamictext.compiled-library | Bin 0 -> 20559 bytes .../3.5.5.0/cmperrors2_itfs.compiled-library | Bin 0 -> 12708 bytes .../3.5.5.0/cmpeventmgr.compiled-library | Bin 0 -> 24277 bytes .../system/cmplog/3.5.5.0/cmplog.compiled-library | Bin 0 -> 17125 bytes .../3.5.5.0/cmpschedule.compiled-library | Bin 0 -> 15643 bytes .../3.5.5.0/cmptargetvisu.compiled-library | Bin 0 -> 12556 bytes .../3.5.6.0/cmpvisuhandler.compiled-library | Bin 0 -> 30874 bytes .../component manager/3.5.5.0/cm.compiled-library | Bin 0 -> 40088 bytes .../3.5.2.0/dataserver_itfs.compiled-library | Bin 0 -> 76219 bytes .../3.5.2.0/monitoringdata_itfs.compiled-library | Bin 0 -> 39335 bytes .../3.5.6.0/stringutils.compiled-library | Bin 0 -> 126454 bytes .../sysfile/3.5.6.0/sysfile.compiled-library | Bin 0 -> 23653 bytes .../system/sysmem/3.5.5.0/sysmem.compiled-library | Bin 0 -> 18005 bytes .../sysprocess/3.5.5.0/sysprocess.compiled-library | Bin 0 -> 17317 bytes .../system/sysshm/3.5.5.0/sysshm.compiled-library | Bin 0 -> 14973 bytes .../systarget/3.5.5.0/systarget.compiled-library | Bin 0 -> 21297 bytes .../systime/3.5.5.0/systime.compiled-library | Bin 0 -> 8455 bytes .../3.5.5.0/systimecore.compiled-library | Bin 0 -> 11600 bytes .../systimertc/3.5.5.0/systimertc.compiled-library | Bin 0 -> 24315 bytes .../3.5.2.0/systypes_itfs.compiled-library | Bin 0 -> 11482 bytes .../3.5.4.0/systypes_itfs.compiled-library | Bin 0 -> 12416 bytes .../3.5.5.0/visu_itfs.compiled-library | Bin 0 -> 27620 bytes .../3.5.6.0/visuelembase.compiled-library | Bin 0 -> 1743684 bytes .../3.5.6.0/visuelemmeter.compiled-library | Bin 0 -> 2483904 bytes .../visuelems/3.5.6.10/visuelems.compiled-library | Bin 0 -> 424922 bytes .../visuelemsspecialcontrols.compiled-library | Bin 0 -> 2146422 bytes .../3.5.6.0/visuelemswincontrols.compiled-library | Bin 0 -> 845827 bytes .../3.5.6.0/visuelemtexteditor.compiled-library | Bin 0 -> 390796 bytes .../visuinputs/3.5.6.0/visuinputs.compiled-library | Bin 0 -> 85394 bytes .../3.5.6.0/visunativecontrol.compiled-library | Bin 0 -> 83866 bytes Library/Vacuum/Vacuum/Vacuum.xml | 7520 ++++++++++++++++++++ Source/Scripts/h0vaclx.ps1 | 22 +- Source/Scripts/h0vaclx_create_target.ps1 | 15 +- Source/Scripts/h0vacly.ps1 | 20 +- Source/Scripts/h0vacly_create_target.ps1 | 6 +- Source/Scripts/macro_functions.ps1 | 226 + Source/h0vaclx_create_target.cs | 4 +- Target/H0VACEX/scp.bat | 2 +- Target/H0VACEY/scp.bat | 2 +- Target/H0VACLX/h0vaclx.cmd | 8 +- Target/H0VACLX/h0vaclx_start_ioc.bat | 2 +- Target/H0VACLX/scp.bat | 2 +- Target/H0VACLY/scp.bat | 2 +- Target/H0VACMR/scp.bat | 2 +- Target/H0VACMX/scp.bat | 2 +- Target/H0VACMY/scp.bat | 2 +- 113 files changed, 9928 insertions(+), 38 deletions(-) create mode 100644 Library/2010/Vacuum/Vacuum.project.~u create mode 100644 Library/2010/Vacuum/Vacuum.sln create mode 100644 Library/2010/Vacuum/Vacuum.suo create mode 100644 Library/2010/Vacuum/Vacuum.tsproj create mode 100644 Library/2010/Vacuum/Vacuum.tsproj.bak create mode 100644 Library/2010/Vacuum/Vacuum/DUTs/SmoothStateEnum.TcDUT create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Controls/ColdCathodeGaugePowerControlFB.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Controls/PIControllerFB.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Controls/RegenHeaterTemperatureControlFB.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/AnnulusIonPump/AnnulusIonPumpMilliAmpsToLogMilliAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/AnnulusIonPump/AnnulusIonPumpMilliAmpsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/AnnulusIonPump/AnnulusIonPumpVoltsToMilliAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/CC10/CC10VoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/ColdCathodeGauge/ColdCathodeGaugeTorrToLogTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/ColdCathodeGauge/ColdCathodeGaugeVoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/Cryopump/CryopumpMilliAmpsToPercentFullFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/CryopumpLiquidLevelControlValve/CryopumpLiquidLevelControlValvePercentOpenToMilliAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/Dewar/DewarMilliAmpsToPercentFullFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/Dewar/DewarPercentFullToGallonsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/DischargeLine/DischargeLineMilliAmpsToPoundsPerSquareInchGaugeFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/DischargeLine/DischargeLineMilliAmpsToStandardLitrePerMinuteFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/FanVibration/FanVibrationMilliAmpsToInchesPerSecondFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/GateValve/GateValveLimitSwitchesToPositionNumberFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/GateValve/GateValvePositionNumberToAnimationNumberFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/GateValve/GateValvePositionNumberToPositionStringFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/GaugeControllerMKS937/GaugeControllerMKS937VoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IO/EL3004CountsToVoltsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IO/EL3024CountsToMilliAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IO/EL3314CountsToDegreesCelsiusFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IO/EL4024MilliAmpsToCountsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/Inficon/InficonBPG402TorrToLogTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/Inficon/InficonBPG402VoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/InstrumentAir/InstrumentAirVoltsToPoundsPerSquareInchGaugeFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerDualVac/IonPumpControllerDualVacTorrToStatusFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerDualVac/IonPumpControllerDualVacVoltsToKiloVoltsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerDualVac/IonPumpControllerDualVacVoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerGamma/IonPumpControllerGammaAmpsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerGamma/IonPumpControllerGammaTorrToStatusFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerGamma/IonPumpControllerGammaVoltsToAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerGamma/IonPumpControllerGammaVoltsToKiloVoltsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerIPCMini/IonPumpControllerIPCMiniAmpsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerIPCMini/IonPumpControllerIPCMiniTorrToStatusFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerIPCMini/IonPumpControllerIPCMiniVoltsToAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerIPCMini/IonPumpControllerIPCMiniVoltsToKiloVoltsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMiniVac/IonPumpControllerMiniVacAmpsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMiniVac/IonPumpControllerMiniVacTorrToStatusFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMiniVac/IonPumpControllerMiniVacVoltsToAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMiniVac/IonPumpControllerMiniVacVoltsToKiloVoltsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMultiVac/IonPumpControllerMultiVacTorrToStatusFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMultiVac/IonPumpControllerMultiVacVoltsToKiloVoltsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/IonPumpControllerMultiVac/IonPumpControllerMultiVacVoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/LinearConversionFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/PiraniGauge/PiraniGaugeVoltsToTorrFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/RegenHeater/RegenHeaterDegreesCelsiusToMilliAmpsFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Conversions/WaterPressure/WaterPressureVoltsToPoundsPerSquareInchFun.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Filters/DeadBandFB.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/POUs/Filters/SmoothFB.TcPOU create mode 100644 Library/2010/Vacuum/Vacuum/Vacuum.plcproj create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/beckhoff automation gmbh/tc2_standard/3.3.0.0/tc2_standard.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/beckhoff automation gmbh/tc2_system/3.3.10.0/tc2_system.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/beckhoff automation gmbh/tc2_utilities/3.3.10.0/tc2_utilities.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/beckhoff automation gmbh/tc3_interfaces/3.3.0.0/tc3_interfaces.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/beckhoff automation gmbh/tc3_module/3.3.6.0/tc3_module.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/intern/unit conversion interfaces/3.5.4.0/unitconversion_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/base interfaces/3.5.2.0/base_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmpapp/3.5.6.0/cmpapp.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmpbitmappool/3.5.5.0/cmpbitmappool.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmpdynamictext/3.5.3.50/cmpdynamictext.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmperrors2 interfaces/3.5.5.0/cmperrors2_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmpeventmgr/3.5.5.0/cmpeventmgr.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmplog/3.5.5.0/cmplog.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmpschedule/3.5.5.0/cmpschedule.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmptargetvisu/3.5.5.0/cmptargetvisu.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/cmpvisuhandler/3.5.6.0/cmpvisuhandler.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/component manager/3.5.5.0/cm.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/data server interfaces/3.5.2.0/dataserver_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/monitoring data interfaces/3.5.2.0/monitoringdata_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/stringutils/3.5.6.0/stringutils.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/sysfile/3.5.6.0/sysfile.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/sysmem/3.5.5.0/sysmem.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/sysprocess/3.5.5.0/sysprocess.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/sysshm/3.5.5.0/sysshm.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/systarget/3.5.5.0/systarget.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/systime/3.5.5.0/systime.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/systimecore/3.5.5.0/systimecore.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/systimertc/3.5.5.0/systimertc.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/systypes interfaces/3.5.2.0/systypes_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/systypes2 interfaces/3.5.4.0/systypes_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visu interfaces/3.5.5.0/visu_itfs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuelembase/3.5.6.0/visuelembase.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuelemmeter/3.5.6.0/visuelemmeter.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuelems/3.5.6.10/visuelems.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuelemsspecialcontrols/3.5.6.0/visuelemsspecialcontrols.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuelemswincontrols/3.5.6.0/visuelemswincontrols.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuelemtexteditor/3.5.6.0/visuelemtexteditor.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visuinputs/3.5.6.0/visuinputs.compiled-library create mode 100644 Library/2010/Vacuum/Vacuum/_Libraries/system/visunativecontrol/3.5.6.0/visunativecontrol.compiled-library create mode 100644 Library/Vacuum/Vacuum/Vacuum.xml Administrator@h0vacmr MINGW32 ~/Desktop/lho-vacuum (main)
Closes WP 12577. The running code is now at commit 0faf5c4aeb5c61116a5abf0573cb3d09ffdc9e7c in https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum. This completes the remaining part of the work permit: "Update the PLC code on h0vacly to pull and use the following changes from git: "Changed the names of the IP23, IP24, and IP25 filter cavity ion pump controllers. Added IPFCC6 and IPFCC8 filter cavity ion pump controllers. Commented out IPFCC6 and IPFCC8. Commented out PT100 as a Pirani and Cold Cathode gauge pair." After regenerating the TwinCAT 3 solution and running a scan for devices it showed that Box 1, Box 4, PT154 and PT157 had different hardware revisions than they were configured for in the solution. I changed the PowerShell script to make them match, but when I ran it I found that the device driver installed for these gauges did not match the new revision number. I looked on the MKS website for updated drivers, but could not find any drivers at all. I looked back through my emails and found that Chandra had given me the one I currently have, and remembered that she had probably gotten it from the manufacturer directly. The most feasible solution I could think of to do in the time remaining was to revert the revision numbers in the software and run with the mismatch. I don't see any issues at present, and apparently PT154 has been running with the mismatch since it was replaced a while back.
The FC TRANS GR (CAM33) camera looks to have crashed or at least the channels for its controls were no longer accessable. The image was still viewable, at least from the screenshots fom. i restarted the process via the browser interface linked from the camera overview and that did the trick. Back to Observing at 0730UTC.
Trend of H1:IOP-SUS_ITMY_WD_OSEM1_RMSOUT shows increased motion during the 10 minutes post-RCG upgrade that OMC0, see alog 85120, was clobbering IPCs, including two peaks.
The attached screenshot has cursors at the approximate start and end of OMC0 clobbering IPCs. RMS remained high until guardian was started 30 minutes later, after which ITMY continued to ring until guardian was again restarted.
We will attempt to trace the clobbered IPCs to see if they plausibly could have driven ITMY.
The attach list shows the mapping from OMC0 IPCs to IPCs that were clobbered during the ten minutes OMC0 was running on the wrong IPC table.
ITMX, which received the same clobbered channel as ITMY, also showed a spike in movement during the same period, but was properly stilled by guardian.
WPs: 12577 and 12608 Previous work: alog 84871 This portion of the first work permit has been completed: "Migrate h0vaclx from the svn repo to the git repo. Also migrate it from using the C# code to the PowerShell code for generating the TwinCAT 3 Visual Studio solution. This would make it match h0vacmr and h0vacly in both of these regards. Update the PLC code on h0vaclx to add PT100 as an Inficon BCG552 gauge." The installation of TwinCAT 3 on h0vaclx has been updated to version 3.1.4024.35. The PowerShell script to generate the TwinCAT 3 solution has been changed to use the TwinCAT XAE Shell instead of Visual Studio 2010 because I could not get it working with the latter. The new Inficon BCG552 EtherCAT gauge on HAM1 is connected and being read into EPICS. The code being used for the scripts is at commit d27c3ebfb424572f3aba003744e97e947e5a4873 in the git repo at https://git.ligo.org/cds/ifo/beckhoff/lho-vacuum. The shortcut in the TwinCAT autostart folder to start the EPICS IOC has been updated to point to the location of the checkout of this repo. The shortcut on the Desktop has similarly been updated. Timeline of work: 9:56 Stopped the EPICS IOC. Set the TwinCAT runtime to Config. Started the installer for TwinCAT 3.1.4024.67. 10:02 A Windows Security dialog message appeared three times: "Windows can't verify the publisher of this driver software". Clicked "Install this driver software anyway" each time. The installer took a very long time on "Installing Microsoft .NET Framework 5.6.1 Full". 10:22 The computer spontaneously logged me out during the installation. 10:24 Logged back in. 10:26 I started the installation of TwinCAT 3.1.4024.67 again and then soon canceled it. 10:35 I started the installer for TwinCAT 3.1.4024.35. 10:50 I restarted the computer to complete the install as prompted. 10:52 Logged back in. The installation appeared to be successful. I tried to generate the TwinCAT 3 solution from the scripts. I could not find a way around an error saying that the project template could not be found, despite it being at the path shown. 11:19 I ran 'shutdown /r' to restart the computer and try again but still got the same error about the template after the restart. I changed the script to use the TwinCAT XAE Shell instead of Visual Studio 2010. The script froze. I logged out and back in. The script succeeded in generating the solution. I scanned for terminals and did not see the BCG552 gauge on HAM1. Gerardo told me it was not connected and went to connect it. The gauge showed up and everything appears to be working. I updated the paths in the scripts for the IOC and the shortcuts to start the IOC. I checked in all of the changes to git.
SDF Overview looks great except this HPIHAM1 channel not found.
I went down to end Y to retrieve the usb stick that I remotely copied the c:\slowcontrols directory on h1brsey to, and also to try to connect h1brsey to the kvm switch in the rack. I eventually realized that what I thought was a vga port on the back of h1brsey was probably not, and instead I found this odd seeming wiring connected from what I am guessing is a hdmi or dvi port on the back of h1brsey, to some kind of converter device, then to a usb port on a network switch. I'm not sure what this is about, so I am attaching pictures.
I copied the contents of C:\SlowControls on h1brsex and h1brsey onto a usb stick. I committed changes local to h1brsex into svn. I ran svn update on h1brsey. I was just expecting the changes I committed from h1brsex to show up, but a whole lot more did. I guess no one had run svn update in a long time. It appeared to complete without conflicts and reported that it was now at revision 6189. I started committing files to svn on h1brsey that I thought did not conflict between the two machines, but I think I accidentally committed one that does. I committed local changes on h1brsey to /trunk/BRS2 C#/BRSReadout/configs/LHOEY.config, but afterward found that there are also local changes to the same file on h1brsex.
HWS servers now point to /ligo/data/hws as the data directory.
The old data directory, h1hwsmsr:/data, is now moved to h1hwsmsr:/data_old
The contents of the old directory were copied into the new directory, except H1/ITMX, H1/ITMY, H1/ETMX, H1/ETMY, under the assumption that these only contain outputs from the running processes.
HWS processes on h1hwsmsr, h1hwsmsr1, h1hwsex were stopped and restarted and are writing to the new directory.
h1hwsey had crashed previously and wasn't running. It was restarted and is also writing to the new directory
FAMIS28948
The quarterly reminder came at a good time for us to restart fresh for observation next week. Reboot went as expected, no hiccups. Reboot started at 1553UTC.
Daniel, Kevin, (Erik, Dave), Vicky
Kevin is interested in taking ADF sweeps around the second higher order mode arm resonance near 10.4 kHz.
We (Daniel) made model changes in h1ioplsc0 and h1omcpi that should enable higher freq ADF demods. Daniel built the models successfully. Then Dave also built these models successfully for the custom RCG running on h1omcpi for the variable duotone. We put in a WP to boot in these changes to h1ioplsc0 and h1omcpi next Tuesday 6/10.
From h1ioplsc0, we added 2 new PCIe channels to write the digital ADF LO oscillator out to PCIe. These are H1:IOP-PCI_ADF_VCXO_{COS,SIN} in screenshot 1. We also changed a rogue limiter such that the ADF should be able to scan +/-1 MHz according to the PLL.
In h1omcpi, we use the fast 64 kHz OMC PI user model to do a fast digital demodulation of the OMC_DCPD_SUM signal using the above ADF-LO PCIe channels. This is beating the fast dcpd output signal (H1:OMC-PI_DCPD_64KHZ_AHF), against the ADF LO's cosine and sine components from PCIe (H1:IOP-PCI_ADF_VCXO_{COS,SIN}), to get the demodulated ADF I/Q signals. The demod signals will have names like H1:OMC-PI_ADF_DEMOD_{I,Q}. Screenshots 2-4.
Operationally nothing should change for the ADF or for OMC-based fast PI damping. We are just using PCI to send 2 IPC channels from an IOP model to a user model on a different computer at ~65kHz, and doing the demod in a 64kHz user model (but the demod does not go anywhere, it is just used for squeezer diagnostics).
Model change summary:
h1ioplsc0
+2 IPC senders to H1.ipc
+2 slow channels to DAQ
h1omcpi
(+2 IPC receivers)
+33 slow channels to DAQ
Model changes today seem relatively successful. No way to verify in hardware (yet), but the ADF PLL claims it successfully locks at -11kHz from carrier, so at least the limiter fix in h1ioplsc0 seems to work; in principle the ADF sweep limiter is now set at +/- 1 MHz.
I added a quick ADF demod of the 64kHz OMC DCPD SUM channel into the normal ADF screen, screenshot attached, see the very bottom. New filter banks initialized with values and filters as in the other adf demod chains. Also tried to clean it up in SDF: channels are initialized, gains and phase are monitored, and saved into sdf (h1omcpi model).
Betsy, Ryan S, TJ
We did our first walk through after the vent, but next week there will definitely be more to sweep that we either missed or that we said we will hold off a week on. We focused on the most egregious items.
Two index number changes this morning:
J. Kissel Now that PM1, RM1, and RM2 are safely functional on the new ISI HAM1, in the h1iopsush2b front-end model, I've - set H1:IOP-SUS_${OPTIC}_DK_BYPASS_TIME to 600 seconds H1:IOP-SEI_HAM1_DK_BYPASS_TIME - set H1:IOP-SEI_HAM1_DK_BYPASS_TIME to 999999999 (~1e9) seconds, as is seemingly common in most SWWDs - hit RESET on each of the SUS DACKILLs and the SEI DACKILL to arm them - initialized the PM1 channels in the safe.snap and accepted and monitored their current values
J. Kissel, F. Clara, E. von Ries, D. Barker, E. Dohman, O. Patane, R. Short After fixing MEDM screens, I was able to validate that all expected drive signal channel assignments reach the expected DAC outputs for H1SUSITMY, H1SUSITMX, and H1SUSBS. As such, I restored the function of top mass damping loops, L2 to R0 tracking for the ITMs, and optical lever damping for the BS. We've confirmed that alignment offsets have been restored. With the SUS happily damping, I then restored the seismic isolation system, using the SEI guardians to bring HEPIs and ISIs back to FULLY_ISOLATED for the ITMs and FULLY_ISOLATED_NO_ST2_BOO for the BS. Executive Summary of the last 24 hours of events regarding h1susb123 DAC card failure: - LHO:84500 h1susb123's Slot 4, DAC 2 -- an 18-bit DAC -- died and caused the front-end to crash, which eventually tripped all BSC1, BSC2, and BSC3 seismic systems via Software Watchdog (SWWD) - LHO:84506 Having agreed that we should take the opportunity to enact ECR E1900216 (IIET:13232) and upgrade all the DAC cards in the chassis to 20-bit DACs -- we prepped the h1susb123 user and IOP models for the change - LHO:84508 Erik and Fil replace all 18-bit DAC cards with 20-bit DAC cards, Dave compiles, installs, and restarts the h1susb123 front-end's models with the new code. - LHO:84509 With the models running, Ryan and I installed updates to the COILOUTF filters to account for the calibration change between 18 and 20 bit DACs. - LHO:84514 I cleaned up the MEDM interface for the SUS-ITMs and SUS-BS to ensure they accurately show signal flow from user model output to the DAC. - (this aLOG) Having validated signal flow, we restored the SEI and SUS systems to full nominal functionality.
Fil, Rahul
This morning we finished ground loop checks on HAM1 chamber, since Jim was done with final cabling work. The only grounding issues we found were in RM1 and PM1, hence we removed pin1 from the in-air cable (connecting Satamps).
D0902810 aLIGO SUS HAM 1-2 System Wiring
T1200131 Grounding and Shielding at LIGO
D1900511 ISC/SQZ Wiring Diagram
The following were checked for ground loops:
To get a good chamber ground connection, testing was done at the feedthroughs. Normally done at the ISC racks. Shorts found on RM1, PM1, and both beam diverters.
With suspensions in safe mode, the termination shielding was repaired on the following PM1 cables:
F. Clara, R. Kumar
The DM first starting having issues at ~11am 2 weeks ago on April 22nd (Tues) for seemingly no reason, there wasn't any work or alogs that day that would made us suspicious of causing this.
Following my alog comments on alog84282, Dave showed me where the physical comtrol box is in the CER, restarting it brought the connection back but I then found that the dust monitor had no flow :(. This DM hasn't been used since we got it calibrated in April of 2024, so I swapped it for the last pumpless spare we had which has good flow but now it's not connecting again. I've tried powercycling the DM itself, the ioc, and the comtrol box then the ioc which is what got the other DM to reconnect, and it still getting "No reply from device within 1000 ms" for all its PVs. The DM it self is working and reading counts properly.
Doing a telnet network status (comand "ss -e") on h0epics for the diode room port yielded:
timer:(keepalive,38min,0) uid:1001 ino:20939307 sk:ffff8800b67bd500
ESTAB 0 0 10.105.0.80:37347 10.105.0.100:8000
I opened up the DM that had no flow to find that the internal tubing was not even connected, I swapped this one back this morning and it came right back no problem and we can see it on epics. The one that I took off has some kind of network issue.
TITLE: 05/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: MAINTENANCE
Wind: 9mph Gusts, 5mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: Vent work continues today with more HAM1 alignment and wind fence work.
The DR dust monitor counts did not look correct, its was only reading zero for over 2 weeks, I went out and power cycled it and made some counts which I was not able to see on epics. I then tried to restart the IOC, and it struggled to come back. After a little over 5 minutes it did come back and started showing counts again.
The DR is having network issues again, ~an hour after the restart. I'll try swapping this one with one of our 2 pumpless spares.
2025/05/06 11:09:20.443023 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: No reply from device within 1000 ms
2025/05/06 11:09:21.444241 gt521s1 H1:PEM-CS_DUST_DR1_STATE: No reply from device within 1000 ms
2025/05/06 11:09:21.787891 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "SH 600*00337" mismatch after 0 bytes
2025/05/06 11:09:21.787919 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "SH 600*00337" where "OP " was expected
2025/05/06 11:09:22.344822 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: Input "OP H 58*00404" mismatch after 0 bytes
2025/05/06 11:09:22.344838 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: got "OP H 58*00404" where "SH " was expected
2025/05/06 11:09:22.394988 gt521s1 H1:PEM-CS_DUST_DR1_STATE: Input "H 57*00403" mismatch after 0 bytes
2025/05/06 11:09:22.395020 gt521s1 H1:PEM-CS_DUST_DR1_STATE: got "H 57*00403" where "OP " was expected
2025/05/06 11:09:22.445131 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "P H 57*00403<8d>OP H 57" mismatch after 0 bytes
2025/05/06 11:09:22.445164 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "P H 57*00403<8d>OP H 57" where "OP " was expected
Swapped the dust monitor and now it won't come back and the IOC can't connect to/see the DM.
2025/05/06 11:42:20.506771 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIME: No reply from device within 1000 ms
2025/05/06 11:42:20.507000 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: @init handler failed
2025/05/06 11:42:20.507100 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: Record initialization failed
Bad init_rec return value PV: H1:PEM-CS_DUST_DR1_HOLDTIME ao: init_record
2025/05/06 11:42:21.508499 gt521s1 H1:PEM-CS_DUST_DR1_SAMPLETIME: No reply from device within 1000 ms
2025/05/06 11:42:21.508670 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: @init handler failed
2025/05/06 11:42:21.508762 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: Record initialization failed
Bad init_rec return value PV: H1:PEM-CS_DUST_DR1_SAMPLETIME ao: init_record
Good news:
One of the RF cables for ASC-WFS_B, the one on the right viewed from the front where the diode sits, started working after I disconnected and reconnected the cable. Marc and Daniel can see the connection from outside using their tdr setup.
Bad news:
I broke one of two RF connectors per WFS for both ASC-REFL_A and ASC-REFL_B in somewhat different ways. For both of them, the broken one is the one with "TEST" input. Viewed from the front of the WFS, it's on the left.
Instead of one fully working WFS and one totally broken WFS, we now have two units of half-working WFS. We need a help from somebody who has some experience dealing with helicoils.
ASC-REFL_A
Helicoil insert of one of the RF connector screws was stuck with the screw and came out with the cable-side connector (1st picture). I'll try to remove the helicoil from the screw later, but even if I'm successful we must install a new helicoil into the WFS, and reconnect the cable.
(Added later: I quickly pinched the helicoil using a class B needle noise plier and tried to "unscrew" the screw from helicoil but wasn't successful. I felt as if a bit more of the "free" helicoil emerged from the tip of the screw, it eventually was crushed by the plier and came off (4th pic), maybe it takes more time or maybe it galled, but I stopped there as I was worried to damage the thread of the screw.)
ASC-REFL_B
One of the RF connector screws was broken, and the broken bit stayed inside the connector on the WFS (2nd attachment). The screw seems to be vented. If we have a small screw extractor bit, we might be able to remove that.
Not sure about the cable-side connector. If we can disassemble and replace the screw with a new one, that will be good.
How this happened:
Yesterday, Daniel found that none of RF of ASC-REFL_B was not working at all. alog 84224
Today I disconnected one of RF cables (on the right viewed from the front) on ASC-REFL_B and reconnected. Eventually it turns out that that fixed the issue for that cable, but at the time we somehow confused ourselves and started to think that WFSA in chamber was WFSB in RF world and vice versa.
Then I disconnected both of the cables on ASC-REFL_A and swapped the positions so that left is right and vice versa (because we thought that it was REFL_B), and Daniel found that the RF signals were swapped for REFL_A. Fine, no more confusion.
I removed the cables from ASC-REFL_A again and started putting them back in a correct order. However, as soon as I started working on the first cable, the one on with "TEST" input, I felt that one of the screws was stuck even though the connector was not yet fully seated. I backed it off and found that the helicoil was stuck with the screw.
Since there was no immediate remedy for this, I started working on ASC-REFL_B. Turned out that the cable I reseated was working fine. I looked at the connectors from the back (3rd picture) and the non-working one didn't look as if it was fully seated. One of the screws was easy to tighten, but the other was not. I tried to tighten them while maintaining balance (tighten one screw a bit, the other a bit, check that the connector gap is uniform, repeat), but the harder-to-turn one broke before the connector was fully seated.
In the third picture you can clearly see a gap between two mating surfaces for the connector on the right on the picture, and that's the one that shows/showed no sign of connection anywhere. Unfortunately I don't have a picture before I reseated the first connector (on the left on the picture), so I don't know if that one also had a gap before, but I strongly suspect that it did.
Note about the 5-way SMP connector
SMP (Sub Miniature Push-on) connector itself is a snap-on connector. You need a substantial pushing force to make it snap on at the last 0.5mm or so of insertion travel. Once it snaps on, no external force is necessary to retain the connection, but you need to first make it snap.
5-way SMP we're using is just 5 single SMP put in a bigger connector shell with two connection screws. Unlike the single SMP, it's not possible to make it snap by just using your fingers because the entire connector slides in and out with the screws.
However, if screws are completely removed, it might be possible for somebody to fully insert the connector by just using fingers at least in principle. The problem is the force needed for that. Even a single SMP needs some serious pushing, at least that's the case for SMP used in ISS array, but we have five SMPs in a single cable/connector, so the person must have VERY strong fingers.
Gerardo alerted me to the fact that PT110 is indicating an error on the H0:VAC-LX_Y0_PT110_ERROR channel. I logged in to h0vaclx and traced this to an unexpected value for the info data state readout. This should be 8 but is reading 15368. I don't know why or what 15368 means. He indicated that this appeared after they swapped in this gauge for another, so I suspect that this is the issue somehow.