Jim Harwood
August 29, 1995
An infinitely accurate time source, derived from a GPS receiver, is being used to control the IC position update algorithm so that perfect tracking will occur on the celestial sphere. However, PMAC contains a timing clock that is quite accurate but not the same as the one driving the IC software, with the result that phase slip occurs between the two computers.
It would be nice if there were a BNC connecter on PMAC that accepted a power of ten external clock frequency to which the internal clock would be slaved. Unfortunately, it doesn't work that way. The closest thing to a simple connection accepts the "phase" clock signal from another PMAC so two or more PMACs can be slaved together. The phase clock frequency that PMAC uses, 9.035294 Khz, is of course not available from our infinitely accurate time source nor is easily derived from it.
Instead, PMAC provides the ability to input an external clock frequency into a particular encoder input. A custom entry in the encoder conversion table then processes this input so that all timed actions in PMAC use this timing source rather than the locally generated default time source. When picking the external frequency, one also has to choose a particular scale factor to keep the timing at the "real time" scale. If we use a 1 Khz external clock frequency, the scale factor turns out to be exactly 131,072 (explained below), and the synchronization of PMAC's operations to an external timing source is doable in our application.
The information on providing an external frequency source is in a number of different places in the manual, primarily on pages 3-35 to 3-45, 3-171 to 3-178, 5-66 (Ix93), and 8-6.
PMAC's operating system carries an encoder conversion table which is processed every servo cycle (1/4 the phase fequency, or 2.25 Khz). This table contains information on the encoders in use and is processed to provide in memory the current position of the associated motors.
The encoder conversion table also contains fixed locations used to service an external clock, if present. In the table we specify the encoder input at which the external clock is connected, the source address of the associated counter, and the scale factor relating to the external frequency. Certain I-variables need to be set. Once this is all in place, the operating system uses the timing derived from the external source to time all functions (except for DWELL).
The way it works, at each servo cycle the system saves the previous value of the counter that is counting the external pulse train and updates the counter to the new value for this cycle. The counter is maintained to five fractional bits by the 1/T smoothing that PMAC can provide to digital encoder inputs. The previous value of the counter is subtracted from the current value to produce a final elapsed time interval for this cycle. An I-variable (I193) points to this result location in the encoder conversion table, which provides the source of time interval for all operations.
If we want to go back to internal timing, we simply restore I-variable I193 to its default value of $0806. No hardware disconnection is necessary.
Interconnect the GPS receiver with the Odetics TPRO frequency generator so that the signal from the TPRO is slaved in phase with the GPS. On the TPRO, jumper the terminal strip pin P13-6 (1 Khz) to P13-10 (Rate 1). Connect TPRO output pin J1-10 (Select rate 1) to PMAC P2 JMACH1 connector, pin A07. This is Encoder #4, channel A. Leave the channel B line floating (manual, P.5-70) since this is a non-differential signal. PMAC jumper E24 specifies non-differential as factory default for Encoder #4.
Set variable I915 to either 0 or 4, depending on whether the clock signals are counting up or down. They are to count up, of course, unless someone figures out how to go backwards in time. This I-variable defines the decode control for Encoder #4. The address of the external clock's counter (nominally Encoder #4's counter) is X:$0723. Set up an M-variable to point to this, and make sure it is counting up when the external 1 Khz clock is connected and ticking; otherwise, use the alternate value for I915.
The encoder conversion table occupies both X and Y memory banks. Setup data is in the Y bank, and the results of the table processing are placed in the X bank. Except for a scaling factor in encoder table location Y:$729, the default table values are exactly what we need. For clarity, I am detailing here how they are derived.
To set up an external clock source, we utilize two items in the encoder conversion table; the table entry for Encoder 4 and the table entry reserved to handle external clocking.
The table address for Encoder 4 starts at Y:$723. For bits 16-23 of this location we use the number $00, which specifies 1/T interpolation of the 1 Khz signal and provides an additional 5 fractional bits. Bits 0-15 of this word contains the hardware address of the encoder 4 counter, $C00C. Thus, the encoder table address Y:$723 is set to $00C00C. The result of the encoder table processing will be placed in X:$723, which will be the smoothed "encoder" count (actually external frequency pulse count) for this servo cycle.
The encoder conversion table has two addresses reserved specifically for use if an external clock is tied in to encoder #4's input. The address Y:$728 is loaded with the high order hex byte $40, which specifies time base rather than real encoder operation. The lower 16 bits contain the source of the time counter, which is the result of the previous operation descussed above, at address X:$0723. Thus, the data in word Y:$728 is set to $400723.
Finally, location Y:$729 is to contain a scale factor for scaling the 1 Khz frequency to that required for the real-time (or other timing) time base. The scale factor is 131,072 (explained below). This is the only value in the encoder conversion table that is not default and will have to be explicity set. The final result of the encoder table processing of the external time base will be in X:$729, which will be used internally by PMAC for all motions.
In order for PMAC's time base to be real-time rather than proportional to real-time, the scale factor we need to put in register Y:$729 in the encoder conversion table is equal to the number 131,072 (= 2**17) divided by the input frequency in cycles per millisecond. The resulting scale factor must be an integer. This constraint means that the input frequency must be a power of two or there will be a fractional remainder to the scale factor, which when truncated ruins our time base accuracy. However, the TPRO frequency generator only puts out frequencies that are powers of 10. The number 1 as a divisor satisfies both constraints. One cycle per millisecond corresponds to an input frequency of a Khz, easily provided by the TPRO, which gives us the integer 131,072 ($20000) as our scale factor, for perfect synchronicity with the IC "tservo" interrupt cycle.
We store $20000 in register Y:$0729 as the only change we need to make to the encoder conversion table, as long as we use the Encoder #4 input as our source of external time base frequency.
I am a little concerned that the 1 Khz input frequency is the same order of magnitude as the servo update frequency (2.25 Khz). Each servo cycle, only a fraction of an input timing pulse will be seen. The precision of timing the elapsed interval will be only 4 or 5 binary places. However, using such a small frequency is perfectly legal, though is probably the minimum possible, and the time base should average over time to the expected value.
The system knows that we are applying an external time base if we set the variable I193 to point to the address of the final result in the encoder table of processing the external frequency input, which is in X:$729. The fact that this is the X-bank is already known to the system, so we just store $0729 into I193. The external time base will then apply to all motions in Coordinate System #1.
If we need to switch back to the internal time base, we merely restore I193 to its default value of $0806. There is no need to disconnect the wire coming from the TPRO.