Servo Progress Report

December 15, 2006

 

D. Clark, T. Trebisky

 

 

Dates covered: 12/7 through 12/13/2006

 

 

Activity Summary

 

In order to confirm the results obtained in October, 2006 that indicated a change in the open-loop response of the MMT elevation axis, Trebisky and Clark collected more open-loop data on the telescope on December 9, 2006.  While at the site, Trebisky received training on the connecting the hardware, generating the real-time code using Matlab/Simulink to the xPC Target kernel running on the test PC, and collection of data. The data were then reduced offline by Clark to Bode plots that represent the open-loop elevation axis response to a chirp signal input driving current-source motor amplifiers. Detailed discussion of the results follows below. The data do not appear to agree with that taken in October, while the recent open-loop response seems to have good general agreement with data taken with the f/9 secondary in 2004 and 2005.

 

Activity Details

 

Before the system is changed over to test mode, it is necessary to move the telescope to a safe elevation angle to ensure that out-of-balance or other runaway conditions may be successfully stopped without damage to the telescope or endangering personnel.

 

Next, in order to change the telescope drive hardware over to the test mode, it is necessary to make several changes to the drive system:

 

1.      Connect the motor cables to linear current-source amplifiers from the existing voltage-source PWM amplifiers.

2.      Connect the 208VAC 3-phase power plug to a “splitter” box that re-routes the AC power for the amplifiers to the two alternate amplifier units as two 120VAC circuits.

3.      Install 2 Heidenhain EXE650B encoder interpolators to bring the two tape encoder heads up to 50X interpolation from the existing 25X EXE702 units. A cable must be borrowed from one of the two rotator head interpolators, as only one spare cable for this type of interpolator box exists. The cables between EXE702s and EXE602/650 units are not interchangeable, as the 702 units have internal 5VDC power supplies, while the others get power from a separate supply attached to the mount interface chassis.

4.      Next, detach the ribbon cables that are on the elevation encoder opto-coupler board and the elevation IP-Servo interface board in the front of the mount interface chassis, and connect them to the re-mapping boards on the xPC Target hardware interface panel.

5.      Power up the xPC Target machine, ensuring that the power cord for the xPC interface panel is also plugged in, and that it has a connected network cable.

 

Now it is time to set up things to enable open-loop testing software. A special switch box exists that allows the amplifiers and brakes to be manually powered up and released. It bypasses all the interlock safety chain items except for emergency stops. When using this method, people must be present in the chamber to ensure the telescope does not endanger personnel or telescope hardware. This procedure is potentially extremely hazardous to both.

 

 Generally, a laptop PC with Ethernet connection is used to communicate with the xPC Target test PC in the drive room for data collection and interacting in various ways with the real-time code in the machine (i.e. starting/stopping execution, adjusting parameters, or checking status).

 

Using a pre-constructed open-loop Simulink block diagram, Real-time Workshop is then used to generate and download the real-time test code to the xPC Target machine over the network.  A web-browser view of the open-loop test software that is generated into real-time code is available at:

http://www.mmto.org/~dclark/Reports/MMT_el_openloop_run6_slwebview.html

 

In this diagram, the yellow blocks represent custom hardware i/o drivers written using the Simulink S-function and xPC Target kernel libraries to support the available hardware on the test PC.  Real-time Workshop automatically generates all the source code from the block diagram, compiles it into a complete executable, and downloads the code to the xPC Target machine over the network. The numbered output ports on the block diagram become logging buffer data points in the target machine’s memory. All data is logged as double-precision values into an m-by-n matrix, where m is the number of sample ticks in the real-time code, and n is the number of signal logging points in the Simulink block diagram.

 

Once the real-time code is downloaded and running on the target machine, the next crucial step is to precisely balance the telescope, since it needs to stay in position for as long as 10 minutes with both cell and motor brakes released.  We balanced it as well as possible before the cable switchover described above, then fine tuned the balance while in the actual test configuration to ensure that the average motion while the input chirp signal is applied tends to be zero.

 

The data collection process then uses a chirp function via a custom-written S-function  to sweep a sinusoidal excitation into the elevation drive motors while storing the encoder outputs from the absolute and both tape encoders.  User-adjustable parameters allow the starting frequency, ending frequency, number of cycles per frequency, and frequency step size to be varied in the generated code.

For this set of tests, the frequency range was 0.25 to 30Hz, and we collected either 6 or 8 complete cycles of each frequency in the data buffer. Increasing the number of cycles per frequency or decreasing the step size increases the overall frequency-space resolution of the test data.  For all tests, both of us were present while the test was underway to preclude any dangerous excursions of the telescope.

 

In this manner, we collected 4 total runs of data with either 0.1 or 0.05Hz step sizes, with 6 or 8 cycles per frequency. The highest-resolution data set is then used as a check on the faster, lower-resolution runs to ensure that we completely capture the modal response of the telescope.

 

Data Collection Results

 

This data collected is used to prepare Bode plots depicting the open-loop response over frequency of the telescope, which then can be numerically reduced to a “black box” with the same frequency response and used to drive controller design in simulation space. With a “block box” model of sufficient accuracy, predicting the actual response of the telescope to controller inputs in a closed-loop form becomes a straightforward exercise in Simulink, and gives confidence in the controller design before applying it to real-world hardware.

 

The measured data are then reduced using the Matlab tfestimate routine, which performs the numerical computations necessary to convolve the input and output signals and produce a complex number array output that represents the magnitude and phase of the input/output signal pair over the interval 0 to Fs/2, or the Nyquist frequency limit. We necessary constrain this output to the actual frequencies of the chirp signal block, since the correlation between the input signal and output should be high to have confidence in the numerical results; uncorrelated data should be treated as suspect (i.e. due to nonlinear or transient effects). A copy of the reduction script and comparative plots showing the October, December, and older results from 2005 can be found at: http://www.mmto.org/~dclark/Reports/reduce3.html for those interested.

 

It is clear in the data plots, the October data appear to be fishy, to say the least. The two items of most concern are that first, the two drive arc encoder outputs are not in agreement in the October data, while they do agree in the December run. Indeed, they closely agree with 2005 data taken when f/5 Hectochelle was installed on the telescope – a completely different setup from December, when f/9 with Blue Channel Spectrograph was the telescope configuration. The second is that the phase of the two drive arc encoders in the December data diverges at  ~11Hz , when at lower frequencies they were in phase. This implies differential motion of the two drive arcs, something that is hard to credit given the history of prior data collection runs. This divergence in the data requires more investigation.

 

Next Steps

 

Activities to be pursued before the next servo group meeting:

 

1. Purchase additional Matlab blocks to allow us to generate state space models given measured transfer functions, and to bring Tom's Matlab resources up to what is required to do this.

 

2. Rework the velocity estimator block, which currently injects high frequency noise.

 

3. Explore parameter tuning on the downtown VxWorks simulator.

 

4. Return to mountain and test controller with f/9 and be ready to experiment with parameter tuning.

 

5. Build an archive of software and documents relating to this servo project.

 

6. Mine old data files to determine if any data from the past sheds light on the current inconsistent open-loop data reduction results.