From what I understand, Alex rewrote portions of the framebuilder and testpoint codes and then recompiled them in order to get more than 1 testpoint per front end working. I've tested up to 5 testpoints at once so far, and it worked.
We also have a new noise component added to the RCG code. This piece of code uses the random number generator from chapter 7.1 of Numerical Recipies Third Edition to generate uniform numbers from 0 to 1. By placing a filter bank after it should give us sufficient flexibility in generating the necessary noise types. We did a coherence test between two instances of this noise piece, and they looked pretty incoherent. Valera will add a picture of it when it finishe 1000 averages to this elog.
I'm in the process of propagating the old suspension control filters to the new RCG filter banks to give us a starting point. Tomorrow Valera and I are planning to choose a subset of the plant filters and put them in, and then work out some initial control filters to correspond to the plant. I also need to think about adding the anti-aliasing filters and whitening/dewhitening filters.
Alex wrote a new code to implement LSP noise generator. The code is based on 64 bit random number generator from Numerical Recipes 3rd ed ch 7.1 (p 343).
Joe made two instances in the LSP model.
The attached plot shows the spectra and coherence of two generators. The incoherence is ~1/Navg - statistically consistent with no coherence.
I put matlab files and a summary into the 40m wiki for the fitting of the 40m Optickle transfer functions and generating digital filters for the simulated plant:
The filters are not loaded yet. Joe and Alex will make a rcg code to make a matrix of filters (currently 5x15=75 elements) which will enable the simulated plant tf's.
Joe and I tried to put a signal through the DARM loop but the signal was not going through the memory location in the scx part of the simulated plant.
Edit by Joe:
I was able to track it down to the spx model not running properly. It needed the Burt Restore flag set to 1. I hadn't done that since the last rebuild, so it wasn't actually calculating anything until I flipped that flag. The data is now circulating all the way around. If I turn on the final input (the same one with the initial 1.0 offset), the data circulates completely around and starts integrating up. So the loop has been closed, just without all the correct filters in.
A new webview of the LSP model is available at:
This model include a couple example noise generators as well as the new Matrix of Filter banks (5 inputs x 15 outputs = 75 Filters!). The attached png shows where these parts can be found in the CDS_PARTS library. I'm still working on the automatic generation of the matrix and filter bank medm screens for this part. The plan is to have a matrix screen similar to current ones, except that the value entry points to the gain setting of the associated filter. In addition, underneath each value, there will be a link to the full filter bank screen. Ideally, I'd like to have the filter adl files located in a sub-directory of the system, to keep clutter down.
I've cut and past the new Foton file generated by the LSP model below. The first number following the MTRX is the input the filter is taking data from and the second number is the output its pushing data to. This means for the script parsing Valera's transfer functions, I need to input which channel corresponds to which number, such as DARM = 0, MICH = 1, etc. So the next step is to write this script and populate the filter banks in this file.
# FILTERS FOR ONLINE SYSTEM
# Computer generated file: DO NOT EDIT
# MODULES DOF2PD_AS11I DOF2PD_AS11Q DOF2PD_AS55I DOF2PD_AS55Q
# MODULES DOF2PD_ASDC DOF2PD_POP11I DOF2PD_POP11Q DOF2PD_POP55I
# MODULES DOF2PD_POP55Q DOF2PD_POPDC DOF2PD_REFL11I DOF2PD_REFL11Q
# MODULES DOF2PD_REFL55I DOF2PD_REFL55Q DOF2PD_REFLDC Mirror2DOF_f2x1
# MODULES Mirror2DOF_f2x2 Mirror2DOF_f2x3 Mirror2DOF_f2x4 Mirror2DOF_f2x5
# MODULES Mirror2DOF_f2x6 Mirror2DOF_f2x7 DOF2PD_MTRX_0_0 DOF2PD_MTRX_0_1
# MODULES DOF2PD_MTRX_0_2 DOF2PD_MTRX_0_3 DOF2PD_MTRX_0_4 DOF2PD_MTRX_0_5
# MODULES DOF2PD_MTRX_0_6 DOF2PD_MTRX_0_7 DOF2PD_MTRX_0_8 DOF2PD_MTRX_0_9
# MODULES DOF2PD_MTRX_0_10 DOF2PD_MTRX_0_11 DOF2PD_MTRX_0_12 DOF2PD_MTRX_0_13
# MODULES DOF2PD_MTRX_0_14 DOF2PD_MTRX_1_0 DOF2PD_MTRX_1_1 DOF2PD_MTRX_1_2
# MODULES DOF2PD_MTRX_1_3 DOF2PD_MTRX_1_4 DOF2PD_MTRX_1_5 DOF2PD_MTRX_1_6
# MODULES DOF2PD_MTRX_1_7 DOF2PD_MTRX_1_8 DOF2PD_MTRX_1_9 DOF2PD_MTRX_1_10
# MODULES DOF2PD_MTRX_1_11 DOF2PD_MTRX_1_12 DOF2PD_MTRX_1_13 DOF2PD_MTRX_1_14
# MODULES DOF2PD_MTRX_2_0 DOF2PD_MTRX_2_1 DOF2PD_MTRX_2_2 DOF2PD_MTRX_2_3
# MODULES DOF2PD_MTRX_2_4 DOF2PD_MTRX_2_5 DOF2PD_MTRX_2_6 DOF2PD_MTRX_2_7
# MODULES DOF2PD_MTRX_2_8 DOF2PD_MTRX_2_9 DOF2PD_MTRX_2_10 DOF2PD_MTRX_2_11
# MODULES DOF2PD_MTRX_2_12 DOF2PD_MTRX_2_13 DOF2PD_MTRX_2_14 DOF2PD_MTRX_3_0
# MODULES DOF2PD_MTRX_3_1 DOF2PD_MTRX_3_2 DOF2PD_MTRX_3_3 DOF2PD_MTRX_3_4
# MODULES DOF2PD_MTRX_3_5 DOF2PD_MTRX_3_6 DOF2PD_MTRX_3_7 DOF2PD_MTRX_3_8
# MODULES DOF2PD_MTRX_3_9 DOF2PD_MTRX_3_10 DOF2PD_MTRX_3_11 DOF2PD_MTRX_3_12
# MODULES DOF2PD_MTRX_3_13 DOF2PD_MTRX_3_14 DOF2PD_MTRX_4_0 DOF2PD_MTRX_4_1
# MODULES DOF2PD_MTRX_4_2 DOF2PD_MTRX_4_3 DOF2PD_MTRX_4_4 DOF2PD_MTRX_4_5
# MODULES DOF2PD_MTRX_4_6 DOF2PD_MTRX_4_7 DOF2PD_MTRX_4_8 DOF2PD_MTRX_4_9
# MODULES DOF2PD_MTRX_4_10 DOF2PD_MTRX_4_11 DOF2PD_MTRX_4_12 DOF2PD_MTRX_4_13
# MODULES DOF2PD_MTRX_4_14
I've finished the MEDM portion of the RCG FiltMuxMatrix part. Now it generates an appropriate medm screen for the matrix, with links to all the filter banks. The filter bank .adl files are also generated, and placed in a sub directory with the name of the filter matrix as the name of the sub directory.
The input is the first number and the output is the second number. This particular matrix has 5 inputs (0 through 4) and 15 outputs (0 through 14). Unfortunately, the filter names can't be longer than 24 characters, which forced me to use numbers instead of actual part names for the input and output.
The key to the numbers is:
To get this working required modifications to the feCodeGen.pl and the creation of mkfiltmatrix.pl (which was based off of mkmatrix.pl). These are located in /cvs/cds/caltech/cds/advLigoRTS/src/epics/util/
In related news, I asked Valera if he could load the simulated plant filters he had generated, and after several tries, his answer was no. He says it has the same format as those filter they pass to the feed forward banks down in Livingston, so he's not sure why they won't work.
I tested my script, FillFotonFilterMatrix.py, on some simple second order section filters (like gain of 1, with b1 = 1.01, b2 = 0.02, a1 = 1.03, a2 = 1.04), and it populated the foton filter file correctly, and was parsed fine by Foton itself. So I'm going to claim the script is done and its the fault of the filters we're trying to load. This script is now living in /cvs/cds/caltech/chans/ , along with a name file called lsp_dof2pd_mtrx.txt which tells the script that DARM is 0, CARM is 1, etc. To run it, you also need a SOS.txt file with the filters to load, similar to the one Valera posted here, but preferably loadable.
I also updated my progess on the wiki, here.
It appears that foton does not like the unstable poles, which we need to model the transfer functions.
But one can try to load the filters into the front end by generating the filter file e.g.:
# MODULES DARM_ASDC
### DARM_ASDC ###
# SAMPLING DARM_ASDC 16384
# DESIGN DARM_ASDC
DARM_ASDC 0 21 6 0 0 darm 1014223594.005454063416 -1.95554205062071 0.94952075557861 0.06176931505784 -0.93823068494216
-2.05077577179611 1.05077843532639 -2.05854170261687 1.05854477394411
-1.85353637553024 0.86042048250739 -1.99996540107622 0.99996542454814
-1.93464836371852 0.94008893626414 -1.89722830906561 0.90024221050918
-2.04422931770060 1.04652211283968 -2.01120153956052 1.01152717233685
-1.99996545575365 0.99996548582538 -1.99996545573320 0.99996548582538
Unfortunately if you open and later save this file with foton it will strip the lhp poles.
I was getting an excess noise in the C1:IOO-MC_DRUM1 channel - it was a flat spectrum of 10 cts/rHz (corresponding to 600 uV/rHz).
I tried a few things, but eventually had to power cycle the crate with c1iovme in order to recover the standard ADC noise level of 3x10^-3 cts/rHz with a 1/sqrt(f) knee at 10 Hz.
I checked the gain of the channel by injecting a 2 Vpp sine wave at 137.035 Hz. 2Vpp as measured on a scope gives 31919 cts instead of the expected 32768, giving a 2.5% error from what we would have naively calculated.
Even so, the noise in this channel is very surprisingly good: 0.003 / (31919 / 2) = 187 nV /rHz. The best noise I have previously seen from an ICS-110B channel is 800 nV/rHz. What's going on here?
I visited downs and announced that I would be showing up again until all the 40m hardware is delivered.
I brought over 4 ADC boards and 5 DAC boards which slot into the IO chassis.
The DACs are General Standards Corporation, PMC66-16AO16-16-F0-OF, PCIe4-PMC-0 adapters.
The ADCs are General Standards Corporation, PMC66-16AI6455A-64-50M, PCIe4-PMC-0 adapters.
These new ones have been placed with the blue and gold adapter boards, under the table behind the 1Y4-1Y5 racks.
With the 1 ADC and 1 DAC we already have, we now have enough to populated the two ends and the SUS IO chassis. We have sufficient Binary Output boards for the entire 40m setup. I'm going back with a full itemized list of our current equipment, and bring back the remainder of the ADC/DAC boards we're due. Apparently the ones which were bought for us are currently sitting in a test stand, so the ones I took today were from a different project, but they'll move the test stand ones to that project eventually.
I'm attempting to push them to finish testing the IO chassis and the remainder of those delivered as well.
I'd like to try setting up the SUS IO chassis and the related computer this week since we now have sufficient parts for it. I'd also like to move megatron to 1Y3, to free up space to place the correct computer and IO chassis where its currently residing.
Yesterday afternoon I went to downs and acquired the following materials:
2 100 ft long blue fibers, for use with the timing system. These need to be run from the timing switch in 1Y5/1Y6 area to the ends.
3 ADCs (PMC66-16AI6455A-64-50M) and 2 DACs (PMC66-16AO16-16-F0-OF), bringing our total of each to 8.
7 ADC adapter boards which go in the backs of the IO chassis, bringing our total for those (1 for each ADC) to 8.
There were no DAC adapter boards of the new style available. Jay asked Todd to build those in the next day or two (this was on Thursday), so hopefully by Monday we will have those.
Jay pointed out there are different styles of the Blue and Gold adapter boxes (for ADCs to DB44/37) for example. I'm re-examining the drawings of the system (although some drawings were never revised to the new system, so I'm trying to interpolate from the current system in some cases), to determine what adapter style and numbers we need. In any case, those do not appear to have been finished yet (there basically stuffed boards in a bag in Jay's office which need to be put into the actual boxes with face plates).
When I asked Rolf if I could take my remaining IO chassis, there was some back and forth between him and Jay about numbers they have and need for their test stands, and having some more built. He needs some, Jay needs some, and the 40m still needs 3. Some more are being built. Apparently when those are finished, I'll either get those, or the ones that were built for the 40m and are currently in test stands.
Aparently Friday afternoon (when we were all at Journal Club), Todd dropped off the 7 DAC adapter boards, so we have a full set of those.
Things still needed:
1) 3 IO chassis (2 Dolphin style for the LSC and IO, and 1 more small style for the South end station (new X)). We already have the East end station (new Y) and SUS chassis.
2) 2 50+ meter Ethernet cables and a router for the DAQ system. The Ethernet cables are to go from the end stations to 1Y5-ish, where the DAQ router will be located.
3) I still need to finish understanding the old drawings drawings to figure out what blue and gold adapter boxes are needed. At most 6 ADC, 3 DAC are necessary but it may be less, and the styles need to be determined.
4) 1 more computer for the South end station. If we're using Megatron as the new IO chassis, then we're set on computers. If we're not using Megatron in the new CDS system, then we'll need a IO computer as well. The answer to this tends to depend on if you ask Jay or Rolf.
ORPHAN ENTRY FOUND ON ROSALBA:::::::::::::::::::::::::::::::::::::::::::::::::::>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
We did svn update. Then Alex realized he missed adding some files, so added them to the svn, and then we checked out again.
We rebuilt awg, fb, nds.
We reloaded service xinet.d, after editing /etc/xinetd.d/chnconf. We changes all the tpchn_c1 to tpchn_c1SYS
There's a new naming scheme for the model files. They start with the site name. So, lsc becomes c1lsc.
On any machine you want code running, make a symbolic link to /cvs/cds/rtcds/ in /opt/
This applies to SUS:
Two ICS 110Bs. Each has 2 (4 total) 44 shielded conductors going to DAQ Interface Chassis (D990147-A). See pages 2 and 4.
Three Pentek 6102 Analog Outputs to LSC Anti-Image Board (D000186 Rev A). Each connected via 40 conductor ribbon cable (so 3 total). See page 5.
Eight XY220 to various whitening and dewhitening filters. 50 conductor ribbon cable for each (8 total). See page 10.
Three Pentek 6102 Analog Input to Op Lev interface board. 40 conductor ribbon cable for each (3 total). See page 13.
The following look to be part of the AUX crate, and thus don't need replacement:
Five VMIC113A to various Coil Drives, Optical Levers, and Whitening boards. 64 conductor ribbon cable for each (5 total). See page 11.
Three XY220 to various Coil boards. 50 conductor ribbon for each (3 total). See page 11.
This applies to WFS and LSC:
Two XY220 to whitening 1 and 2 boards. 50 conductor ribbon for each (2 total). See page 3.
Pentek 6102 to LSC Anti-image. 50 conductor ribbon. (1 total). See page 5.
The following are unclear if they belong to the FE or the Aux crate. Unable to check the physical setup at the moment.
One VMIC3113A to LSC I & Q, RFAM, QPD INT. 64 conductor ribbon cable. (Total 1). See page 4.
One XY220 to QPD Int. 50 conductor ribbon cable. (Total 1). See page 4.
The following look to be part of WFS, and aren't needed:
Two Pentek 6102 Analog Input to WFS boards. 40 conductor ribbon cables (2 Total). See page 1.
The following are part of the Aux crate, and don't need to be replaced:
Two VMIC3113A to Demods, PD, MC servo amp, PZT driver, Anti-imaging board. 64 conductor ribbon cable (2 Total). See page 3.
Two XY220 to Demods, MC Servo Amp, QPD Int boards. 50 conductor ribbon cable (2 Total). See page 3.
Three VMIC4116 to Demod and whitening boards. 50 conductor ribbon cable (3 Total). See page 3.
Last week Alex merged in the changes I had made to the local 40m copy of the Real Time Code Generator. These were to add a new part, called FiltMuxMatrix, which is a matrix of filter banks, as well as fixing the filter medm generation code so the filter banks actually have working time stamps.
I checked out a new version of the CDS SVN with these changes merged in. Changes that will be added in the near future by Rolf and Alex include the addition of "tags". These are pieces in simulink which act as a bridge between two points, so you can reduce the amount of wire clutter on diagrams. Otherwise they have no real affect on the generated C code. Also the ADC/DAC channel selector and in fact the ADC/DAC parts will be changing. The MIT group has requested the channel selector be freed up for its original purpose in matlab, so Rolf is working on that.
For the time being, Alex has created a directory /rtcds on Linux1 under /home/cds. He then created softlinks to that directory on megatron, c1iscex, and allegra in the /opt directory. This was an easy way to have a shared path.
After checking out the CDS SVN, we discovered there some files missing that Alex had added to his version, but not the main branch. Alex came over to the 40m and proceeded to get all those files checked in. We then checked it out again. Changes were made to the awg, framebuilder, and nds codes and needed to be rebuilt.
Certain other file name conventions were also changed. Instead of tpchn_c1.par, tpchn_c2.par, etc, its now tpchn_c1lsc.par, tpchn_c2lsp.par, etc. The system name is included at the end of the filename, to help make it clearer what file goes with what.
This required an edit of the chnconf file, which has explicit calls to those file names. Once we edited that file, we had to reload the xinetd service which its apparently a subpart of (this can be accomplished by /etc/init.d/xinetd stop, then /etc/init.d/xinetd start).
/etc/rc.d/rc.local also had to be edited for the new model names (c1lsc, c1lsp, etc).
The daqdrc file (for the framebuilder) now parses which dcu_rate to use from the tpchn_c1lsc.par type files, so the dcu_rate 20 = 16384 lines have been removed. set gds_server has also been removed, and replaced with tpconfig "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par"; from which it can get the hostname. This information is now derived from the c1SYS.mdl file.
After that Alex informed me the IOP processor needs to be running for the other models to work properly, as well as for the Framebuilder to work.
Initially there was a problem running on Megatron, because the IOP gets its timing signal from the IO chassis, and there was none connected to megatron. However, he has since modified the code so that if there's no IO chassis, the IOP processor just uses the system clock. It has been tested and runs on megatron now.
Those drawings are an OK start, but its obvious that things have changed at the 40m since 2002. We cannot rely on these drawings to determine all of the channel counts, etc.
I thought we had already been through all this...If not, we'll have to spend one afternoon going around and marking it all up.
I talked with Rolf, and asked if we were using Megatron for IO. The gist boiled down to we (the 40m) needed to use it for something, so yes, use it for the IO computer. In regards to the other end station computer, he said he just needed a couple of days to make sure it doesn't have anything on it they need and to free it up.
I had a chat with Jay where he explained exactly what boards and cables we need. Adapter boards are 95% of the way there. I'll be stopping by this afternoon to collect the last few I need (my error this morning, not Jays). However it looks like we're woefully short on cables and we'll have to make them. I also acquired 2 D080281 (Dsub 44 x2 to SCSI).
For each 2 Pentek DACs plus a 110B, you need 1 DAC adapter board (D080303 with 2 connectors for IDC40 and a SCSI). You also need a D080281 to plug onto the back of the Sander box (going to the 110Bs) to convert the D-sub 44 pins to SCSI.
LSC will need none, SUS will need 3, IO will need 1, and the ends will need 1 each. We have a total of 6, we're set on D080303s. We have 3 110Bs, so we need one more D080281 (Dsub44 to SCSI). I'll get that this afternoon.
For each XVME220, we'll need one D080478 binary adapter. We have 8 XVME220s, and we have 8 boards, so we're set on D08478s.
For the ends, there's a special ADC to DB44/37 adapter, which we only have 1 one of. I need to get them to make 1 more of these boxes.
We have 1 ADC to DB37 adapter, of which we'll need 1 more of as well, one for IO and one for SUS.
However, for each Pentek ADC, we need a IDC40 to DB37 cable. For each Pentek DAC we need an IDC40 to IDC40 cable. We need a SCSI cable for each 110B. I believe the current XVME220 cables plug directly in the BIO adapter boxes, so those are set.
So we need to make or acquire 11 IDC40 to DB37 cables, 7 IDC40 to IDC40 cables, and 3 SCSI cables.
I picked up the ribbon cable connectors from Jay. It looks like we'll have to make the new cables for connecting the ADCs/DACs myself (or maybe with some help). We should be able to make enough ribbon cables for use now. However, I'm adding "Make nice shielded cables" to my long term to do list.
I pointed out the 2 missing adapter boxes we need to Jay. He has the parts (I saw them) and will try to get someone to put it together in the next day or so. I also picked up 2 more D080281 (DB44 to SCSI), giving us enough of those.
I once again asked Jay for an update on IO chassis, and expressed concern that without them the CDS effort can't really go forward, and that we really need this to come together ASAP. He said they still need to make 3 new ones for us.
So we're still waiting on a computer, 3 IO chassis, router + ethernet.
I spent this morning populating the SUS IO Chassis and getting it ready for installation into the 1Y4 rack. I discovered I'm lacking the internal cables to connect the ADC/DAC boards to the AdL adapter boards that also go in the chassis (D0902006 and D0902496). I'm not sure where Alex got the cables he used for the end IO chassis he had put in. I'll be going to Downs after the meeting today either to get cables or parts for cables, and get the SUS chassis wired up fully.
I'd also like to confirm with Alex that the OSS-MAX-EXP-ELB-C board that goes in the IO chassis matches the host interface board that goes in the computer (OSS-HIB2-PE1x4-1x4 Re-driver HIB, since we spent half a day the last time we installed an IO chassis determining that one of the pair was bad or didn't match.
The SUS chassis has been populated in the following way:
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 2 DAC PMC66-16AO16-16-F0-OF
Slot 3-6 BO Contec DIO-1616L-PE Isolated Digital IO board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 8-9 DAC PMC66-16AO16-16-F0-OF
Slot 1 ADC adapter D0902006
Slot 2 DAC adapter D0902496-v1
Slot 7 ADC adapter D0902006
Slot 8-9 DAC adapter D0902496-v1
Thanks to Steve's work on some L brackets, and Kiwamu's lifting help, we now have a new SUS IO chassis in the new 1X4 rack (formerly the 1Y4 rack), just below the new SUS and LSC computers. I have decided to call the sus machine, c1sus, and give it IP address 192.168.113.85. We also put in a host interface adapter, OSS-HIB2-PE1x4-1x4 Re-driver HIB, which connects the computer to the IO chassis.
The IP was added to the linux1 name server. However, the computer itself has not been configured yet. I'm hoping to come in for an hour or two tomorrow and get the computer hooked up to a monitor and keyboard and get its network connection working, mount /cvs/cds and get some basic RCG code running.
We also ran ethernet cables for the SUS machine to the router in 1X6 (formerly 1Y6) as well as a cable for megatron from 1X3 (formerly 1Y3) to the router, in anticipation of that move next week.
During the day, I realized we needed 2 more ADCs, one of which I got from Jay immediately. This is for two 110Bs and 4 Pentek ADCs. However, there's a 3rd 110B connected to c0dcu1 which goes to a BNC patch panel. Original Jay thought we would merge that into 4 pin lemo style into the 2nd 110B associated with the sus front ends. We've decided to get a another ADC and adapter. That will have to be ordered, and generally take 6-8 weeks. However, it may be possible to "borrow" one from another project until that comes in to "replace" it. This will leave us with our BNC patch panel and not force me to convert over 20 cables.
I also discovered we need one Contec DIO-1616L-PE Isolated Digital IO board for each Chassis, which I wasn't completely aware of. This is used to control the ADCs/DACs adapter boards in the chassis. It means we need still need to put a Binary Output board in the c1iscex chassis. Hopefully the chassis as they come in come from Downs continue to come with the Contec DIO-1616L-PE boards (they have so far).
The current loadout of the SUS chassis is as follows:
Far left slot, when looking from the front has the OSS-MAX-EXP-ELB-C board, used to communicate with the c1sus computer.
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 3-6 BO Contec DIO-32L-PE Isolated Digital Output board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 10-11 ADC PMC66-16AI6455A-64-50M
Slot 12 Contect DIO-1616L-PE Isolated Digital IO board
Slot 10-11 ADC adapter D0902006
Kiwamu and I went through and looked at the spare channels available near the PSL table and at the ends.
First, I noticed I need another 4 DB37 ADC adapter box, since there's 3 Pentek ADCs there, which I don't think Jay realized.
Anyways, in the IOO chassis that will put in, for the ADC we have a spare 8 channels which comes in the DB37 format. So one option, is build a 8 BNC converter, that plugs into that box.
The other option, is build 4-pin Lemo connectors and go in through the Sander box which currently goes to the 110B ADC, which has some spare channels.
For DAC at the PSL, the IOO chassis will have 8 spare channel DAC channels since there's only 1 Pentek DAC. This would be in a IDC40 cable format, since thats what the blue DAC adapter box takes. A 8 channel DAC box to 40 pin IDC would need to be built.
The ends have 8 spare DAC channels, again 40 pin IDC cable. A box similar to the 8 channel DAC box for the PSL would need to be built.
The ends also have spare 4-pin Lemo capacity. It looked like there were 10 channels or so still unused. So lemo connections would need to be made. There doesn't appear to be any spare 37 DB connectors on the adapter box available, so lemo via the Sander box is the only way.
Joe needs to provide Kiwamu with cabling pin outs.
If Kiwamu makes a couple spares of the 8 BNC to 37DB connector boards, there's a spare 37DB ADC input in the SUS machine we could use up, providing 8 more channels for test use.
I connected a monitor and keyboard to the new c1sus machine and discovered its not running RTL linux. I changed the root password to the usual, however, without help from Alex I don't know where to get the right version or how to install it, since it doesn't seem to have an obvious CD rom drive or the like. Hopefully Tuesday I can get Alex to come over and help with the setup of it, and the other 1-2 IO chassis.
I went to talk to Rolf and Jay this morning. I asked Rolf if a chassis was available, so he went over and disconnected one of his test stand chassis and gave it to me. It comes with a Contect DIO-1616L-PE Isolated Digital IO board and an OSS-MAX-EXP-ELB-C, which is a host interface board. The OSS board means it has to go into the south end station. There's a very short maximum cable length associated with that style, and the LSC and IOO chassis will be further than that from their computers (we have dolphin connectors on optical fiber for those connections).
I also asked Jay for another 4 port 37 d-sub ADC blue and gold adapter box, and he gave me the pieces. While over there, I took 2 flat back panels and punched them with approriate holes for the scsi connectors that I need to put in them. I still need to drill 4 holes in two chassis to mount the boards, and then a bit of screwing. Shouldn't take more than an hour to put them both together. At that point, we should have all the adapter boxes necessary for the base design. We still need some stuff for the green locking, as noted on Friday.
I talked to Alex, and he explained the steps necessary to get the real time linux kernel installed. It basically went like copy the files from c1iscex (the one he installed last month) in the directory /opt/rtlidk-2.2 to the c1sus locally. Then go into rtlinux_kernel_2_6, and run make and make install (or something like that - need to look at the make file). Then edit the grub loader file to look like the one on c1iscex (located at /boot/grub/menu.lst).
This will then hopefully let us try out the RCG code on c1sus and see if it works.
After talking with Rolf, and clarifying exactly which machine I wanted, he gave me an 4600 Sun machine (similar to our current megatron). I'm currently trying to find a good final place for it, but its at least here at the 40m.
I also acquired 3 boards to plug our current VMIPMC 5565 RFM cards into, so they can be installed in the IO chassis. These require +/- 5V power be connected to the top of the RFM board, which would be not possible in the 1U computers, so they have to go in the chassis. These style boards prevent the top of the chassis from being put on (not that Rolf or Jay have given me tops for the chassis). I'm planning on using the RFM cards from the East End FE, the LSC FE, and the ASC FE.
I talked to Jay, and offered to upgrade the old megatron IO chassis myself if that would speed things up. They have most of the parts, the only question being if Rolf has an extra timing board to put in it. Todd is putting together a set of instructions on how to put the IO chassis together and he said he'd give me a copy tomorrow or Monday. I'm currently planning on assembling it on Monday. At that point I only need 1 more IO chassis from Rolf.
When I asked about the dolphin IO chassis, he said we're not planning on using dolphin connections between the chassis and computer anymore. Apparently there was some long distance telecon with the dolphin people and they said the Dolphin IO chassis connection and RFM doesn't well together (or something like that - it wasn't very clear from Rolf's description). Anyways, the other style apparently is now made in a fiber connected version (they weren't a year ago apparently), so he's ordered one. When I asked why only 1 and what about the IOO computer and chassis, he said that would either require moving the computer/chassis closer or getting another fiber connection (not cheap).
So the current thought I hashed out with Rolf briefly was:
We use one of the thin 1U computers and place that in the 1Y2 rack, to become the IOO machine. This lets us avoid needing a fiber. Megatron becomes the LSC/OAF machine, either staying in 1Y3 or possibly moving to 1Y4 depending on the maximum length of dolphin connection because LSC and the SUS machine are still supposed to be connected via the Dolphin switch, to test that topology.
I'm currently working on an update to my CDS diagram with these changes and will attach it to this post later today.
This is the machine which will be the new x end front end machine. Its IP is 192.168.113.86.
We changed the root and controls passwords to the usual. We have modified the controls user group to be 1001, by using "usermod -u 1001 controls" (we had to use the non-rtl kernel to get that command to work).
We changed /etc/fstab to point to /cvs/cds on Linux rather than some downs machine. We added a link to /cvs/cds/rtcds in the local /opt directory.
We modified the /etc/rc.d/rc.local file to no longer run /opt/open-mx/sbin/omx_init start, /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 om1, and /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 -e2 -r2 om2. We modified the /usr/bin/setup_shmem.rtl to run only c1x00 c1scx and c1spx.
I also commented out a line0 "/bin/rm -f /rtl*"
The timing slave in the IO chassis on the new X end was not working with symptoms of no front "OK" green light, no "PPS" light, 3.3V testpoint not working and ERROR testpoint bouncing between 5-6V.
We took out the timing slave from the X end IO chassis put in to the new Y end IO chassis .
It worked perfectly there. We took the working one from Y end put in the X end IO chassis.
We slowly added cables. First we added power , it worked fine and we saw green "OK" light. Then we added 1PPS signal by a fiber and it also worked.
We turned everything off and then we added 40pin IPC cable from the chassis and infiniband cable from the computer.
When we turned ON it we didn't see the green light.
This means something in the computer configuration might be wrong not in the timing card, we now are trying to make contact with Alex.
We are comparing the setup of the C1SCX machine and the working C1ISCEX machine.
The End IO chassis have small trenton boards, which apparently only have 5 usuable PCI slots, even though there are 6 on the board. This is because of the way the the host interface board is setup and its closeness to the 2nd to last PCI slot
The PMC to PCIe adapters I was handed by Jay for use with the RFM cards require a 4 pin power connection at the top, which are not available inside the thin 1U computers.
The only solution I can come up with is swap the PMC to PCIe adapters for the RFM cards with adapters for some of the already installed ADCs and DACs which do not require power directly from the power supply. This should make it possible to mount the RFM card in the computer, at least for the ends. Since the SUS and IOO chassis will have more slots available than needed, the RFM cards can be slotted into those. The SUS has to fit in the chassis since the computer will have the Infiband host adapter and a dolphin connector for talking to the LSC machine.
There is still the problem of actually getting the RFM card into the computer, but that should be possible with a little bit of bending of the left side of the computer frame.
I re-routed around the c1lsc machine this morning. I turned the crate off, and disconnected the transmission fiber from c1lsc (which went to the receiver on c1asc). I then took the receiving fiber from c1lsc and plugged it into the receiver on c1asc.
I pulled out the c1lsc computer from the VME crate and pulled out the RFM card, which I needed for the CDS upgrade. I then replaced the lsc card back in the crate and turned it back on. Since there hasn't been a working version of the LSC code on linux1 since I overwrote it with the new CDS lsc code, this shouldn't have any significant impact on the interferometer.
I've confirmed that the RFM network seems to be in a good state (the only red lights on the RFM timing and status medm screen are LSC, ASC, and ETMX). Fast channels can still be seen with dataviewer and fb40m appears to still be happy.
The RFM card has found its new home in the SUS IO Chassis. The short fiber that used to go between c1asc and c1lsc is now on the top shelf of the new 1X3 rack.
Kiwamu and I strung an ethernet cable from the new 1X7 rack to the 1X3 rack. The cable is labeled c1iscex-daq on both ends. This cable will eventually connect c1iscex's second ethernet port to the daq router. However, for today, it plugged into the primary ethernet port and is going to a linksys router. This is the same linksys router we used to firewall megatron.
The idea is to place megatron, c1sus, and c1iscex behind the firewall to prevent any problems with the currently running while doing RFM nework tests.
The way to get into the firewalled sub-network is to ssh into megatron. The router will forward the ssh to megatron. Inside the network, the computers will have the following IPs. Router is 192.168.1.1, megatron is 192.168.1.2, c1sus is 192.168.1.3, and c1iscex is 192.168.1.4.
I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation
depth slider for the MC is now in an unknown state.
If you're refering to just the medm screen, those can be restored from the SVN. As we're moving to a new directory structure, starting with /opt/rtcds/caltech/c1/, the old LSC screens can all be put back in the /cvs/cds/caltech/medm/c1/lsc directory if desired.
The slow lsc aux crate, c1iscaux2, is still working, and those channels are still available. I confirmed that one was still updating. As a quick test, I went to the SVN and pulled out the C1LSC_RFADJUST.adl file, renamed it to C1LSC_RFadjust.adl and placed it in /cvs/cds/caltech/medm/c1/lsc/, and checked it linked properly from the C1IOO_ModeCleaner.adl file. I haven't touched the modulation depths, as I didn't want to mess with the mode cleaner, but if I get an OK, we can test that today and confirm that modulation depth control is still working.
A brief report about the new front end machine "C1ISCEX" installed on the X end (old Y end).
All 16 channels are working well.
We can see the signals in the medm screen while injecting some signals to the ADC by using a function generator.
All 16 channels do NOT work.
We can not see any signals at the DAC SCSI cable while digitally injecting a signal on the medm screen.
Kiwamu and I strung a temporary RFM fiber from the c1iscex machine (in the new 1X9 rack) to the c1sus machine (in the new 1X4 rack). This was connected into the respective RFM cards. Once we put the fiber in correctly, the status lights came on the RFM card, which is a good sign. This did not go through the RFM bypass, and did not interfere with any other RFM connections.
We created a simple model to test the RFM card, which basically was 4 RFM memory locations passing back and forth between 2 filters on each machine. These models were called c1rf0 (on c1sus) and c1rf1 (on c1iscex). We added 4 entries to the /cvs/cds/caltech/chans/ipc/C1.ipc file corresponding to the 4 RFM memory locations, set their ipcType=RFM and set the ipcRate to 65536. The ipcNum were set from 0 to 3. The models ran, however, the data we were trying to pass over the RFM card did not seem to be being passed. Currently trying to contact Alex via e-mail to get debugging advice, and confirm the ipc file is setup correctly.
Since the RFM on the new CDS is not working, we had to test it by using some softwares.
I installed a driver for PCI-5565 on C1SUS and ran a test script wich is one of the packaged test scripts in the driver.
So far the RFM card on C1SUS looked correctly mounted, but I didn't check the memory location and the sending/ receiving functions.
This test will continue sometime on August because right now the RFM test is not higher priority.
Alex suggested to use a driver package for PIC-5565 called "RFM2g Linux 32/64-bit PCIE/PCI/PMC driver for x86 kernels R7.03" , which is available on this web site.
And the package contains some useful test scripts which exactly we want to run for RFM test.
I downloaded the driver and put it on C1SUS.
After doing usual "unzip", "tar" and "make" things, I ran one of the test script called "rfm2g_util".
Currently it lives under /home/controls/Desktop/162-RFM2G-DRV-LNX-R07_03-000/rfm2g/diags/rfm2g_util on C1SUS.
It invokes an interactive shell and firstly it asks the mount point of the RFM card.
I eventually found the card was mounted on #1 which means the card is correctly mounted.
Some detail procedures will be summarized on the wiki later.
[Joe and Kiwamu]
Ok, after a few minutes of talking to Alex, I got the correct "GUI syntax" through my head, and we now have a simple working green end control which in fact puts signals out through the DAC.
Note to self, do not put any additional filters or controls in the IOP module. Basically just change the master block with GDS numbers, DCU_ID numbers, etc. When using a control model, copy the approriate ADC and ADC selector or DAC to the control model. It will magically be connected to the IOP.
A correct example of a simple control model is attached.
Next in line is to get the adapter boxes for SUS into the new 1X5 rack and get started on SUS filter conversion and figuring out which ADC/DAC channels correspond to which inputs.
We are currently using the SUS wiring diagram found on Ben Abbott's page (link here) to determine the ADC/DAC/BO channel numbers for each individual optics inputs and outputs. Basically it involves tracking the paths back from the Pentek's, XY220, and IC110Bs to a point where we can identify it as a Coil UL or a PD whitening filter control or whatever it might be.
Once done we will have a nice wiki page describing what the final wiring is going to be, along with which ADC effectively plugs into which analog board and so forth.
Last Thursday, Kiwamu and I went through the cabling necessary for a full damping test of the vertex optics controled by the sus subsytem, i.e. BS, ITMX, ITMY, PRM, SRM. The sus IO chassis is sitting in the middle of the 1X4 rack. The c1sus computer is the top 1U computer in that rack.
The hardest part is placing the 2x D-sub connectors to scsi on the lemo break out boxes connected to the 110Bs. The breakout boxes can be seen at the very top of the picture Kiwamu took here. These will require a minor modification to the back panel to allow the scsi cable to get out. There are two of these boxes in the new 1X5 rack. These would be connected by scsi to the ADC adapters in the back of the sus IO chassis in 1X4. The connectors are currently behind the new 1X5 rack (along with some spare ADCs/DACs/BOs.
There are 3 cables going from 40 IDC to 37 D-sub (the last 3 wires are not used and do not need to be connected, i.e. 38-40). These plug into the blue and gold ADC adapter box, the top one shown here. There is one spare connection which will remain unused for the moment. The 40 IPC ends plug into the Optical Lever PD boxes in the upper right of the new 1X4 rack (as seen in the top picture here - the boards on the right). At the back of the blue and gold adapter box is a scsi adapter which goes to the back of the IO chassis and plugs into an ADC.
In the back of the IO chassis is a 4th ADC which can be left unconnected at this point. It will eventually be plugged into the BNC breakout box for PEM signals over in the new 1X7 rack, but is unneeded for a sus test.
There are 5 cables going from 3 SOS dewhite/anti-image boards and 2 LSC anti-image boards into 3 blue and gold DAC adapter boxes. Currently they plug into the Pentek DACs at the bottom of the new 1X4 rack. Ideally we should be able to simply unplug these from the Pentek DACs and plug them directly into the blue and gold adapter boxes. However at the time we checked, it was unclear if they would reach. So its possible new cables may need to be made (or 40 pin IDC extenders made). These boxes are then connected to the back of the IO chassis by SCSI cables. One of the DAC outputs will be left unconnected for now.
The Binary output adapter boxes are plugged into the IO chassis BO cards via D-sub 37 cables. Note one has to go past the ADC/DAC adapter board in the back of IO chassis and plug directly into the Binary Output cards in the middle of the chassis. The 50 pin IDC cables should be unplugged from XY220s and plugged into the BO adapter boxes. It is unclear if these will reach.
We have a short fiber cable (sitting on the top shelf of the new 1X3 rack) which we can plug into the master timing distribution (blue box located in the new 1X6 rack) and into the front of the SUS IO chassis. It doesn't quite make it going through all the holes at the top of the racks and through the cabling trays, so I generally only plug it in for actual tests.
The IO chassis is already plugged into the c1sus chassis with an Infiniband cable.
So in Summary to plug everything in for a SUS test requires:
Tomorrow, I will finish up a channel numbering plan I started with Kiwamu on Thursday and place it in the wiki and elog. This is for knowing which ADC/DAC/BO channel numbers correspond to which signals. Which ADCs/DACs/BOs the cables plug into matter for the actual control model, otherwise you'll be sending signals to the wrong destinations.
Ideally we can reuse the existing cables, but some of them may not be long enough for the new wiring.
The diagram below shows extremely non-ideal case.
While working on a test stand at LLO, I've discovered that there's a new update to the Real Time Code Generator that breaks virtually all of our current models.
Previously, we've been using the cdsIPCx part as a flexible link between models, and could be set to RFM (reflected memory), SHMEM (shared memory on the local computer), or PCIE (pci express or dolphin I think) depending on what was written in the IPC file (found in /cvs/cds/caltech/chans/ipc/C1.ipc).
Recently, three new parts were added called cdsIPCx_SHMEM, cdsIPCx_RFM, cdsIPCx_PCIE, and the previous cdsIPCx broken. The cdsIPCx_***** has to match the type written in the IPC file or else it errors out with a rather unhelpful error message which doesn't tell you which part/line is in conflict...
***ERROR: IPCx type mis-match: I vs. ISHM
make: *** [g1lsc] Error 255
In anycase, when using a current checkout (updated or checked out after ~July 30th), all cdsIPCx blocks in the simulink models needs to be changed to the approriate type. I'm trying to get a new CDS_PARTS.mdl file I updated into the svn, but for now you can just open up the model file directly in the /advLigoRTS/src/epics/simLink/lib directory and copy it in from there (i.e. cdsIPCx_SHMEM.mdl) to your model file. I'm also trying to get the feCodeGen.pl file changed so the error message actually tells you what channel/part is mismatching so you don't have to guess.
An easy way to modify a file for all shared memory connections without doing a ton of cutting, pasting and renaming is:
sed -i 's/"cdsIPCx"/"cdsIPCx_SHMEM"/g' file_name_here.mdl
All the necessary cables are in our hands, such as SCSIs, 37 pin D-sub and 3 pin power cables.
With a big help from Jenne and Koji, we made 37 pin F/M cables and 3 pin power cables on the last Tuesday.
Now all the cables are connected to the machines except for the 3 pin power cables.
To install the power cables I will switch off Sorensens at new 1X5 for a minute.
The model file named C1SUS was made and I succeeded in compiling and building it. So it is ready for the test.
But some medm screens look like not correctly complied.
For example the channel names which are listed on C1SUS_MONITOR_ADC0.adl aren't correctly assigned.
All the ADC channels are working. Also the channel assignments are correct.
I checked all the ADC channels if it was working while I ran the front end realtime code C1SUS.
By injecting a signal from a function generator directly to the SCSIs, I could clearly see the numbers hopping on medm screens.
None of them are working although the computer can recognize that all three DAC cards are mounted.
I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry )
I have to fix it anyhow because the DACs are very necessary part for this damping test.
They didn't work at all. Even the computer didn't recognize the binary output cards.
I think I should put some magical components on the model files.
- Binary Outputs
- simlink realtime model with the new CDS PARTS ( see the notice from Joe )
To be done
When I was working on a new front end machine c1sus, I found that make command didn't run and gave the following message.
"make:warning:clock skew detected.Your build may be incomplete"
This was caused by a clock difference between the nfs (nodus) and the terminal machine (c1sus).
I had to set up ntp daemon to synchronize them. Here is a procedure to set up it
- log in to a front end machine
- enable the ntp daemon
- configure the ntpd
vi (emacs) /etc/ntp.conf
vi (emacs) /etc/ntp.conf
- below is the contents I wrote on ntp.conf
server 192.168.113.200 minpoll 4 maxpoll 4 iburst
server 192.168.113.200 minpoll 4 maxpoll 4 iburst
sudo service ntpd start
First, awesome progress.
Second, the Binary Output parts do in fact need to be added to the c1sus model. They don't need to appear in the IOP though. (They are somehow automatically taken care of by the IOP code).
It looks like in the 2004 revision in SVN, the cdsCDO32 part (located in the CDS_PARTS.mdl/IO_PARTS) was broken. I fixed it and updated the svn with it, so a svn update should pull the corrected version.
I'm not sure whats wrong with the DAQs. I'll try to take a closer look at the model file tonight and see if I can make suggestions. When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything?
The medm screen C1SUS_GDS_TP.adl showed some numbers which correspond to that I wrote on the outputs.
But I still could not get any physical voltage coming from the DACs.
When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything?
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.
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.
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.
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).
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.
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.
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).
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.
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.
Woooo Yeaaaah !
With the new CDS we succeeded in damping of PRM and BS !!
For a futher damping test, I again turned off the vertex optics watchdogs temporarily, including BS, ITMs, SRM, PRM, MCs.