Rana theorized that we're having problems with the MC error signal in the OAF model (separate elog by Den to follow) because we've named a channel "C1:IOO-MC_F", and such a channel already used to exist. So, Rana and I went out to do some brief cable tracing.
MC Servo Board has 3 outputs that are interesting: "DAQ OUT" which is a 4-pin LEMO, "SERVO OUT" which is a 2-pin LEMO, and "OUT1", which is a BNC->2pin LEMO right now.
DAQ OUT should have the actal MC_F signal, which goes through to the laser's PZT. This is the signal that we want to be using for the OAF model.
SERVO OUT should be a copy of this actual MC_F signal going to the laser's PZT. This is also acceptable for use with the OAF model.
OUT1 is a monitor of the slow(er) MC_L signal, which used to be fed back to the MC2 suspension. We want to keep this naming convention, in case we ever decide to go back and feed back to the suspensions for freq. stabilization.
Right now, OUT1 is going to the first channel of ADC0 on c1ioo. SERVOout is going to the 7th channel on ADC0. DAQout is going to the ~12th channel of ADC1 on c1ioo. OUT1 and SERVOout both go to the 2-pin LEMO whitening board, which goes to some new aLIGO-style ADC breakout boards with ribbon cables, which then goes to ADC0. DAQout goes to the 4pin LEMO ADC breakout, (J7 connector) which then directly goes to ADC1 on c1ioo.
So, to sum up, OUT1 should be "adc0_0" in the simulink model, SERVOout should be "adc0_6" on the simulink model, and DAQout should be "adc1_12" (or something....I always get mixed up with the channel counting on 4pin ADC breakout / AA boards).
In the current simulink setup, OUT1 (adc0_0) is given the channel name C1:IOO-MC_F, and is fed to the OAF model. We need to change it to C1:IOO-MC_L to be consistent with the old regime.
In the current simulink setup, SERVOout (adc0_6) is given the channel name C1:IOO-MC_SERVO. It should be called C1:IOO-MC_F, and should go to the OAF model.
In the current simulink setup,DAQout (~adc1_12) doesn't go anywhere. It's completely not in the system. Since the cable in the back of this AA / ADC breakout board box goes directly to the c1ioo I/O chassis, I don't think we have a degenerate MC_F naming situation. We've incorrectly labeled MC_L as MC_F, but we don't currently have 2 signals both called MC_F.
Okay, that doesn't explain precisely why we see funny business with the OAF model's version of MCL, but I think it goes in the direction of ruling out a degenerate MC_F name.
Problem: If you look at the screen cap, both simulink models are running on the same computer (c1ioo), so when they both refer to ADC0, they're really referring to the same physical card. Both of these models have adc0_6 defined, but they're defined as completely different things. Since we can trace / see the cable going from the MC Servo Board to the whitening card, I think the MC_SERVO definition is correct. Which means that this Green_PH_ADC is not really what it claims to be. I'm not sure what this channel is used for, but I think we should be very cautious and look into this before doing any more green locking. It would be dumb to fail because we're using the wrong signals.