a200hr.txt August 27, 2011 =============== This file contains working notes on the A200HR mount with the supplied Sidereal Technology controller. The following details and comments are edited from help provided by Dan Gray on May 25, 2011. They may be superceded by information on his website, but they provided the framework for the driver we have in xmtel. ================================================================================ Here's a code snippet to move the motors at various rates: internal static double DegsPerSec2MotorSpeed(double dps, double TicksPerRev) { return Math.Round(TicksPerRev * dps * 0.09321272116971); } internal static double MotorSpeed2DegsPerSec(double Speed, double TicksPerRev) { if (TicksPerRev == 0.0) TicksPerRev= 1.0; return Speed/TicksPerRev*10.7281494140625; } internal const double SiderealConstant = 0.00038942519; internal static double TicksPerRev2SiderealRate(double TicksPerRev) { return Math.Round(TicksPerRev * SiderealConstant); } The nice thing about the scope encoder is that the serial port routine in the controller takes a "snapshot" of all 4 encoders, at a single moment, so the information you have with the binary protocol is for a single moment in time. You have to do whatever you need to do to cascade the motor location to make the scope encoder location accurate. The documents for the hardware limit switches are not finished yet. The wiring is obvious, so shouldn't be a problem. There area also software limits in the planewave and sitech software, such as altitude limit, and GEM gem flip window, etc. There are lots of defaults, you can really screw things up in the parameters of the controller. How badly do you want it not to work? We can make it do that! Best to make a backup of the parameters. SiTech ASCII command set ***************************************************************************** ***************************************************************************** ***************************************************************************** About the new ASCII CS (ACS) Mode: The SiTech ascii command set has a lot of commands that can be typed in from a terminal program. But this was problematic when communications were not very good (noisy RS232 lines, etc). Sometimes when SiTechExe sent a binary command, the controller did not receive it as a binary command. Then, by chance, some of the binary data would equal an ASCII command, such as "Reset Controller", or other commands, and the controller would do unpredictable things. To solve this, I deviced an Ascii Checksum Mode (ACS). If in the ACS mode, after the in the command is sent, you send another byte, which is the 8 bit sum of all the bytes, inverted. Entering and Leaving the ACS mode: YXY0 + 184 We go out of the Ascii Checksum mode YXY1 We go into the Ascii Checksum mode YXY + 232 Returns "Y0crlf" if not in Ascii Checksum mode, and "Y1crlf" if in ascii cs mode. If controller is in the ascii CS mode, and it is receiving characters, if the character stream stops for more than 50 mSecs, the controller resets the serial stream, and the next character will be placed at the beginning of the receive buffer. If the controller is not in the ascii CS mode, you can send characters with any time spacing, and it will always respond. Example of a "YXS" command, in ACS mode: 59 58 53 D EE One more oddity.... If controller is in the ACS mode, and you want to "talk" to the focuser/rotator, then you replace the first 'X' with 'T', and the first 'Y' with 'U' (same as previously), but you calculate the checksum based on if it had been the 'X' or 'Y'. ***************************************************************************** There are two ascii commands that require binary data to follow. These are: XXR and YXR Obviously, if in the ACS mode, there would be a checksum following the The checksums in the following commands do not include the Ascii portion, or the ascii checksum (if in ACS mode) Following the ascii portion of the XXR command, is the 21 binary data as follows: 4 bytes Alt/Dec destination 4 bytes Alt/Dec Speed 4 bytes Az/RA destination 4 bytes Az/RA Speed 1 byte. bit 0 means use following xbits and ybits value, if zero, ignore. 1 byte xbits 1 byte ybits 1 byte checksum (low byte) 1 byte checksum (high byte) (inverted) Following the ascii portion of the YXR command, is the 34 binary data as follows: 4 bytes Alt/Dec destination 4 bytes Alt/Dec Speed (base rate) 4 bytes Az/RA destination 4 bytes Az/RA Speed (base rate) 4 bytes Alt/Dec Rate Adder 4 bytes Az/RA Rate Adder 4 bytes Alt/Dec Rate Adder Time (in Servo Loops (1953 would be 1 second) ) 4 bytes Az/RA Rate Adder Time (in Servo Loops (1953 would be 1 second) ) 1 byte checksum (low byte) 1 byte checksum (high byte) (inverted) The Rate Adder is added to the base rate for the number of servo loops specified. For instance if the base rate is 2000 and the rate adder is -2100, then the rate will be -100 for 66 servo loops. This in effect will change the direction of the motor for 66 servo loops. In SiTechExe, I truncate the rate adder so in never actually changes motor directions, because, if the controller has backlash enabled, it will toggle back and forth. Here's an example of what SiTechExe sends the controller for the YXR command while in the ACS mode: 59 58 52 D EF F7 25 CF FF D0 7 0 0 B CF BA 58 EB 15 0 0 0 0 0 0 16 EA FF FF 42 0 0 0 42 0 0 0 2F F5 Here's the interpretation thereof: YXR/n,AsciiCS:239,AlDst:-3201545,AlSpd:2000,AzDst:1488637707,AzSpd:5611,AlRateAdd:0,AzRateAdd:-5610,AlRateTime:66,AzRateTime:66 ***************************************************************************** ***************************************************************************** Here is the Binary Response, returned from the controller, Version 3.6C: This response is returned from all of these commands: XXS XXR YXR All Multi-bytes (Ints and Longs) are lsb first. 1 byte 0xA8 + controller address (1, 3 or 5) 4 bytes of Alt motor position 4 bytes of AZ motor position 4 bytes of Alt scope encoder position 4 bytes of Az scope encoder position 1 byte of keyboard status 1 byte for Xbits 1 byte for YBits 1 byte for various bits. //0 = X stopped (altitude) //1 = X Manual (Altitide) //2 = DigIn0 (v2.0 and later) //3 = DigIn1 (v2.0 and later) //4 = YStopped (Azimuth) //5 = Y Manual (Azimuth) //6 = Y PEC Recording //7 = Y PEC Playing 2 bytes Analog Input 1 2 bytes Analog Input 2 4 bytes millisecond clock 1 byte, temperature Deg's F (This will be changed to Alt/Dec Worm Phase eventually) 1 byte Az/RA Worm Phase 4 bytes. Alt/Dec motor location at last Alt/Dec Scope Encoder location change 4 bytes. Az/RA motor location at last Az/RA Scope Encoder location change 2 bytes for checksum The checksum is the 16 bit sum of all bytes, starting with the A8 + controller address (byte 1) The high byte of the cs is inverted. Here's a typical binary response (in hex): A9 1D 5C 0 0 5E 67 4 0 0 0 0 0 1D 19 0 0 0 60 0 80 0 0 0 0 5E 96 E 0 50 99 0 0 0 0 2D 67 4 0 84 FA Here's the same response broken down: A9 = 0xA8 + controller address Alt/Dec Motor Position 1D 5C 0 0 23581 Az/Ra Motor Position 5E 67 4 0 288606 Alt/Dec Scope Encoder Location 0 0 0 0 0 Az/RA Scope Encoder Location 1D 19 0 0 6429 Keypad Status: 0 0 XBits (XBits and YBits functions are the same as listed in ServoDoc.pdf 60 (hex) 96 (dec) YBits 0 (hex) 0 (bin) 0 (dec) 0 (oct) Various Bits (it looks like the YPEC is playing) 80 (hex) 128 (dec) Analog Input 1 0 0 Analog Input 2 0 0 Millisecond Clock 5E 96 E 0 955998 Temperature (Deg's F) (will be changed to Alt/Dec Worm Phase eventually) 50 (hex) 80 (dec) Az/RA Worm Phase (0-255) 99 153 (59.7 percent) Alt/Dec Motor Location at last Alt/Dec Scope Encoder Location Position Change 0 0 0 0 Az/RA Motor Location at last Az/Ra Scope Encoder Location Position Change 2D 67 4 0 288557 Checksum 84 FA ***************************************************************************** ***************************************************************************** *****************************************************************************