BICEP PMAC Logbook

16-Feb-2009, Setting up new PMAC for optical test mount:

PMAC1, TURBO PMAC PCI, SN C0004QF4 Jumpers: HRM p 15 - 29 records defaults. Compared every jumper on board XXX main and CPU boards with default settings and notes on changes as recorded in BICEP1 paper copy of PMAC HRM. Made the following changes: 

E85,E87,E88: removed all three jumpers to allow analog +/-15VDC and ground to come in externally.
             According to the HRM this is the default, but the board came with these installed
E90: jumper pins 1-2
E98: moved jumper to pins 2-3 to provide 1.22 MHz DCLK for high accuracy A/D on ACC-28.
E111: jumped pins 2-3 to disable phase, servo, init on J4.  HRM says default is pins 1-2.
E121: removed jumper
E122: removed jumper


ACC-51P, SN C0002TFN
all jumpers confirmed to be default.  Left S1 dipswitches at default: 1-on, 2-off, 3-off, 4-off.
This appears to be for non-Turbo, but let's try it.

15-Jan-2007, AZ tuning at Pole:

Trying to understand the pattern of dependence of thermistor stability (rtc 47) on AZ-scan speed that was documented in http://bicep.southpole.usap.gov/analysis_logbook_north/20070103_stability/ To summarize those results, (1-9, 9 is worst): 

 date   config         ramp1p8  ramp2p0  ramp2p2  ramp2p4  ramp2p6  ramp2p8  ramp3p0  ramp3p2
 11-04  winter 06      3        9        2        3        9        3        4        6
 12-16  p.serv, bad dk 2        9        2        6        3        2        8        3
 12-18  corrected dk   4        8        4        5        4        7        6        4
 12-23  new PID        1        8        1        3        3        3        3        2
 12-24  new PID        1        9        2        3        3        3        6        3

These results are confusing. I observe that at lower scan rates, especially 1.8 and 2.0 d/s, there is a substantial oscillation in AZ velocity pmac.fast_mtr_vel[0]. Could this be the cause of the dependence of thermal instabilities on AZ scan rate? 

Here is the existing tuning:
;s-curve-t  prop.gain   derivative  vel.ff      integral  accel.ff    low pass   fric.ff
i121=1000  i130=2000   i131=15000  i132=9000  i133=30000 i135=140000 i138=-0.85 i168=150 ; 24 aug 2005, smoother az scans

Here is a tuning that smoothes these oscillations:
i121=1000  i130=2000   i131=4000   i132=9000  i133=30000 i135=140000 i138=-0.70 i168=150 ;  2007, smoother az scans
Repeated an AZ stability schedule using this AZ tuning and the new temperature control PID: 
  http://robi/analysis_logbook_south/20070116_az_stability/20070115_az_stability_nopoly.pdf
Not a dramatic difference, 2p0 is still bad and 2p2 still good. Still, if we are going to go with 2p2, I want to kill these oscillations. 5-Feb-2007, Tuning up pmac program at Pole: Replaced the DK coupling today with a stiffer, stainless steel version. Re-aligned DK drive shaft in process (it was off by 0.2 in., not too bad). No explanation for why we saw a 5.0 degree shift in position of DK=0 sometime between Jan 4 and 6. I reset the DK encoder zero in pointing.init: 
#encoder_zeros  -322.79, -82.398, +56.5083  # 2006-12-20 (2007 mark on DK gear & motor)
# note: between Jan 4-6 until Feb 5, DK was somehow shifted by +5.0 degrees (DK=-5.0 to align marks)
encoder_zeros  -322.79, -82.398, -0.930    # 2007-02-05 (after DK coupling replacement, re-aligned 2007 mark on DK gear & motor)

Using bicepPmacterm command 

PMAC:> list prog 1
I verified that the motion program we have been running is pmac_mainprog1_pt.pmc. Combined this and pmac_setup_060627.pmc into pmac_code_bicep_060627.pmc, which reproduces the PMAC state that we ran on BICEP from 06/2006 to 02/2007.

Made these changes, saved in new pmac_code_bicep.pmc, now called v1.01: