Looking at the old latch.st code, looks like this is just a heartbeat signal to indicate the code is alive. I'll implement this. Aesthetically, it'd be also nice to have the hex representation of the "*_SET" channels visible on the MEDM screen.
Latch logic works. But latch alive signal is missing.
DATED, SEE ELOG14941 for the most up-to-date info on latch.py.
I modified /cvs/cds/caltech/target/c1iscaux/latch.py and /cvs/cds/caltech/target/c1iscaux/C1_ISC-AUX_CM.db to set up the mbbo logic for the other three channels on the CM board, namely REFL2 Gain, AO Gain, and the Super boosts. The systemctl processes were restarted on c1iscaux. We are now ready to perform systematic checks on the CM board functionality.
The addressing of the Acromag BIO registers is done in a way that is kind of inconvenient to use the EPICS mbboDirect protocol
I tested the new latch.py script by toggling the various sliders (one at a time) between two values and monitoring the states of the various soft and "*_BITS" channels, see Attachment #1. The behavior seems consistent to me, but to be sure, we have to use Koji's LED tester board and confirm that the physical bits are being toggled correctly. The StripTool templates live in /cvs/cds/caltech/target/c1iscaux/CMdiag.
I have not yet implemented the fix for the MBBO gain channels for all the gains - only REFL1_GAIN is set up correctly now. Need to look at the hardware for the correct addressing of bits
The machine needed a hard reboot as it was un-ssh-able.
The exact time that the machine went down is unknown because the blinkys were not DQ-ed. I've now added these to the EDCU to make these channels actually useful, and we may look back on the reliability (or otherwise) of the Acromag system. To my memory, this is the ~5th time one of the new Acromag servers has needed a hard reboot. While this may be less frequent (?) than the VME machines, perhaps there is some other reason for these dropouts. Maybe something to do with the martian network?
Anyway the machine is back up and running now.
While checking whitening filters on the LSC rack, I found some epics controls for the whitening looked not working.
So I powered two crates off : the top one and the bottom one on 1Y3 rack.
These crates contain c1iscaux and c1iscaux2. Then powered them on. But it didn't solve the issue.
Keying again did not help to solve the issue. I turned off the power at the back of the crate, and turn it on again.
Then the key worked again.
c1iscaux2 is burtrestored and running fine now.
- One of the VME rack on 1X3 is not showing the +/-15V green LED lights.
This is the one on very upper side of the rack, which contains the old c1lsc machine and c1iscaux2. If we are still using c1iscaux2, it needs to be fixed.
We saw some white boxes on the LSC screens.
We found c1iscaux2 is not running.
Once the target was power-cycled, these epics channels are back.
Then c1iscaux2 were burtrestored using the snapshot at 5:07 on 4/16, a day before the power glitch.
c1iscex has not been running for a couple of days (since the power shutdown at least). I was assuming that the problem was recurrence of the c1iscex IO chassis issue from a couple weeks ago (5854). However, upon investigation I found that the timing signals were all fine. Instead, the IOP was reporting that it was finding now ADC, even though there is one in the chassis.
Since I had a spare ADC that was going to be used for the CyMAC, I decided to try swapping it out to see if that helped. Sure enough, the system came up fine with the new ADC. The IOP (c1x01) and c1scx are now both running fine.
I assume the issue before might have been caused by a failing and flaky ADC, which has now failed. We'll need to get a new ADC for me to give back to the CyMAC.
I appears that the c1iscex IO-chassis is either dead or in a very bad state. The PCIe interface card in the IO-chassis is showing four red lights, where it's supposed to be showing a dozen or so green lights. Obviously this is going to prevent anything from running.
We've had power issues with this chassis before, so possibly that's what we're running into now. I'll pull the chassis and diagnose asap.
c1iscex is back up. It is communicating with it's IO chassis, and all of it's models (c1x01, c1scx, c1spx) are running again.
The problem was that the IO chassis had no connection to the computer. The One Stop card in the IO chassis, which is the PCIe bridge from the front-end machine and the IO chassis, was showing four red lights instead of the dozen or so green lights that it usually shows. Upon closer inspection, the card appeared to be complaining that it had no connection to the host card in the front-end machine. Un-illuminated lights on the host card seemed to be pointing to the same thing.
There are two connector slots on the expansion card, presumably for a daisy chain situation. Looking at other IO chassis in the lab I determined that the cable from the front-end machine was plugged into the wrong slot in the One Stop card. wtf.
Did someone unplug the cable connecting c1iscex to it's IO chassis, and then replug it in in the wrong slot? A human must have done this.
Since the 1U sized computers don't have enough slots to hold the host interface board, RFM card, and a dolphin card, we had to move the 2U computer from the end to middle to replace c1sus.
We're hoping this will reduce the time associated with reads off the RFM card compared to when its in the IO chassis. Previous experience on c1ioo shows this change provides about a factor of 2 improvement, with 8 microseconds per read dropping to 4 microseconds per read, per this elog.
So the dolphin card was moved into the 2U chassis, as well as the RFM card. I had to swap the PMC to PCI adapter on the RFM card since the one originally on it required an external power connection, which the computer doesn't provide. So I swapped with one of the DAC cards in the c1sus IO chassis.
But then I forgot to hit submit on this elog entry..............
After I did several things to add new DAQ channels on c1iscex it suddenly became out of network. Maybe crashed.
Then c1iscex didn't respond to a ping and all the epics values associated with c1iscex became not accessible.
I physically shut it down by pushing the reset button. Then it came back and is now running fine.
(how I broke it)
Since activateDAQ.py has screwed up the 'ini' files including C1SCX.ini, I was not able to add a channel to C1SCX.ini by the usual daqconfig GUI.
So I started editing it in a manual way with an editor and changed some sentences to that shown below
Then I rebooted fb to reflect the new DAQ channels.
After that I looked at the C1_FE_STATUS.adl screen and found some indicator lights were red.
So I pushed "Diag reset" button and "DAQ Reload" button on the C1SCX_GDS_TP.adl screen and then c1iscex died.
After the reboot the new DAQ channels looked acquired happily.
This is my second time to crash a front end machine (see this entry)
c1iscex is dead again. Red lights, no "breathing" on the FE status screen.
c1iscex is working as before and the optic is damped.
What I checked
1. I went to the X-end rack. I found the io-chassis was turned off.
2. I shutdown c1iscex, turned off, and turned on everything. Again, we did not have any signal from the ADC into c1scx model.
However, I found that c1x01 indicates healthy ADC signals.
This means that the connection between the IOP and the c1scx model was wrong ==> Simulated Plant
3. Burtrestored X'mas eve snapshot. This restored the gains and matrices as well as C1:SCX-SIM_SWITCH
which switches the input between the real ADCs and simulated plant.
4. The signals came back to c1scx.
c1iscex does not even see its 32 channel Binary output card. This means we have no control over the state of the analog whitening and dewhitening filters. The ADC, DAC, and the 1616 Binary Input/Output cards are recognized and working.
Tried recreating the IOP code from the known working c1x02 (from the c1sus front end), but that didn't help.
Checked seating of the card, but it seems correctly socketed and tightened down nicely with a screw.
Tomorrow will try moving cards around and see if there's an issue with the first slot, which the Binary Output card is in.
The ETMX is currently damping, including POS, PIT, YAW and SIDE degrees of freedom. However, the gds screen is showing a 0x2bad status for the c1scx front end (the IOP seems fine with a 0x0 status). So for the moment, I can't seem to bring up c1scx testpoints. I was able to do so earlier when I was testing the status of the binary outputs, so during one of the rebuilds, something broke. I may have to undo the SVN update and/or a change made by Alex today to allow for longer filter bank names beyond 19 characters.
c1iscex was spamming the network with error messages.
Updated the front end codes to current standards (they were on the order of months out of date). After fixing them up and rebuilding the codes on c1iscex, it no longer had problems connecting to the frame builder.\
I can look at test points for ETMX. It is not currently damping however.
Move filters for ETMX into the correct files.
Need to add a Binary output blue and gold box to the end rack, and plug it into the binary output card. Confirm the binary output logic is correct for the OSEM whitening, coil dewhitening, and QPD whitening boards.
Get ETMX damped.
Figure out what we're going to do with the aux crate which is currently running y-end code at the new x-end. Koji suggested simply swapping auxilliary crates - this may be the easiest. Other option would be to change the IP address, so that when it PXE boots it grabs the x-end code instead of the y-end code.
Current CDS status:
Here is what was done (Jamie will correct me if I am mistaken).
So while we are in a better state now, the problem isn't fully solved.
Comment: seems like there is an in-built timeout for testpoints opened with DTT - if the measurement is inactive for some time (unsure how much exactly but something like 5mins), the testpoint is automatically closed.
This morning, all the c1iscex models were dead. Attachment #1 shows the state of the cds overview screen when I came in. The machine itself was ssh-able, so I just restarted all the models and they came back online without fuss.
This was me. I had rebooted that machine and hadn't restarted the models. Sorry for the confusion.
The c1iscex machine itself wasn't dead, the models were just not running. Here are the last messages in dmesg:
[130432.926002] c1spx: ADC TIMEOUT 0 7060 20 7124
[130432.926002] c1scx: ADC TIMEOUT 0 7060 20 7124
[130433.941008] c1x01: timeout 0 1000000
[130433.941008] c1x01: exiting from fe_code()
I'm guessing maybe the timing signal was lost, so the ADC stopped clocking. Since the ADC clock is the everything clock, all the "fe" code (ie. models) aborted. Not sure what would have caused it.
I restarted all the models ("rtcds restart all") and everything came up fine. Obviously we should keep our eyes on things, and note if anything strange was happening if this happens again.
c1iscex was behaving very strangely this morning. Steve earlier reported that he was having trouble pulling up some channels from the c1scx model. I went to investigate and noticed that indeed some channels were not responding.
While I was in the middle of poking around, c1iscex stopped responding altogether, and became completely unresponsive. I walked down there and did a hard reset. Once it rebooted, and I did a burt restore from early this morning, everything appeared to be working again.
The fact that problems were showing up before the machine crashed worries me. I'll try to investigate more this afternoon.
I started to modify the c1asx model to reduce the RFM model from hitting its max time.
Instead of bringing in ASS, I have modified ASX to do everything and only the clock signals to ITMX pitch and yaw are now going through RFM. RFM is still hitting 62usec and I suppose that is because of the problems with c1iscex.
c1iscex not happy
Cause and symptoms
While restarting the models, c1iscex crashed a couple of times because of some errors and had to be powercycled. The models were modified and they seem to start ok.
But it looks like there is something wrong with c1iscex since the models were started. The GPS time is off and C1:DAQ-DC0_C1X01_CRC_SUM keeps building up even for c1x01 which was left untouched.
1. Since c1x01 ans c1spx were not touched,c1scx and c1asx were killed and we tried to start the other models. This did not help.
2. Koji did a manual daqd restart which did not help either.
We are leaving c1iscex as is for the time being and calling Jamie for help.
P.S. While making the models, I had created IPCx_PCIE blocks in c1iscex which do not exist. I changed them to RFM and SHMEM blocks. This did not allow me to compile the model and was only spitting errors of IPCx mismatch. After some struggle and elog search I figured out from an old elog that eventhough the IPCx blocks are changed in the model, the old junk exists in the ipc file in chans directory. I deleted all junk channels related to the ASX model. The model compiled right away.
Sorrensen ps ouput of +15V at rack 1X9 was current limited to 10.3V @ 2A
Increased threshold to 2.1A and the voltage is up to 14.7V
I'm not sure why, but c1iscex did not want to do an mxstream restart. It would complain at me that "* ERROR: mx_stream is already stopping."
Koji suggested that I reboot the machine, so I did. I turned off the ETMX watchdog, and then did a remote reboot. Everything came back nicely, and the mx_stream process seems to be running.
* ERROR: mx_stream is already stopping.
I swapped out the IO chassis which could only handle 3 PCIe cards with the another chassis which has space for 17, but which previously had timing issues. A new cable going between the timing slave and the rear board seems to have fixed the timing issues.
I'm hoping to get a replacement PCI extension board which can handle more than 3 cards this week from Rolf and then eventually put it in the Y-end rack. I'm also still waiting for a repaired Host interface board to come in for that as well.
At this point, RFM is working to c1iscex, but I'm still debugging the binary outputs to the analog filters. As of this time they are not working properly (turning the digital filters on and off seems to have no effect on the transfer function measured from an excitation in SUSPOS, all the way around to IN1 of the sensor inputs (but before measuring the digital fitlers). Ideally I should see a difference when I switch the digital filters on and off (since the analog ones should also switch on and off), but I do not.
We noticed that the iscex computer is still down, but the IOP is (was) running. When we sat down to look at it, c1x01 was 'breathing', had a non-zero CPU_METER time, and the error was 0x4000, which I've never seen before. The fb connection was still red though. Also, it is claiming that its sync source is 1pps, not TDS like it usually is.
Since things were different, Koji restarted the 2 other models running on iscex, with no resulting change. We then did a 'rtcds restart all', and the IOP is no longer breathing, and the error message has changed to 0xbad. The sync source is still 1pps.
Moral of the story: c1iscex is still down, but temporarily showed signs of life that we wanted to record.
There's definitely a timing issue with this machine. I looked at it a bit yesterday. I'll try to get to it by the end of the week.
There is definitely a timing distribution malfunction at the c1iscex IO chassis. There is no timing link between the "Master Timer Sequencer D050239" at the 1X6 and the c1iscex IO chassis. Link lights at both ends are dead. No timing, no running models.
It does not appear to be a problem with the Master Timer Sequencer. I moved the c1iscey link to the J15 port on the sequencer and it worked fine. This means its either a problem with the fiber or the timing card in the IO chassis. The IO timing card is powered and does have what appear to be normal status lights on (except for the fiber link lights). It's getting what I think is the nominal 4V power. The connection to the IO chassis backplane board look ok. So maybe it's just a dead fiber issue?
I do not know what could have been the problem with c1auxex, or if it's related to the fast timing issue.
I just got over here from Downs, where I managed to convince Todd to let me borrow one of their three remaining timing slave boards for c1iscex. I walked down to the X end to replace the board only to discover that the link light on the existing timing board was back! c1iscex was not responding, so I hard rebooted the machine, and everything came up rosy (all green!):
To repeat, I DID NOTHING. The thing was working when I got here. I have no idea when it came back, or how, but it's at least working for the moment. I re-enabled the watchdog for ETMX SUS and it's now damped normally.
I'm going to hold on to the timing card for a couple of days, in case the failure comes back, but we'll need to return it to Downs soon, and probably think about getting some spare backups from Columbia.
Steve was trying to do something to it this morning, but I'm not exactly clear on what it was. Maybe that helped? Steve, can you tell us what you were trying to do this morning?
I was trying to repeat elog 9007 I did only get to line 2 of the Solution by Koji when Ottavia shut down, where I was working. This was all what I did.
I tried all versions of power cycling and debugging this problem known to me, including those suggested in this thread and from a more recent time. I am leaving things as it for the night, will look into this more tomorrow. I've also shutdown the ETMX watchdog for the time being. Looks like this has been down since 24Jun 8am UTC.
I tried a couple of things, but no fundamental improvement of the missing LED light on the timing board.
- The power supply cable to the timing board at c1iscex indicated +12.3V
- I swapped the timing fiber to the new one (orange) in the digital cabinet. It didn't help.
- I swapped the opto-electronic I/F for the timing fiber with the Y-end one. The X-end one worked at Y-end, and Y-end one didn't work at X-end.
- I suspected the timing board itself -> I brought a "spare" timing board from the digital cabinet and tried to swap the board. This didn't help.
- Bring the X-end fiber to C1SUS or C1IOO to see if the fiber is OK or not.
- We checked the opto-electronic I/F is OK
- Try to swap the IO chassis with the Y-end one.
- If this helps, swap the timing board only to see this is the problem or not.
There were a few more flaky things in the Expansion chassis - the IDE connectors don't have "keys" that fix the orientation they should go in, and the whole timing card assembly is kind of difficult and not exactly secure. But for now, things are back to normal it seems.
Steve and I inadvertently discovered that the c1iscey IO chassis doesn't have brackets to secure the cards where the ADC/DAC cables are connected, making them very easy to knock loose. All other IO chassis have these brackets. Pictures of c1iscey and c1lsc IO chassis to compare:
Brackets for the c1iscey IO chassis cards have been installed. Now, I can't unseat the cards by wiggling the ADC or DAC cable.
We found that both of the c1iscey models (c1x05 and c1scy) were unresponsive, and weren't coming back up even after reboot. We then found that the c1iscey IOchassis was actually powered off. Steve's accepts some sort of responsibility, since he was monkeying around down there for some reason. After powerup and reboot, everything is running again.
while I was not doing anything on the machine.
This morning the LSC scripts wheren't running properly. I had to reboot c1iscey, c1iscex, c1lsc, c1asc .
I burtrestored to Monday January 25 at 12:00.
The tip-tile SOS dewhite/AI boards are now connected to the digital system.
I put together a chassis for one of our space DAC -> IDC interface boards (maybe our last?). A new SCSI cable now runs from DAC0 in the c1lsc IO chassis in 1Y3, to the DAC interface chassis in 1Y2.
Two homemade ribbon cables go directly from the IDC outputs of the interface chassis to the 66 pin connectors on the backplane of the Eurocrate. They do not go through the cross-connects, cause cross-connects are stupid. They go to directly to the lower connectors for slots 1 and 3, which are the slots for the SOS DW/AI boards. I had to custom make these cables, or course, and it was only slightly tricky to get the correct pins to line up. I should probably document the cable pin outs.
As reported in a previous log in this thread, I added control logic to the c1ass front-end model for the tip-tilts. I extended it to include TT_CONTROL (model part) for TT3 and TT4 as well, so we're now using all channels of DAC0 in c1lsc for TT control.
I tested all channels by stepping through values in EPICS and reading the monitor and SMA outputs of the DW/AI boards. The channels all line up correctly. A full 32k count output of a DAC channel results in 10V output of the DW/AI boards. All channels checked out, with a full +-10V swing on their output with a full +-32k count swing of the DAC outputs.
We're using SN 1 and 2 of the SOS DW/AI boards (seriously!)
The output channels look ok, and not too noisy.
Tomorrow I'll get new SMA cables to connect the DW/AI outputs to the coil driver boards, and I'll start testing the coil driver outputs.
As a reminder: https://wiki-40m.ligo.caltech.edu/Suspensions/Tip_Tilts_IO
Tomorrow I'll get new SMA cables to connect the DW/AI outputs to the coil driver boards, and I'll start testing the coil driver outputs.
I've found a nice 16 twisted pair cable ~25m long and decided to use it as a port from 1Y3 to clean room cable instead of buying a new long one. I've added a break out board to the coil driver end to monitor outputs.
Full cable path from coil driver to osem input is now ready. I've tested Ch1-4 of the left AI and left coil driver. 15 pin outputs and monitors show voltage that we expect. I've checked voltage on the other side of the cable in the clean room, it is correct. We are ready to test the coils. We need to bake osem cables asap. Hopefully, Bob will start this job tomorrow.
c1lsc FE is up and running.
2) The machine was manually rebooted.
3) c1daf was recompiled and installed, with the problematic piece of code removed.
4) NTP timing was adjusted.
5) Frame Builder was restarted.
6) All models on c1lsc machine were restarted.
Attachment 1 shows the CDS status after the recovery. I wont be trying to run frequency warping immediately, I will first finish implementing the other harmless modules first.
Today, at around 10:30, c1lsc machine froze and stopped responding to ping and ssh after I compiled and restarted c1daf. I think it is due to a large array in one of my codes. The daqd.log file shows the following:
Warning: "Virtual circuit unresponsive"
Source File: ../tcpiiu.cpp line 945
Current Time: Thu Jul 14 2016 22:27:42.102649102
I think the c1lsc FE may need a hard reboot.
c1lsc is up and running, Eric did a manual reboot today.
Warning: "Virtual circuit unresponsive"
Source File: ../tcpiiu.cpp line 945
Current Time: Thu Jul 14 2016 22:27:42.102649102
c1lsc and c1sus are still down. Only ETMX and ETMY are damped
[Mirko / Jenne / Kiwamu]
Just a quick update. All the realtime processes on the c1lsc and c1sus machine didn't run at all.
Somehow the c1xxxfe.ko kernel module, where xxx is x04, x02, lsc, ass, sus, mcs, pem and rfm failed to be insmod.
The timing indicators on the c1lsc and c1sus machine are saying NO SYNC.
- According to log files (target/c1lsc/logs/log.txt)
insmod: error inserting '/opt/rtcds/caltech/c1/target/c1lsc/bin/c1lscfe.ko': -1 Unknown symbol in module
- dmesg on c1lsc (c1sus also dumps the same error message):
[ 45.831507] DXH Adapter 0 : sci_map_segment - Failed to map segment - error=0x40000d01
[ 45.833006] c1x04: DIS segment mapping status 1073745153
DXH dapter is a part of the Dolphine connections.
When a realtime codes is waking up, the code checks the Dolphin connections.
The checking procedure is defined by dolphin.c (/src/fe/doplhin.c).
According to a printk sentence in dolphin.c the second error message listed above will return status "0" if everything is fine.
The first error above is an error vector from a special dolphin's function called sci_map_segment, which is called in dolphin.c.
So something failed in this sci_map_segment function and is preventing the realtime code from waking up.
Note that sci_map_segment is defined in genif.h and genif.c which reside in /opt/srcdis/src/IRM_DSX/drv/src.
[Jenne, Mirko, Kiwamu, Koji, and Jamie by phone]
We just got off the phone with Jamie. In addition to all the stuff that Kiwamu mentioned, Mirko reverted the c1oaf model and C-code to stuff that was working successfully on Friday (using "svn export, rev # 1134) since that's what we were working on when all hell broke loose.
We did a few rounds of "sudo shutdown -h now" on c1lsc and c1sus machines, and pulled the power cords out.
We also switched the c1ioo and c1lsc 1PPS fibers in the fanout chassis, to see if that would fix the problem. Nope. c1ioo is still fine, and c1lsc is still not fine.
Still getting "No Sync".
We're going to call in Alex in the morning, if we can't figure it out soon.
Alex fixed the computers this morning. It was in fact a dolphin problem:
Hi Jenne, figured it out. Even though dxadmin said the Dolphin net was fine, it wasn't. Something happeneed to DIS networkmanager and I had to restart it. It is running on fb:
controls@fb ~ $ ps -e | grep dis 12280 ? 00:00:00 dis_networkmgr
controls@fb ~ $ sudo /etc/init.d/dis_networkmgr restart
Once the restart was done both c1lsc and c1sus nodes were configured correctly, they printed the usual "node 12 is OK" "node 8 is OK" messages into the dmesg and was able to run /etc/start_fes.sh on lsc and sus to load all the FEs. Alex
Some lights on c1lsc were still red: C1:DAQ-FBO_C1SYS_SYS and the smaller red light left of it. Restarted the fb. Didn't help. Restarted c1lsc, all green now.
Restored autoburt from Oct 3. 19:07 on c1lsc and c1sus.
This is my third time to crash a real-time machine. This time I crashed c1lsc.
I physically rebooted c1lsc machine by pushing the power button and it came back and now running fine.
(what I did)
The story is almost the same as the last two times (1st time, 2nd time).
I edited c1lsc.ini file using daqconfig and then shutdown daqd running fb.
Some indicators for c1lsc on the C1_FE_STATUS screen became red. So I hit the 'DAQ reload' button on the C1LSC_GDS_TP screen.
Then c1lsc died and didn't respond to ping.