Topics

Project TinTac - a breadboard setup for testing OnStep code


jsalbinson@...
 

This may be of interest as an inspiration for a test setup for others.


From Right to left:
A Sigma Instruments (SI) series 20-size 22 early hybrid stepper (200st/rev) - Focus motor
A SI Nema34 (200 st/rev) with 11:2 antibacklash gearbox for DecTangentArm (+-20 degree movement)
A SI Nema34 with 50:1 gearbox (on 720:1 wormwheel) for RA track. About 40 halfsteps backlash.
Breadboard with LEDs for Track/Slew Clutch, NS Dec Slew, EW RA Slew.
Relay banks  for turning the slewing motors and switching the clutches.
(Slewing is by 3 phase 1/16th HP 1425rpm induction motors wired for reversible single phase; via 600:1 gearbox and 16:1 wormwheel.)
MKS Gen_L V1.0 board with 3off  8825DRV  drivers set at 1.5A, 1A, 1A,:: RA, Dec, Focus steppers - hard set for half-stepping.
Breadboard simple handset
(Note: The telescope has a moment of inertia of 1000kg-m**2, many hundreds, or a thousand times that of the general run of amateur telescopes.
Its total mass is 2 metric tons, including the RA axis and pillar).

Notes. The setup works fine for testing.
I can connect via SkyPlanetarium (Howard Dutton) + OnCue, and ASCOM (Win10-64bit, which was a bit of a bind to install!),
or by Kstars+INDI on OpenSuse-Leap15.2. Either give the same performance.
The current is insufficient to drive the steppers properly - the production version will use (much) larger drivers.
I will be breadboarding a SmartHandController, and an encoder/Ethernet box, with cheap encoders to test the principle.
(Current encoders have 65k counts/rev; future ones may go up to 250,000+ cpr)
The mechanical relays will be replaced by DC-AC SolidState Relays for the motors, and DC-DC SSRs for the Track/Slew clutches.
Arduino compatible modules are becoming available cheaply.
This will enable controllable switching of the SlewMotors on 10msec timescales (half cycle UK mains voltage).

I will be looking at the OnStep code carefully to shim the code to control the slew motors - something like:
- Computed GOTOs > 1 degree are slew, otherwise use steppers. Maybe use the 64x speed to indicate slew instead of steppers,
as the fastest step rate required is 32x sidereal (~5000 st/sec). The induction motor slew rate is 0.8 degree/sec, 200x sidereal rate,both axes.
- Slew by handset is unconditional but still bound by altitude limit (eg 10 degree)
- DecTanArm stops valid on a relative basis +- 20 degree from its zero. Not sure I fully understand the recent mods by HD in this regards - more coffee needed!
(Existing method of centering on current telescope (+- 1 degree!) is to travel between ends and then move to middle)
- DecDance: Move to centre or either end of tangent arm while simultaneously moving Dec slew in the opposite direction;
this maintains approximate pointing while setting up for a long dec track N or S, principally to follow a comet or similar body that has a large motion in dec.
- Incorporate tan(theta)/theta correction for motion of tangent arm - a series of terms up to theta**4 is sufficient for +- 15 degrees or so of motion.
Terms up to theta**6 are good to +-20 degrees with very little error, but may not be needed in practice.
At the moment I think most of the code should out of sight in the firmware, but the computed gotos, dec centre and decdance visible controls
might be in the INDI driver, in the virtual telescope controller with direction arrows.

I would certainly appreciate comments and help, but have no expectation that any of this be in the main line code.
The telescope I have in mind is probably unique, and there is no point in sludgeing up the main code with oddities and exceptions.
I have seen projects fail for just this reason. I would be perfectly happy to maintain a fork for this 'scope. (Unless I am missing something,
and the world is awash with dual drive 'scopes?)

Anecdote: - I went thru the code commenting out all the mentions of ALTAZM and most of FORK, retaining only GEM related stuff.
It compiled but I saved about 350 bytes of compiled space, not enough to dent the percentage!!  The MKS/Mega2560 certainly has enough memory
to do everything I need!

At any rate, I hope this has been interesting,
James Albinson


jsalbinson@...
 

Just to add: the PSU for the breadboard was a 24v, 4A laptop PSU I had available. The system worked fine with a 2m USB cable to the controlling laptop.


Piers
 

That sounds like an amazing project James!
The humungous scale of the telescope made me wonder...
...and then I might have done some slightly creepy googling.
It seems very much like you're the man for the job, to say the least :)

Piers


Howard Dutton
 

On Tue, Jul 28, 2020 at 08:10 AM, <jsalbinson@...> wrote:
This will enable controllable switching of the SlewMotors on 10msec timescales (half cycle UK mains voltage).
So you switch the relays to setup the direction (clutches, etc) and power up the slew motors, then watch the encoders?


Howard Dutton
 

On Tue, Jul 28, 2020 at 08:10 AM, <jsalbinson@...> wrote:
DecTanArm stops valid on a relative basis +- 20 degree from its zero. Not sure I fully understand the recent mods by HD in this regards - more coffee needed!
(Existing method of centering on current telescope (+- 1 degree!) is to travel between ends and then move to middle)
The new code for TA limits (should) work like the old code.  I simply consolidated several functions that did more or less the same thing into one and added functionality where guides are blocked in some cases if movement would be in the wrong direction.

The Dec TA limit coordinates are based on motor step counts (minus any backlash counts.)  In normal operating mode (non-TA) all coordinates for limits, including Dec min and max, also include the index offsets.  That is, if you manually de-clutch and move a 'scope then sync (or the encoders sync for you) the coordinates are the same as they would be if you did a goto to that location.


Howard Dutton
 

On Tue, Jul 28, 2020 at 08:10 AM, <jsalbinson@...> wrote:
- Incorporate tan(theta)/theta correction for motion of tangent arm - a series of terms up to theta**4 is sufficient for +- 15 degrees or so of motion.
Terms up to theta**6 are good to +-20 degrees with very little error, but may not be needed in practice.
This code is in ~/lib/Coord.h where step counts are converted to/from instrument coordinates.  My approach seems correct, comments and testing results are welcome.

#if AXIS2_TANGENT_ARM_CORRECTION == ON
  axis2=tan(axis2/Rad)*Rad;
#endif

etc.


jsalbinson@...
 

Hello Howard,
Still digesting some of the earlier comments, but the tan(theta)/theta function worries me a bit as both tan(theta) and theta go to zero, while the ratio analytically goes to 1, I doubt the computer can cope with zero/zero - it usually falls over. Therefore I found a series expansion for tan(theta), divided it by theta to get a series = 1+ term in theta**2 + term in theta**4 + term in theta**6. USe of a decent spread sheet, but putting in the zero terms by hand, give the result I commented on earlier. I will have another look at the code to see what I am missing. More coffee...
Chhers, James Albinson


jsalbinson@...
 
Edited

Hello Howard,
Yes that's pretty much it. But you can also predict to the nearest centisecond how long it will take to traverse a given angular distance.
So you can switch from the default track clutch to the slew clutch for a given time, and switch the E or W slew motor for the same period.
*Both MUST have the same time on.*   The N/S slew does not have a clutch - a consequence of the way the 'scope was built many years ago.
This avoids the possibility of a runaway in case you loose the encoder count for whatever reason... And gets you close enough to adjust the last little bit
on the steppers.
I found a class to switch leds on adafruit and realised that leds and relays are the same sort of thing at this level.
The proliferation of arduino switchable SSRs that can handle 2-5A is a godsend. The old system had electromechanical relay logic - robust but slow.
I hope the (rough) example code below gives some idea of my thinking - as always comments welcome.
Regards, JAmes Albinson

Maybe of interest: Bill Earl (https://learn.adafruit.com/multi-tasking-the-arduino-part-1/a-classy-solution)

class SlewMotor
{
    // Class Member Variables
    // These are initialized at startup

  int SlewPin;       //number of the slew pin
  unsigned long OnTime;     // milliseconds of on-time

    // These maintain the current state

  int SlewState;                   // SlewState  used to set the pin
    unsigned long previousMillis;      // will store last time SlewMotor or SlewClutch was updated

  // Constructor - creates a SlewMotor
  // and initializes the member variables and state
  public:
  SlewMotor(int pin, unsigned long on)
  {
    SlewPin = pin;
    pinMode(SlewPin, OUTPUT);    
     
    OnTime = on;
       
    SlewState = LOW;
    previousMillis = 0;
  }

  void DoSlew()
  {
    // check to see if it's time to change the state of the motor or clutch
    unsigned long currentMillis = millis();
    
    if((SlewState == HIGH) && (currentMillis - previousMillis >= OnTime))
    {
        SlewState = LOW;  // Turn it off
      previousMillis = currentMillis;  // Remember the time
      digitalWrite(SlewPin, SlewState);  // Update the actual  motor or clutch
    }
    else if ((SlewState == LOW))
    {
      SlewState = HIGH;  // turn it on
      previousMillis = currentMillis;   // Remember the time
      digitalWrite(SlewPin, SlewState);      // Update the actual motor or clutch
    }
  }
};
// numbers here are examples- tested on an Arduino Uno3 with arduino electromechanical relays and led indicators.
// 1000 would be replaced by OnTime -, calculated in centiseconds ie miliseconds/10, *10 - integer arithmetic rounds down to nearest
// 10 millisec.  Yet to be tested as  such.

SlewMotor SlewN(12, 1000);
SlewMotor SlewS(11, 1000);
SlewMotor SlewE(10, 1000);
SlewMotor SlewW(9, 1000);
SlewMotor SlewC(8, 1000);

void setup()
{
}

void loop()
{
// comment out etc to see leds blink in isolation - too many at once is disturbing...!!

    //SlewN.DoSlew(); delay(1000);
  SlewS.DoSlew(); delay(2000);
  //SlewE.DoSlew(); SlewC.DoSlew(); delay(1500);  // E and W slew MUST have same Clutch time.
  SlewW.DoSlew(); SlewC.DoSlew(); delay(2000);   // E and W slew MUST have same Clutch time.
}


jsalbinson@...
 

Hello Howard,
I think I see it now. Essentially you have moved theta onto the numerator on the LHS of the equation; this means that you never have a divide by nearly/equal to zero problem.
Thanks, James Albinson


jsalbinson@...
 

Hello Piers,
Yes it's a big project. During the Covid-19 pandemic here I am working in isolation, also partly for personal reasons.
I stand on the shoulders of all who have gone before and I hope to learn from, and apply the lessons, of the past.
There are problems with the current system on this 'scope, and I hope to fix them by the end of the pandemic and the
reopening of the observatory.
Regards, JAmes Albinson


Khalid Baheyeldin
 

James,

Looking at the motors (NEMA 34), I think these are the largest I've seen for OnStep over the past 3 years or so.

Can you share what the mount is, and what OTA (or radio?) it will carry?


Howard Dutton
 
Edited

On Wed, Jul 29, 2020 at 07:36 AM, <jsalbinson@...> wrote:
Still digesting some of the earlier comments, but the tan(theta)/theta function worries me a bit as both tan(theta) and theta go to zero, while the ratio analytically goes to 1, I doubt the computer can cope with zero/zero - it usually falls over. Therefore I found a series expansion for tan(theta), divided it by theta to get a series = 1+ term in theta**2 + term in theta**4 + term in theta**6. USe of a decent spread sheet, but putting in the zero terms by hand, give the result I commented on earlier. I will have another look at the code to see what I am missing. More coffee...
Below is how I see it, at least for a TA drive with a "sliding pivoting arm" i.e. the screw is fixed (at both ends) relative to the axis and the arm travels along it.  I'm no expert on TA's but I also didn't find much design info. online so this is my best understanding.  I kept things simple by using unity for the radius and 100 tpi for the screw.

1. As shown with the arm perpendicular to the screw the ratio is exactly 628:1.
2. To reach a real axis angle of 45° you would need 1" of travel.  Since tan(45) = 1 this checks out (1 * 100 = 100 steps if working at 1 step per rotation of the screw.)
3. To reach a real axis angle of 63.4° you would need 2" of travel.  Since tan(63.4) = 2 this checks out (2 * 100 = 200 steps if working at 1 step per rotation of the screw.)
4. If the TA is at 150 steps and you want to know the axis angle atan(150/100) = 56.30° which in angular steps (as opposed to angular degrees) would be 56.30 * (628/360) = 98.21 steps.




Howard Dutton
 

On Wed, Jul 29, 2020 at 08:18 AM, <jsalbinson@...> wrote:
Maybe of interest: Bill Earl (https://learn.adafruit.com/multi-tasking-the-arduino-part-1/a-classy-solution)
There's plenty similar code in OnStep except I do the math correctly.

Don't use this form, it will fall down (after several days) due to overflow:

  • if((ledState == HIGH) && (currentMillis - previousMillis >= OnTime))

It should be:

if ((ledState == HIGH) && ((long)(currentMillis - previousMillis) >= OnTime))


jsalbinson@...
 

Dear Khalid,
The mount was constructed 50 years ago by a heavy engineering co., and this is the 5th iteration of the drive system, reusing parts from the 3rd iteration.
The OTA is a steel frame of Brobdignagian proportions (500kg) with a 600mm f4.5 primary used at Newtonian.
A quick google on my name+observatory will reveal all, but as I replied to another poster, this is an individual project at present.
I will be considering TB6600 (Generic) driver blocks to run the stepper. Just that they are widely available and not too expensive.
OnStep should be perfectly good at running a radio telescope!!
Regards, James Albinson


jsalbinson@...
 

Thank you Howard,
This is the sort of tip I appreciate as I am new to Arduino programming; my background is in Fortran.


Khalid Baheyeldin
 

Wow ... 60cm Newtonian.
Would love to see images made through it ..

Must be the Thornton telescope at Keele Observatory then?

Also, I look forward to a writeup on how this was converted to OnStep, so it would feature on the showcase page.


jsalbinson@...
 

Hello Khalid,
Yes, it is. The conversion to OnStep is ongoing in my mind, mostly, to replace the current commercial system that has problems.
I am working on TinTac, to test ideas, and on replacing some of the peculiar hardware.
Very much my thing. And it may never come to pass: there are many considerations.
Herewith an early commissioning image with the current system, which no longer works.
Regards, JAmes Albinson
M57 BRI filters, combined.