The mechanical engineer in SLAC mentioned that the CCS should not need to command the rotator directly on the summit. However, it is needed in the SLAC for the test. However, there is one important use case that the cable wrap rotator of camera needs to synchronize with the rotator. This use case might need the TCS to coordinate or the CCS commands the rotator directly. If the latter is the case, need to check how to work with the pointing component.

From the comment of mechanical engineer:

We need CCS to command the camera rotator only because we need to have synchronized control of our cable wrap rotator (very different design and control than the T&S CCW).  It might be, however, that the same OCS bridge could be used for both the SLAC synchronized control and the T&S synchronized control. 

CCW: camera cable wrapper.

Reply from Tony:

HI, yes I think it is correct that the only reason we need to use CCS to control the rotator is to synchronize its movements with the camera cable wrap rotator, otherwise we could simply use the engineering UI (and we would not even need the SAL interface).

Our plan currently is that the camera cable wrap rotator will use a motor control system for which we already have a CCS driver, so for us the simplest route appears to be

• Direct CCS control of the camera cable wrap rotator
• CCS control of the rotator via a CCS->OCS/SAL bridge (which mostly already exists since we need such a bridge for the camera/comcam/auxtel).

I am not entirely sure I understand what you mean by "It might be, however, that the same OCS bridge could be used for both the SLAC synchronized control and the T&S synchronized control." If you mean that TCS could control the camera cable wrap rotator, then that is theoretically possible, but it would seem that it would require a whole new TCS system to control the camera cable wrap rotator which does not currently exist. We also do not currently run any OCS/SAL at SLAC except for inside the rotator, so doing so would require setting up and learning a new system.

Reply from Travis:

That comment was from me. I'm not knowledgeable on the software differences between CCS, TCS and OCS. But what I was suggesting is that there may be some commonality in the software we need at SLAC and that which is needed by T&S. I was just suggesting that we may save some time by not duplicating effort for the two systems (since they're very similar).
It appears that you're suggesting that (partially) by having the camera rotator controlled with a CCS->OCS bridge.

The draft of test plan is Rotator Test. Need to discuss the details with Scott.

Today's test result is here: Updated Middleware Test in SLAC at 10/15/2019.

Conversation with the CCS team in SLAC:

1. The engineers in SLAC showed me the CCS output FITS image will name like the MC_C_20191015_000189_R00_SG0.fits, MC_C_20191015_000189_R00_SG1.fits, MC_C_20191015_000189_R00_SW0.fits, MC_C_20191015_000189_R00_SW1.fits, or MC_C_20191015_000189_R00_S00.fits. SG means the guiding sensor and SW means the wavefront sensor. The SW0 and SW1 mean the intra- and extra-focal wavefront sensor. For each defocal sensor file, there are 8 amplifiers in each FITS file.

2. After each exposure, CCS will generate a new directory and put all FITS images in it. The directory will name like MC_C_20191014_000006, MC_C_20191014_000007, etc.. The upper level of directory names like 20190319, 20190320, etc. for each day.

3. There is no tracking mode for CCS.

4. CCS has two times: exposure time and dark time. The dark time begins when CCS starts the exposure and ends when CCS is done.

5. LSST camera shutter time is around 1.5 seconds. The ComCam's shutter time should be shorter than this.

6. CCS does not support the guider mode in 9 Hz yet at this moment.

7. The developer of image processing in DM team is Seth Digel. I could talk to him.

Comments from Russel for the test at 10/15:

Here is a possible way to enter the FAULT state safely: issue the trackStart command and wait. I think it should go to FAULT when it does not get a track command.

I have a question about state transitions: can the CSC go from state OFFLINE/PUBLISH_ONLY (which is how the CSC wakes up and I think where it ends up after clearError) to STANDBY from the CSC or do you have to use the engineering user interface. My understanding was that you had to use the EUI.

I don’t believe the vendor’s CSC publishes the “offline_substate” or “enabled_substate” fields from its telemetry. At least I could not find it. That is why I added the “controllerState” event to the XML and publish it from ts_rotator.

For the record: here are the differences I know about between the vendor’s CSC and ts_rotator (my salobj-based CSC):

ts_rotator publishes new “controllerState" and “connected" events. The vendors’ CSC does not and as far as I can tell the information is not available to SAL.
The vendor’s CSC publishes “rejectedCommand”. ts_rotator does not.
The vendor’s CSC publishes “inPosition” only when in position (as far as I can tell). ts_rotator publishes it whenever it transitions between true and false.
If there are multiple errors the vendor’s CSC “deviceError” “code" field only describes one of them; ts_rotator describes all, at least for now, but I think "controllerState” is a better source of the information.

Installed the docker in the management PC in SLAC and add the user of pbalucan into the docker group.

Tiago suggested to use the image of lsstts/rotator:DM-21694 and do the following:

1 - Run the container:
docker run -it --rm --net=host --name rotator lsstts/rotator:DM-21694

2 - On a different terminal: enter the container and setup the packages:
docker exec -it rotator /bin/bash

source /opt/lsst/software/stack/loadLSST.bash
setup lsst_distrib
source ~/repos/ts_sal/setup.env
setup ts_rotator -t current
cd repos/
git clone https://github.com/r-owen/rot_scripts.git
cd rot_scripts/
python commander.py 

Specific tests suggested by Russell:

• State transition commands. Monitor both the summaryState and the controllerState and make sure they transition as you expect
• Move with positionSet and move. Does the rotator move as you expect?
• Move with positionSet and move and then stop the move. Does this work?
• Track with ramp and/or sine. Does it work? Can you stop it with stop?

I tried to pull the docker image of lsstts/rotator:DM-21694. However, the docker stucks there for around 30 mins in the pulling process. After the checking, it looks like the default docker image position has no enough disk space.

I followed the Installing docker on CentOS, and noticed that the kernel version does not fulfill the pre-condition. I redirect to the position: "/mnt/d1". But there is still the problem. Tiago let me try somethings but it does not work yet. I gave my account and password to Tiago to let him take a try.

We will need to reboot the management PC in tomorrow.

I based on Rusell's proposal to do the following test plan:
New Rotator CSC Test in SLAC at 10/17/2019.

We rebooted the management PC today and figured out the reason of "PC stucks" is the file format of "/dev/sdb1". We changed it to ext4 by "tune2fs -O extents,uninit_bg,dir_index /dev/sdb1" in the yesterday. Think makes the system crashes. After the rebooting, the system will enter the emergency mode. At this moment, there is no internet connection to the outside. We need to modify the file format of "/dev/sdb1" to be ext4 from ext3 in "/etc/fstab" file by vi. After this, we soft rebooted the system and got back to the normal mode.

After this, Tiago helped to check the computer. He mentioned:

The machine cannot reach docker hub for some reason.. I’ll manually copy the container there… it will take a bit longer because I have to write the container to a file and go through all the hoops… but we’ll get there (I hope)…

At 2:19 PM, Tiago mentioned:

It failed after loading half the image… I’m looking it…

In the final (4:30 pm), it looks like the software is still not ready yet. The test plan at this time could be a good beginning of the test in Dec. in this year.

Test was done in SLAC and recorded in the report.

Te-Wei did a fabulous job testing the new Hex/Rot and attempting to test Russell's CSC.  Story complete.