I think op540m has finally bitten the dust.  I noticed that both of its screens were black, so I assumed that it had crashed due to known graphics card issues or something.  But upon closer inspection, it is way more dead than that.  I checked that it does have power (at least the power cable is securely plugged in at both ends, and the power strip its on is successfully powering several other computers), but I can't make any lights or anything come on by pressing the power button on the front of the computer tower.

Immediate consequences of op540 not being operational are the lack of DMT, and the lack of Alarms. 

Joe is doing an autopsy right now to see if its really dead, or only 'mostly dead'.

EDIT: Joe says maybe it's the power supply for the computer.  But he can't turn it on either.

 was down.  I restarted the version in the 2.7.5 folder.  It went down again almost immediately but stayed up after the second restart.

[Joe, Kiwamu] 

Woooo Yeaaaah ! 

With the new CDS we succeeded in damping of PRM and BS !!

We are in the process of doing a damping test with the real time code and have turned off the vertex optics watchdogs temporarily, including BS, ITMs, SRM, PRM, MCs.

The tile work was done yesterday after noon.

This morning Mike Gerfen and me lowered the enclosure frame to normal height.

Keven- janitor and I removed plastic covers from chambers, racks, SP, MC2 and clean tool boxes.

The afternoon Jenne, Kiwamu, Joe and Aiden cleaned the enclosure inside out. The particle count measured zero inside the enclosure with HEPAs on when the covers were

removed. The MOPA and all other components were happy to see us in excellent condition.

This table height is very user friendly!

Safety grounds were reconnected.

Atm1, new tiles around the concrete slab

Atm2, frame lowered with low cross bars reinstalled

Atm3, the enclosure frame's north west foot is connected to ground

Atm4, PSL optical table is connected to ground at the north east corner through 1 Mohm

Atm5, PSL optical table level at a stimulating, back-friendly height

Turns out the elog version 2.8.0 uses a different encryption method than 2.7.5.  This mean the encrypted passwords stored in the elogd.cfg don't work with the new code.  elogd includes functionality to generate encrypted passwords, but unfortunately I don't know the administration passwords for some of the logbooks.  So I'm going to leave 2.7.5 running until I can get those added properly to the 2.8.0 cfg file.

Thoughts on where to take the pickoff for the SHG for the PSL-green?  We discussed today at the meeting the possibility of putting a 90/10 beam splitter right after the PMC, so that the green team would get somewhere between 100-200mW. 

In a manner similar to the now classic 'Mode Matching from PMC to IMC' entry, I have calculated the lenses and positions needed to match the 2W NPRO beam into the PMC.

The added complication is that we also want to have a reasonable beam size to get into the Faraday and the AOM. It seems that this should be possible using one lens.

After the beam comes out of the AOM, there's another lens to match to the PMC. Its possible to do this with more lenses, but this is just an effort to minimize the number

of surfaces in the beam.

So apparently the themes/configurations didn't work so nicely on some of the logbooks with 2.8.0, so I'm reverting to 2.7.5 until I can figure out (assuming I can) how to get them to display properly.

So unfortunately, I made the start-elog-nodus script smart enough to kill the debugging run I had (although thats probably good since there might have been issues with continuing to run - just poor timing on part of the crash).

In related news, I have gotten the latest version of the elog code to actually compile on Nodus.  I had to hack the cryptic.c file (elog/src/cryptic.c) to get it to work though.

The following was copied from the #ifdef _MSC_VER section of the code into the #else directly following that section. 

#define MAX(x,y) ((x)>(y)?(x):(y))
#define MIN(x,y) ((x)<(y)?(x):(y))
#define __alignof__(x) sizeof(x)
#define alloca(x) malloc(x)
#define mempcpy(d, s, n) ((char *)memcpy(d,s,n)+n)
#define ERANGE 34

I also removed #include <stdint.h> as the functionality it provides is covered by inttypes.h on Solaris machines, which is automatically included.

This new code was released August 5th 2010, while the old elog code we were running was 2.7.5 and was released sometime in 2008.  There are several crash fixes mentioned in the version notes so I'm hoping this may improve stability. I'm in the process of making a copy of the elog logbooks into the elog-2.8.0 install (so as to have a backup with the original 2.7.5).  I'm also copying over all the configuration files.   In a few minutes I'm going to try switching over to the new elog.  If it doesn't work, or is worse, its easy enough to just start up the current version.

All files are located in /cvs/cds/caltech/elog/elog-2.8.0 (the old directory is elog-2.7.5).  I've made  a new startup script called start-elog-nodus-2.8.0.  To start the new one, just run that script.  To start the old one, just go to the elog-2.7.5 directory and run the old start-elog-nodus script.

took two again

 Restarted the elog using the script. I had to do it twice for it to work. This is not the first time this has happened---does anyone know why this might be?

I'm going to take the elog down for one minute and restart it under gdb (using a copy of gdb stolen from fb40m since I couldn't figure out how to install an old enough version on nodus from source).  The terminal with information is running on Rosalba under the "Phase Noise" panel, so please don't close it.  Ideally, the next time the elog crashes, I'll have some output indicating why or at least the line in the code.  I can then look at the raw source code or send the line back to the developer and see if he has any ideas.

I used the free software called 'ABCD' for Mac to construct this mode matching solution for going from the PMC to the IMC.

After getting it close by eye, I plugged the initial guess into Matlab and let it optimize the distances. I then plugged this into 'ABCD'

to get the exact solution. ABCD doesn't actually optimize anything; it just makes a nice table and graphically plots the solution.

• The first waist between the first lens (f = +200 mm) and the second lens (f = -150 mm) is where the triple mod EOM goes. I have not accounted for the index (1.75) of the KTP.
• The third lens we need is a f = +400 mm lens. I have put the lenses in the new layout drawing at the positions indicated in the Omnigraffle drawing. Each grid square corresponds to 1 inch.

The part numbers for these lenses are:

PLCX-25.4-103.0-UV-1064

PLCC-25.4-77.3-UV-1064

PLCX-25.4-206.0-UV-1064

Bertine Robby, Bertin and Jerry completed the installation by pouring concrete yesterday and cleaning up today.

Atm1-2, steel bars, grouted feet and side forms are ready

Atm3,    bounding agent is applied for better bounding

Atm4,    pumping concrete

Atm5,    shaker is used to fill-all

Atm6,    late after noon the forms- sides were removed,     NOTE: actual table to concrete distance is 12.75"

Atm7,    construction people left and the tile man is on the way

The tile patching should complete today so tomorrow we can remove plastic covers.

...was down.  Have restarted it.

Woops, I am sorry about that. I've just cleaned them up.

Bad CDS team. Bad.

 {Joe, Kiwamu}

Today we did the following works in order to get ready for the new CDS test.

 - solved the DAC issue.

 - checked all the channel assignments of the ADC and the DAC.

 - preparation for modification of the AA filter chassis. 

 - checked DAC cable length.

 - connected the power cables of the BO boards to Sorensens.

Although we performed those works, we still couldn't do the actual damping tests.

To do the damping tests, we have to modify the AA chassis to let the SCSIs go in it. Now Joe and Steve are working for this issue.

 Also we found that we should make three more 37pin Dsub - 40pin IDC cables.  

But this is not a critical issue because the cables and the connectors are already in our hands. So we can make them any time later.

(Notes)

 (DAC issue)

  Now all the DAC channels are working correctly.  

There had been a combination of some issues.

  When I posted the elog entry last time, the DAC was not working at all (see here).

 But in the last week Joe found that the IO process didn't correctly run. He modified the IOP file named 'c1x02.mdl' and ran it after compiling and installing it.

 This made the situation better because we then were able to see the most of the signals coming out from the DACs.

     However we never saw any signals associated with SIDE_COILs.

 We checked the DAC cards, their slots and their timing signals. But they all were fine.

At that time we were bit confused and spent a couple of days because the DAC signals appeared at a different slot some time after we rebooted the computer. Actually this issue still remains unsolved...

Finally we found that SIDE_COILs had an input matrix which didn't show up in the medm screen.

We put 1 in the matrix and we successfully got the signal coming out from the DAC.

(channel assignments)

We checked all the channel assignments of the DACs and the ADCs.

All the channels are assigned correctly (i.e. pin number and channel name).

(AA chassis)

 We have been planning to put the SCSI cables into the AA chassis to get the ADC signals.

As Joe said in the past entry (see here) , we need a modification on the AA chassis to let the SCSIs go in it.

Joe and Steve will put an extension component so that we can make the chassis wider and eventually SCSI can go in.

(DAC cable length)

 In the default plan we are going to reuse some DAC cables which are connected to the existing systems.

To reuse them we had to make sure that the length of those cables are long enough for the new CDS.

After stopping the watchdogs, we disconnected those DAC cables and confirmed they were long enough.

Now those cables are connected to the original place where they have been before.

The same test will be performed for the binary outputs.

(power cables to Sorensens)

 Since the binary output boards need +/- 15V power, we hooked up the power cables to Sorensens sitting on the new 1X5 rack.

After cabling them, we turned on the power and successfully saw the green LEDs shining on the back panel of the boards.

Now watchdogs are back.

The suspensions are well damped.

For the new CDS test, I turned off the watchdogs for PRM, SRM, BS, ITMs and MCs.

I will restore these watchdogs after several hours from now.

 Elog was down, I restarted it.

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL/LayoutUpgrade

P-pol = purple

S-pol = red

The .graffle file for this is in the 40m SVN's omnigraffle dir/

I finished assembling the frequency generation unit for the upgrade. I tested it through to check that the power levels are as expected at the various connection (see attached png, showing in black the design power values, and in red the measured ones).

Because of some modifications made on the design along the construction, I have to recalculate the SNR along the lines.

I can now start to measure phase noise and distortion harmonics.

A document with a description of the design and the results of the characterization measurements will be available in the end.

C1: PEM-count channels are dead since August 12, 2010

The preparation for pouring concrete is continuing. The grout forms were removed. Half inch ribbed steel bars were epoxied into our 4" thick floor.

The concrete holding sides- forms are cut to size. They will be installed on Monday morning and pouring concrete should follow.

We can be planning for cleaning up on Tuesday

Atm1, epoxy used bars

Atm2, south west tripod feet grouted

Atm3, ribbed bars are getting ready

[Yoichi, Jenne]

Hooray!!! The Tip Tilts are completely done!  The only things remaining are (1) Install 4 TTs in chambers sometime in September and (2) do shake tests / take TFs of the spare.

Today we balanced and characterized #'s 1 and 5.  All 5 TTs are waiting happily on the flow bench in the cleanroom for installation.

I had to restart the elog again.

At this point, I'm going to try to get one of the GC guys to install gdb on nodus, and run the elog in the debugger, that way when it crashes the next time, I have some error output I can send back to the developer and ask why its crashing there.

 script

The 10' x 6' optical table is seating on 6 tripods. Each tripod leg has 3 feet. They are supported by jack screws against copper plates on the concrete floor.                            These set screws allowed us to set the height,  level and distribute the load of the table.

To lock this position of the table grouting is used around the jack screws and between the concrete floor and the tripod feet.

Once the grout set the load will be carried by the hole feet  of 4" x 3.25" x3 = 39 sq inches per tripod leg

These ~4" thick grouted islands of 8-9" OD will be covered by 4" concrete. The area between the legs will be filled with 8" thick concrete.

http://www.fivestarproducts.com/techinfo/GroutHandbook.pdf

Atm1, http://www.fivestarproducts.com/cementgrouts/specsheets/grout_ss.pdf

         Cement based grout, early height change 0 - 4%, hardened height change 0 - 0.3%

Atm2-3,  pouring grout

Atm4,  south west leg is done

Tomorrow: setting up ribbed bars, building frame to hold concrete and pour concrete

 I phoned Phil Ehrens and found out that all these wikis have been moved to a new wiki site

The ATF wiki can now be found here

I have updated the link from the 40m wiki to reflect this

The ATF wiki page doesn't seem to be working any more.  Does anyone know where this is held so we can try to get it back online?  Thanks

 I restarted it using start-elog-nodus and this worked out fine - even though I did it from Pete's on my phone ;-)

I found the elog dead again this morning, and the script didn't kill again. I modified the script to use the following line instead of "pkill elogd":

kill `ps -ef | grep elogd | grep -v grep | grep -v start-elog-nodus | awk '{print $2}'`

Hopefully the script will be a bit more robust in the future.

 Just for added interest, I tried a different method when the restart script broke.  The "start-elog-nodus" script has a line "kill elogd".  This seems not to be actually killing anything anymore, which means the elog can't restart.  So this time I went for "kill <pid number>", and then ran the startup script.  This worked.  So it's the "kill elogd" which isn't working reliably.

WE programmed the MOPA chiller's AC unit to turn off at 6PM each day and automatically turn on at 7 AM each morning. Its now very quiet in the control room at night.

Next, we'll leave it off during the day and see if it makes Steve go crazy or not.

[Jenne, Yoichi]

The final 2 Tip Tilts (#1 and #5) have been suspended.  We have designated #5 the spare.  It looks like there might be a teensy bit of dust on the AR surface of the optic in #5, right near the edge of the coating.  Not a critical issue if this one is the spare, although we should see if we can blow it off with the Nitrogen.  Both #1 and #5's optics were suspended using the thicker wire, 0.0036" diameter.  This leaves 4/5 TTs with this thick wire, and 1 of the 5 has the thin wire.

To do still: Balance both #1 and #5, and then measure the modes of each.  Then we'll be ready to install them into the chambers, and we'll reserve #5 for shake table TFs for some later date.

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

 Rana, Koji, Alberto and Steve, Tuesday afternoon

Atm3, Part of the tunnel under the table was filled with quick drying concrete this morning  to give solid support for tripod legs.

          PVC tube 6 " ID with TEE will able us to connect AP table, PSL table and Control room if needed

Atm4, Table height set to equal AP at  ~32.75 " on copper plates using 5/8-11 x 4.5" set screw-bolt in tripod foot

           Rough leveling was done by 4 individual levels at the four corners with 9" long Stanley cast aluminum levels.

          Load balancing of the total weight  ~ 3000 lbs over  6 legs x3 = ~170 lbs on each jack screw with Snap-On torque wrench at 140 lbs/ft

Atm1, Three crew members at work. Prof. Rana's calibrated right hand was used at jack screws where insufficient space was available for socket head wrench.

Atm2, Table is ready for no shrink grouting now.

Apparently its possible to have working models get into a bad state in regards to shared memory, which prevents the model from working after killing it and restarting it.  We found that by shutting all the models down, and then killing and restarting the setup_shmem process, it allowed models to function properly again.

The symptom was getting stuck at the burt restore step, according the log files (/opt/rtcds/caltech/c1/target/c1SYS/logs/log.txt).

...I restarted it.

We were able to get the latest SVN checkout (revision 2009), working with the c1x00 (IOP) and c1vgl models at the new X end on the c1iscex machine.

We were unable to get it working yesterday, and as far as we can tell, the only significant change was a reboot of the c1sus machine.  Before the reboot, it did not look like there were any conflicting models running on the c1sus machine, but apparently something was preventing the models on c1iscex from running properly.

Other simulated plant models still need to have their shared memory location blocks updated to the new type.

Now that we have proved we still can get the end model running, we are moving onto the c1sus machine.

Katharine, Sharmila

Update: 
We haven't been posting in the elog regularly, for which we are very sorry.  We have been taking notes in our log books, but we ought to have posted here as well.  We apologize and now present an overview of what we've been up to.

Some time ago, we created a Simulink model to predict the response of our system, but for the model to be useful we needed to include approximately correct gains for each block in the diagram, including the magnet force and coil force gradients and OSEM "gain." We also needed to better quantify the 1x1 levitation.


Adjusting the potentiometers:

The circuit which converts current to voltage in the Quadrant maglev control has a variable resistor. This is useful as it gives us a way to zero the current when the levitated object is in the equilibrium position. It was done as follows. The output voltage from the circuit converting current to voltage is fed into the oscilloscope. The voltage values for zero and complete blockage of the LED is noted(say 2V). We adjust the resistor to make the voltage output to be V when the flag completey bolcks the LED. This gives a zero current when the flag is in the equilibrium position.

OSEM Calibration:

The OSEM works by blocking the light that goes into the photodetector from the LED by a flag. To simulate the model we had on simulink, we needed to find what the gain of the OSEM was. The gain of the OSEM is the current it gives per unit displaccement of the flag. To determine this we attached a micrometer to the OSEM flag. The micrometer was long eneough to push the flag to completey block the OSEM. We connected the output of the PD test point (which was the voltage after the photodiode current was converted into voltage) to the oscilloscope. We noted down the voltage difference in the oscilloscope with a fixed reference for different positons of the flag. From the oscilloscope output, we were able to get the PD current. We then selected a linear region of the plot of PD current vs flag position(which is usually in the middle) to fit the graph with a straight line. The slope gives the OSEM gain.

Magnet strength
    We need to know about the relative strengths of our magnets (levitated and fixed in the coil) in order to do magnet matching.  We used a Gaussmeter to measure the field from each coil magnet at  ~2 mm away from the center (the probe was fixed to an aluminum block, so that the tip had the same vertical separation for each of the four fixed plate magnets).  We labeled each of the four magnets and calculated the field at this distance to be 0.206 kG, 0.210 kG, 0.212 kG, and 0.206 kG,  respectively, for coils 1-4.  However, each measurement had a rather large uncertainty of 0.01 kG, because the field strength varied a lot with position on the magnet, and the measurements were limited by how well we could align the probe tip with the center.

Fixed Plate Magnets - magnetic field (kG)           
meas't    1        2        3        4
1       0.205    0.213    0.209    0.204
2       0.211    0.219    0.223    0.207
3       0.199    0.205    0.211    0.201
4       0.207    0.203    0.206    0.213
average 0.206    0.210    0.212    0.206
stdev   0.005    0.007    0.007    0.005

    We also planned to take the same measurements for the coil magnets.  We noted that the magnetic field varied a lot depending on the probe's location, but not in the way we would expect.  At the edges of the magnet, the field was much stronger (~2 kG) than at the center (~0.5 kG).  We initially thought this might have to do with how we were holding the probe -- for instance, if we measured the force towards the edge by moving the tip all the way across the center of the magnet, there might be some kind of integration effect which does not accurately represent the field.   However, we measured the field at the edge with the probe across the magnet and also with the probe, so this is clearly not the case.

    We also noticed that the cylindrical magnet we used for single-magnet levitation was not attracted to the coil magnets in the way we expected.    Though the cylindrical magnet was oriented so that it was strongly attracted to the coil magnet, it was attracted more to the edges than the center, so that it seemed to be repelled by the centers of the coil magnets.  Though this follows somewhat from the Gaussmeter readings, it is not the behavior we would expect when considering the coil magnets as magnetic dipoles.

Attempting single-magnet levitation for each coil:
    We attempted to levitate single magnets using all four OSEM/coil combinations.   We assembled the magnets and OSEMs using Haixing's mount, and, adjusting the height of the OSEM plate, attempted to levitate the single magnet with a flag with which we were previously successful.   This was completely unsuccessful using all of the coil magnets (and when we tried to levitate using the south magnets, we flipped the cylindrical magnet's orientation).
    Since we had already achieved this levitation, this seemed particularly wrong.  We disassembled the fixed OSEM plate in Haixing's mount and built a cursory OSEM mount, similar to the one we had used for levitation before, and did not fix it in place.  After a little experimenting with the height and position of the OSEM, we were able to achieve levitation with coils 1 and 4.
    We noted the levitation magnet separation (~4.5 mm) and the height of the OSEMs at which levitation was achieved (147 +/- 1 mm for coil 1, 146 +/- 1 mm for coil 4).  Then, we reassembled Haixing's OSEM plate and tried to levitate the cylindrical magnet at coil 1 and coil 4, respectively, adjusting the OSEM plate so that the height of the OSEM of interest was the same as when we achieved single-magnet levitation.  This was unsuccessful, which leads us to believe that there is some alignment issue between the fixed coil magnets and the OSEMs in the mount,  possibly due to the unusual field from the fixed coil magnets.
    We also were completely unable to levitate using coils 2 and 3.  Coils 1 and 4 have identical circuit paths, whereas 2 and 3 differ slightly.  With more time, we need to investigate this further.

Force-distance measurements
    We also measured the repulsive force between the cylindrical magnet and the coil magnets as a function of separation.  We fixed each of the coil magnets, individually, on a stack of sticky notes on a precision balance (the stack of sticky notes was to prevent the coil magnet from interacting with the digital balance) and zeroed the balance.  We then fixed the cylindrical magnet (oriented so that it would be repelled by the coil magnet) to a teflon rod, and mounted the rod so that we could slide it up and down a long cylindrical post.  Noting the position of the rod and cylindrical magnet, we were able to measure the repulsive force as a function of separation (see Excel graph).
    However, because the magnetic field varied so much with position on the coil magnet, there is a lot of uncertainty associated with these measurements.    We tried to keep the cylindrical magnet in the same horizontal position, but it was impossible to keep the exact position while sliding the mounted teflon rod up and down the posts.    In spite of this, we fit the linear region of this graph, near the equilibrium separation of the magnets, for a very approximate measurement of the magnetic field force gradient. The slope gives the force per unit distance of the magnet.

Coil-force measurement
    We measured the force by changing the current through the coil of wire, using a very similar setup as described above.  Since we are concerned with the magnetic force as a function of current, not separation, we fixed the teflon rod so that the cylindrical magnet and coil magnet were separated by ~4.5 mm, the approximate levitation separation of the two magnets.   We then completely blocked the OSEM with the flag, creating a maximum PD current, and measured the coil current using an oscilloscope when the LED was fully blocked and the current when we removed the flag.  At the same time, we measured the repulsive force by looking at the precision balance.
    Unfortunately, we had difficulty taking further readings, because our circuit starting behaving oddly (described below).  Otherwise, we would repeat this process by blocking the OSEM LED by various amount and measuring the change in coil current, and the corresponding reading on the precision balance.   However, the force should be linearly dependent on coil current, and we ought to know one other point: when there is no current in the coil, there should be no magnetic force from the coil to the magnet.  Using this information, we can determine the slope of magnetic force by coil current, but it's not very reliable as we have only one real data point.
    One additional aspect makes this reading questionable.  When we switched on the power supply, the reading on the precision balance changed, before we had blocked the OSEM LED at all. Since no light was blocked, theoretically no photocurrent should be coming from the PD and there should not be a coil current from the feedback, so the force should not be changing. We are not sure why this is.

Recent Circuit Behavior
    Some noise in the circuit appears to be hugely amplified when the gains of each coil are high, resulting in a high frequency signal of a few hundred kHz.  When the gains are all sufficiently high, this noise can saturate the coil current so that when PD current changes, there is no visible change in coil current.
    On Saturday, we noticed some odd behavior from the circuit.  We hooked up the oscilloscope so we could see both PD current and coil current, and were very surprised that the PD current signal was oscillating and continually changing even when no flag was inside the OSEM.   This was also affecting the coil current as well.  We thought this might be due to some component burning out in our circuit, or RC coupling somewhere, but we did not get a chance to pinpoint the origin of this problem.

Modeling
Initially we had attempted to model the force-distance treating the two cylindrical magnets as dipoles, and finding the attraction/repulsions between the four distinct poles.  However, the resulting equation did not have a maximum, which is what we got in our measured values, so it seems this is not the best approach.  We would like to try the current loop approximation.

Tuesday, 17 August : fill tunnel, set table height, level table and balance load

Wednesday : grout tripod legs and leave it alone

Thursday : built  guide-form for concrete

Friday :  pour concrete

Monday, 23 August : remove guide forms and clean up

I just restarted the elog after I found it down a few minutes ago.

 Since we had a similar trouble with the DAC at CLIO, I checked if this problem comes from the same origin.

The origin of the problem we had was that although the board was sold as 16 channel DAC, the firmware was set to use only 8ch.

To see if this problem exist in the DAC boards of c1sus, I added the following code to the /cvs/cds/caltech/cds/advLigoRTS/src/fe/map.c

printk("DAC ASSC = 0x%x\n",dacPtr[devNum]->ASSC);

in the definition of mapDac() function.

This code prints the information of the ASSC (Assembly Configuration) register of the PMC66-16AO16 board as a kernel message at the start up time of the realtime code. You can check the message with dmesg command.

After the modification, I recompiled the c1sus and installed it.

make c1sus; make install-c1sus

After starting c1sus, I checked the dmesg. Then found that the ASSC register was set to 0x130006. To decipher this magic number, you have to consult with the manual of the DAC, which is available online.

http://www.generalstandards.com/view-products.php?product=pmc66-16ao16

The manual says the 17th and 18th bits of this number set the number of channels. Those bits are 11 for 0x130006. According to the manual, 11 means 16 channels are present. So it seems that the ASSC register is correctly set. In the case of CLIO, the ASSC register was 0x110003, meaning only 8 channels are present.

Unfortunately, the ASSC register was not the cause of the problem, but at least this possibility was checked.

The inner and outer screw holes of the EQ stop Jenne is talking about are shown in the photo below.