40m
QIL
Cryo_Lab
CTN
SUS_Lab
TCS_Lab
OMC_Lab
CRIME_Lab
FEA
ENG_Labs
OptContFac
Mariner
WBEEShop
|
40m Log |
Not logged in |
 |
|
Wed Sep 29 17:10:09 2021, Anchal, Summary, CDS, c1teststand problems summary
|
Thu Sep 30 14:09:37 2021, Anchal, Summary, CDS, New way to ssh into c1teststand
|
Thu Mar 3 15:37:40 2022, Anchal, Summary, CDS, c1teststand restructured
|
Mon Oct 4 11:05:44 2021, Anchal, Summary, CDS, c1teststand problems summary
|
Mon Oct 4 18:00:16 2021, Koji, Summary, CDS, c1teststand problems summary
|
Tue Oct 5 17:58:52 2021, Anchal, Summary, CDS, c1teststand problems summary
|
Tue Oct 5 18:00:53 2021, Anchal, Summary, CDS, c1teststand time synchronization working now
|
Mon Oct 11 17:31:25 2021, Anchal, Summary, CDS, Fixed mounting of mx devices in fb. daqd_dc is running now.
|
Mon Oct 11 18:29:35 2021, Anchal, Summary, CDS, Moving forward?
|
Tue Oct 12 17:20:12 2021, Anchal, Summary, CDS, Connected c1sus2 to martian network
|
Tue Oct 12 23:42:56 2021, Koji, Summary, CDS, Connected c1sus2 to martian network
|
Wed Oct 13 11:25:14 2021, Anchal, Summary, CDS, Ran c1sus2 models in martian CDS. All good!
|
Tue Oct 19 18:20:33 2021, Ian MacMillan, Summary, CDS, c1sus2 DAC to ADC test 
|
Tue Oct 19 23:43:09 2021, Koji, Summary, CDS, c1sus2 DAC to ADC test   
|
Wed Oct 20 11:48:27 2021, Anchal, Summary, CDS, Power supple configured correctly.
|
Tue Oct 26 18:24:00 2021, Ian MacMillan, Summary, CDS, c1sus2 DAC to ADC test 
|
Wed Dec 22 17:40:22 2021, Anchal, Summary, CDS, c1su2 model updated with SUS damping blocks for 7 SOSs
|
Wed Dec 29 20:09:40 2021, rana, Summary, CDS, c1su2 model updated with SUS damping blocks for 7 SOSs
|
Fri Mar 4 11:04:34 2022, Anchal, Summary, CDS, c1susaux2 system setup and running
|
Mon Mar 7 19:38:47 2022, Anchal, Summary, CDS, c1susaux2 slow controls issues
|
Mon Mar 14 12:20:05 2022, Anchal, Summary, CDS, c1susaux2 slow controls acromag chassis installed 
|
Thu Mar 17 19:12:44 2022, Anchal, Summary, CDS, c1auxey1 slow controls acromag chassis installed, not powered
|
Fri Mar 18 18:39:13 2022, Yehonathan, Summary, CDS, c1auxey1 slow controls acromag chassis installed, powered
|
Fri Mar 18 19:10:51 2022, Anchal, Summary, CDS, c1auxey1 slow controls issues
|
Mon Mar 21 18:42:06 2022, Anchal, Summary, CDS, c1auxey1 slow controls issues
|
Mon Apr 4 17:03:47 2022, Anchal, Summary, CDS, c1susaux2 slow controls acromag chassis fixed and installed
|
Wed Jul 6 22:40:03 2022, Tega, Summary, CDS, Use osem variance to turn off SUS damping instead of coil outputs
|
Thu Jul 7 21:25:48 2022, Tega, Summary, CDS, Use osem variance to turn off SUS damping instead of coil outputs
|
Tue Mar 15 11:52:34 2022, Anchal, Summary, CDS, c1su2 model updated for sending Run/Acquire Binary Output to Binary Interface card
|
Tue Mar 15 14:10:41 2022, Anchal, Summary, CDS, c1su2 model remade, reinstalled, restarted after the update
|
Tue Oct 12 17:10:56 2021, Anchal, Summary, CDS, Some more information
|
|
Message ID: 16398
Entry time: Wed Oct 13 11:25:14 2021
In reply to: 16397
Reply to this: 16414
16533
|
Author: |
Anchal |
Type: |
Summary |
Category: |
CDS |
Subject: |
Ran c1sus2 models in martian CDS. All good! |
|
|
Three extra steps (when adding new models, new FE):
- Chris pointed out that the sudo command in c1sus2 is giving error
sudo: unable to resolve host c1sus2
This error comes in when the computer could not figure out it's own hostname. Since FEs are network booted off the fb1, we need to update the /etc/hosts in /diskless/root everytime we add a new FE.
controls@fb1:~ 0$ sudo chroot /diskless/root
fb1:/ 0# sudo nano /etc/hosts
fb1:/ 0# exit
I added the following line in /etc/hosts file above:
192.168.113.92 c1sus2 c1sus2.martian
This resolved the issue of sudo giving error. Now, the rtcds make and install steps had no errors mentioned in their outputs.
- Another thing that needs to be done, as Koji pointed out, is to add the host and models in /etc/rtsystab in /diskless/root of fb:
controls@fb1:~ 0$ sudo chroot /diskless/root
fb1:/ 0# sudo nano /etc/rtsystab
fb1:/ 0# exit
I added the following lines in /etc/rtsystab file above:
c1sus2 c1x07 c1su2
This told rtcds what models would be available on c1sus2. Now rtcds list is displaying the right models:
controls@c1sus2:~ 0$ rtcds list
c1x07
c1su2
- The above steps are still not sufficient for the daqd_ processes to know about the new models. This part is supossed to happen automatically, but does not happen in our CDS apparently. So everytime there is a new model, we need to edit the file /opt/rtcds/caltech/c1/target/daqd/master and add following lines to it:
# Fast Data Channel lists
# c1sus2
/opt/rtcds/caltech/c1/chans/daq/C1X07.ini
/opt/rtcds/caltech/c1/chans/daq/C1SU2.ini
# test point lists
# c1sus2
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1x07.par
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1su2.par
I needed to restart the daqd_ processes in fb1 for them to notice these changes:
controls@fb1:~ 0$ sudo systemctl restart daqd_*
This finally lit up the status channels of DC in C1X07_GDS_TP.adl and C1SU2_GDS_TP.adl . However the channels C1:DAQ-DC0_C1X07_STATUS and C1:DAQ-DC0_C1SU2_STATUS both have values 0x2bad. This persists on restarting the models. I then just simply restarted teh mx_stream on c1sus2 and boom, it worked! (see attached all green screen, never seen before!)
So now Ian can work on testing the I/O chassis and we would be good to move c1sus2 FE and I/O chassis to 1Y3 after that. I've also done following extra changes:
- Updated CDS_FE_STATUS medm screen to show the new c1sus2 host.
- Updated global diag rest script to act on c1xo7 and c1su2 as well.
- Updated mxstream restart script to act on c1sus2 as well.
|
|
|