Notes on the Sidtech Controller ============================== Sidereal Technologies Controller has two PWM motor controls and four encoder counters. The velocity and position used for motion control are derived from the encoder attached to the motor. The secondary encoders, from a Renishaw encoder on each axis of the Planewave A200HR mount, is tracked and available through the interface, but does not have a role in the internal feedback. Consequently, this controller does not take full advantage of the precision encoder. Precision position and guiding is possible when an external program such as "tel" or "xmtel1" monitors the prescision encoder and provides the feedback to the system. For this reason we provide software to use the Galil Motion Controller instead. The Galil controller has 4 axes, allowing RA, Dec, focus and rotation to be managed in the same system. It incorporates the precision mount encoder in its PWM position feedback. The cost of the Galil controller is approximately 2000 USD (in 2011). Apparent disadvantages to the Sidtech approach are: *The freedom from backlash inherent in precision encoders on the mount axes is lost when positioning is done through the motor encoder reading. An external loop is required for precision closure of a pointing request. *A constant "chat" has to take place between the Sidtech Control and the computer. To be effective, this communication should read the encoders at rates faster than 15 arcsec/sec divided by half the angular resolution of the telescope. For a 20-inch telescope with 0.2 arcsec resolution, the motion should be sampled fast enough to hold 0.1 arcsec, which requires 15/0.1 or 150 Hz. This is far faster than the Sidtech controller can manage, a rate probably closer to 15 Hz, e.g. intrinsically limited to 1 arcsec error. *The operation of the mount has to have its own processor thread for this to work well, and should be running in background as a separate process if the computer is also handling other tasks. A better approach given that microcontrollers can handle this feedback well, would be to have the motor control actually use the precision encoder. In XmTel we use the Sidtech controller by ignoring the precision encoder for conventional position and free-run tracking. The precision encoder is read to close the positioning loop in XmTel on a 4 Hz polling cycle. Within the poll loop we test (hopefully with time resolution better than 1/15 second) whether the encoders are reading what they are expected to read. Telescope slews are based on the motor encoder. The user sees the precision encoder readout, but the motor sees the motor encoder requests. During the polling loop when a slew is not in progress xmtel will try to change the rates in all axes to null the difference between the sky position and the precision encoder reading, and thus bring the system to the target. For example, to slew to a target in xmtel is normally a four-step approach: 1. Load the target field RA/Dec 2. Compute the telescope motor encoder coordinates of the target 3. Issue a "Go to" for the motors to acquire the target on a preferred trajectory 4. Wait for the motor controller "Go to" to complete With the precision encoder managed externally, we have 5. Calculate the pointing based on the current precision encoder reading 6. Calculate an offset to the motor encoder to make its position agree with the mount encoder 6. Compute the telescope motor encoder coordinates to nudge the telescope to the target position as read by the precision encoder 7. Repeat steps 5 and 6 as needed to achieve the desired pointing Step 7 should be within the desired subarcsecond guide error, but probably will not be since the errors in the motor encoder are changing as we seek closure. We exit the go to process with RA/Dec motor encoder offsets that make the two encoder systems agree. These offsets are constantly updated when the encoders are read, and are used in step 2 of any slew request. To achieve precision guiding, XmTel must compare the precision mount encoder reading with the desired center-of-field pointing and issue (small) corrections to maintain that pointing. At the same time, it must update the differential offsets of the motor and mount encoder systems. Guiding in this mode is done by issuing small changes in the RA motor speed during the polling cycle of tel of xmtel1. Since the A200HR precision declination encoder is not used by the Sidtech motion controller for pointing, we cannot guide with precision in declination if the direction of declination drift changes because of backlash. It may be necessary to turn off declination guiding because of this shortcoming. For debugging use putty, connect to /dev/ttyUSB0 at 19200 BAUD, enter "XV" and return. System will respond with V85. Serlial line to connect to /dev/ttyUSB0 Speed 19200 Data bits 8 Stop bits 1 Parity none Flow XON/XOFF The motor encoders are Motor: Pittman GM9236S021 Motor encoder: 500 cpr Motor encoder multiplier: 4 Motor gearbox: 19.7:1 Motor cog belt: 2:1 Mount worm gear: 360:1 The combined factors are 500 x 19.7 x 2 x 360 = 28,368,000 counts per turn, The scale is 28,368,000/360 = 78800 counts per degree. This is not exact, since the 19.7:1 ratio is only approximate. Planewave says that the correct count is 78632.47778 counts/degree or 28,307,692 counts per turn. The mount encoder is Renishaw tape on a 10-inch stainless ring. It is similar to this stock encoder: Encoder: Renishaw RESM Diameter: 255 mm Reseau: 40 microns exactly Counts: 40000 full turn exactly Signum multiplier: 400x interpolator Effective reseau: 0.1 micron or 100 nm The total number of counts per turn would be 40000 x 400 = 16,000,000. The scale is 16,000,000/360 = 44444.444444 ... counts per degree. In practice the scale is different for each encoder instance since it depends on the ring and the tape. Factors are given by Planewave, and can also be derived by fitting the readings from the motor and mount encoders. For our mount we find: RA counts/deegree: 39880.8000 Dec counts/degree: 39885.7450 The Sidtech controller does not set the mount encoder count in response to the documented command. The effect is that encoders on both axes reset to zero on power up, but keep their values otherwise. The protocol given here reads the mount encoders and sets the motor encoders to match. This allows the software to restart without affecting the operation. Go To ----- The "goto" commands are sprintf(slewcmd,"Y%dS%d\r",gotoazmcount,gotorate); and sprintf(slewcmd,"X%dS%d\r",gotoaltcount,gotorate); for RA and Declination respectively. Once these commands are issued, the mount controller takes over and sends the telescope to the destination at the chosen speed. There appears to be no reliable built-in function that says if the mount is slewing. The binary read function is supposed to return a motor state bit, but that does not seem to indicate motion in progress. Also the controller does not reliably return coordinates with the motor is running at slewing speeds. Thus we cannot read the location on the fly, and we cannot tell with a single read whether motion is on going. In the protocol the work around is to make two measurements of position and see if they differ in order to trap a motion condition. This seems to be very reliable since if the mount is moving and the coordinates read correctly motion will show has a coordinate change, and if it reads incorrectly it will show as a random change. An additional complication is that the first go to completed may stop the second one. This would seem to be a bug in the firmware. The work around is to make repeated go to requests until the target is reached, or give up after a preset number of attempts.