Home                                                   page 1    page 2                                                        

 

Excerpts from the Scope-drive List 

TROUBLESHOOTING

 

Handpad

Slewing    

 

HANDPAD:

Problem:   I've run into a problem with the buttons on my hand pad, that is, three of them won't move the scope. East is the only functioning key. I have opened the hand pad and checked the continuity of all the buttons and wires and everything seem okay there. I also checked the continuity of the hand pad wire from the drive box. BTW: Mel made the hand pad, not me, so it isn't a wrongly built pad. Also, it was working fine a couple of weeks ago. Oh yea, I used the F1 thru F4 keys and they worked just fine, so it seems that the functions are there, just not from my hand pad.    Steve Mitchell

Suggestions:  

See if the handpad button display changes while you press keys. Report back to us which keys do not cause a response on the display, and I can tell you which data lines (probably the cable or the RJ12 mount point on the circuit board) need to be looked at.  Mel Bartels

+++

...check if you did not change the "handpad design" variable by chance - if it is the "4 direction buttons only", scope would react only to 1 key... If so, you need to get it back to standard design. I think I got the same problem some time ago.  Pawel

+++

...you mentioned that the fast/slow halfstep/microstep speed switch on the handpad causes the scope to move. The only way this can happen is if the handpaddesign in config.dat is set to non-zero. ...the wrong cable can mix the data lines too...        Mel Bartels

+++

Check your coordinates and see if Scope.exe thinks you have run into one of the software movement limits. One time when testing, I had my scope pointing at 45 and Scope.exe wouldn't let me move in any direction except up. I spent a half hour trouble shooting and finally put the  scope at 0 and went to change the coordinates and that's when I noticed it had been at 0 all the time. My Alt lower limit had been set to 0.    Don D'Egidio

+++

Troubleshoot Handpad - When you fire up scope.exe, you should see the following characters in response to button presses from the handpad.  Look in the lower right of the screen for a 'U, D, C or W.  If you are not seeing those, make sure that handpad is seeing 5 volts on common wire.  If it is, unplug the parallel port and check for a 5 volt signal on pins 10,11,12,13 on the DB25 connector on Mel's board.  You should see one or more of these pins go to 5 volts depending on the button you press.  If this is happening and you still do not see a response to the handpad from the software, suspect your parallel port on the PC.  Try the same thing using the parallel port test from the menu on scope.exe.

The "ramp up" indicates nothing except that the motor is being ramped up.  You should see an indication of the button pressed in the lower right corner of the screen.  This is the U,D,C, W that I refered to in the previous post.  Under any circumstances, you should see at least one or more of these appear with different buttons pressed.

The simplest way I know of to debug this is start at the output from Mel's board and test with a volt meter.  What you need to verify is that the correct parallel port pins are being raised to +5VDC when a button is pressed.  The handpad pins are 10,11,12, and 13.  You can test at the end of the cable that plugs into the PC.  Unplug at the PC and connect between one of the ground pins 18-25 and 10-13 one at a time and try all the handpad buttons.

The actual direction buttons will work as follows.  Up and Down or Dec will raise pins 13 or 12 respectively.  The East and West or RA will raise pins 12 and 13 together or pin 10 alone.  

Check this out first and verify that the PC is seeing correct signals on the parallel port.  If it is, then you can verify that the software is seeing these pins go high by running the parallel port test from Scope.exe.       Martin  Niemi  

+++

Q.   On the axis that is being commanded to move I see what you would expect....that is 4 LEDs blinking rapidly, chasing each other. However the curious thing is, 1 (one) of the LEDs on the other axis lights up as well. 

A.  This is correct behavior. What you start a move, both motors are energized. With the handpad, only one motor will move, the other will keep its position by powering a single winding. Eventually, based on the setting in config.dat, the stationary motor will be powered down.     Mel Bartels

+++

SLEWING:

+++

Problem:      I slewed back and forth for two nights now from Antares and Dubhe.....never winding up exactly where I wanted to be, but very close.....I adjusted the step sizes along the way hoping for better results , and while there were improvements at times it never was repeatable (star wound up centered or near centered in eyepiece)...I also adjusted my Backlash a bit along the way hoping this might help and to no avail.   (getting repeatability, but one axis is 4.5 step size and the other is 3.625 step size. This with identical gearing on both axes)

Chris Guerra

Suggestions:

//////  Mel Bartels

The software is accurate to sub-arcsecond. The hardware is accurate as long as the motors do not stall. Now the critical third element is the mount. A mount that tracks 'well enough' may be able to do gotos or it may have problems. Until computerized gotos, a lot of mounts with a lot of problems went unnoticed.

Things to check:

1. In daytime, mark the stepper rotor's position, and slew a set number of steps that equal say 15 degrees. Slew equal number of steps in opposite direction to return to where you started. Is rotor in same position - is mount at same angle (use a precision bubble level or a laser pointer on the tube assembly)? The answer must be yes before proceeding.

2. Calculate the step size based on gear ratio and move a set number of steps, say 45 degrees, measure with the precision bubble level. Did you move 45 degrees? Return to home by moving the program with offset altazimuth degrees. Did you return to exactly where you started? The answer must be yes before proceeding.

3. When you adopt an equatorial alignment at startup, then reset to equat coordinates, make sure that you are using a crosshair eyepiece. 'Centering by eye' is amazing imprecise. Do a slew of 10-15 degrees. Did you make it on target? If not, then return to original coordinates. Is the original object centered?  The answer must be yes before proceeding.

When you say that redoing the inits improves things, it makes it sound like the mount is not well polar aligned, or has issues in terms of flexure or mis-alignment between the axis. Need to figure out some tests for these issues and apply them in the daytime, away from the stars.    

Can you return to where you started accurately? If so, then unlikely that gears or rollers or motors are slipping. More likely that step size is the culprit.  Re - polar alignment

If you did a full 2 star init procedure manually, and you get polar alignment close to zero, then you are doing perfectly. The polar alignment values are in degrees, ie, .001 (deg) is just a few arcseconds.  mb

//////   Chuck Shaw

If the scope tracks fine with the 4.5 stepsize, but needs a smaller stepsize to slew OK, that's a clear indication that the accurate stepsize is 4.5 and you are most likely dropping steps during the higher speed parts of the slew. The fix is NOT to fake out the stepsize, you know what that needs to be..... 4.5. What you need to do is find the electronics/electrical problem, or perhaps a configuration problem ...

In your other note you said you swapped the motors and cables and the problem happened with the other motor and cable. (did I read that right?)  That would vindicate the motors and cables, so it sounds like you are having a problem with the board. If the problem moved with the motor and cable to the other axis, that would say the problem is in the motor and cable... If you were geting good tracking on the moon, your tuning is probably not that far off, and tuning will not affect the 1/2 step slews.  What are you using for timing? IRQ timing? 

Meanwhile, download the circuit schematic from Mel's website, and the drawing of the PCB. Use the two drawings to compare components and verify all the diodes over near the row of TIP120 transistors all have the band on them aimed in the right direction per the drawings. It looks confusing at first, but take your time and you will be able to identify the components...

What I am wondering about is something in the strings for the RA motor is breaking down when the motor is going fast and not passing on the pulses like the PC "thinks" are getting passed on. If you have a meter, compare all 4 strings of electronics for the RA motor to see if anything is "different" between the 4 strings. What I am referring to as a string starts with the parallel port pin, and goes thru the board to the output of the transistor. There is a string for each winding. I think you can safely not worry about step sizes if the tracking was good... at least that's some progress!   cs

//////   Andy Martyn

Pointing accuracy does vary greatly depending on how well you mount is made in terms of orthagonality of axis and flexure, how accurate your gears are, and how accurately you perform the initialization process. With both the scope drives I have built first up errors were in the region of 0.5-1.0 deg for long slews ie 90 degrees plus. After some fine tuning of the system by checking orthagonality of the axis, checking for unwanted movement in the motor drives, checking optical alignment and then making assessments of Z errors I was able to get long slew errors down to 5-15 arcmin. Generally offset slews from a know object that are close by are less than 5 arcmin.  However it took a lot of fiddling to get that accuracy.   am

//////   Larry Bell

I agree with Andy. I'm using a GEM and I generally experience long slews accurate to better than 1/2 deg with a mediocre polar alignment. Of course, every time I make the slightest mod to the mount I end up tinkering for a few weeks to recover my accuracy. You should definitely calculate the Alt and Az step sizes -- its the only accurate means.

Also, setting the Z parameters via the analysis functions in scope is essential as Andy mentioned. Remember that the mechanical alignment of the scope mount isn't the only issue. You must also ensure any misalignment between the scope's optical axis and the mount's mechanical axis is taken into account. The Z parameters will handle all these errors and must be determined for descent accuracy.

Finally, you didn't mention using cross-hair eyepiece -- you are using one aren't you?? If not, your inability to accurately center the star in the eyepiece is a significant part of the problem. You need to use a cross hair eyepiece (illuminated reticule) with LOTS of power. I use a 12.5 mm illuminated reticule with a 2.5x barlow for my precision alignments.   lb

I'm with the guys who are suggesting slippage in the gear train. I have the same Beyers gear and worm that you're using. I have a terrible problem keeping my worm and reduction gears from slipping on the shaft. They all lock to the shaft with 2 allen screws and no matter how tight I made them, they would eventually slip when worked back-and-forth during slews. I ended up grinding a flat spot on each shaft under the allen screws and adding a small locking collar on each end of the worm to keep it from sliding. So far, this has worked.  lb

//////  Marty Nemi

I would stick with the step sizes that the gear ratios and motor steps calculate out to.  It may be one of a couple of issues that are giving you problems. Check to make sure that there is not clutch slippage. If you are moving a heavy scope, the gearing can generate allot of torque very quickly if the ramp up/down is too fast. It may be worth lengthening the ramp as an experiment.

//////  James Lerch

For each axis of your scope, perform the following tests

#1 Mark stepper shaft, and command stepper to move 400 Half-Steps.  From what I've read, you have 400 Step motors, so this test should rotate your stepper a 1/2 turn.

#2 Make a reference mark on stepper shaft and First reduction gear. (I think I read your first reduction is 2:1) Using 800 Half-step increments only, command half-step moves to make one rotation of 1st reduction stage. If 2:1 and 400 step motors, it should take 1600 Half-steps for marks to re-align. Repeat test 10x, IE 16000 half-steps should make 1st stage rotate 10 times, Not important to count rotations, just make sure marks re-align!

#3 At this point, we now know the reduction between stepper and 1st stage, without actually having to count teeth ;) If step # 2 resulted in 2:1 reduction AND your have 400 step motors, then it takes 1600 half steps to move worm gear one tooth.

#4 Make reference mark between worm gear and worm. Using 1600 half-step increments * best guess at number of teeth on worm, command half-step moves until mark re-align. IE if 359 tooth worm and 2:1 reduction and 400 step motor, then command move of 574,400 Half steps should move worm gear one rotation for marks to re-align. The trick to this test is each time you command a move, It MUST be in increments that equal one complete turn of the stepper shaft.

When done, you will know exactly what your reduction is, without having to count any teeth. Once you know your reductions and their resulting Arc-Seconds per full step, Never change these values! If troubles persist, it something OTHER than your Arc-Seconds per full step:)      jl

//////   Chuck Shaw

1. Have you physically counted the teeth in both gears? I had a gear that was marked 360 one time, and found out it was 359 instead when I actually counted the teeth. Same for the spur gears you are using....... Do not go by just the markings on the gears. Seems obvious, but I was duped once on this....

2. If all the gearing is exactly as you described, try swapping the motors for the two axes. It is not impossible to have the motors not both be 400 step motors as you are led to believe.

3. If you still get the same results with the motors swapped, and also having physically counted all the teeth on all the gears (worms and spurs), then you may be dropping steps someplace. If your slew speed is too fast, that can happen without your realizing it. If the scope is well balanced it will happen moving in both directions. Try raising the MinDelayX value up a LOT higher than you are currently using to make the slews nice and slow and stately.

4. Can you swap the cables to the motors? I.e. run the RA motor cable to the Dec motor and vice versa? On the off chance that the circuitry or the cabling for one of the motors has a problem, this should shift the error to the other axis.

5. If there are still differences, try commanding the slews differently.  If you have been commanding a given angular difference, instead, use the MOVE command and command the move by specifying a given number of halfsteps to see if its repeatable.

6. You did not specify whether you are using encoders? If yes, are the thresholds set to zero, so you are not getting any encoder resets?cs

//////   Mark Rice

I spent a long time troubleshooting a similar sounding problem to yours before I realised that one of my motors was stalling, but only when BOTH were moved at once. Even if you're sure yours are fine, I'd highly recommend the following little test:

- During daylight aim the scope at some nice point in the distance (say a TV aerial or some such).

- Reset ALT/AZ coordinates to 0,0

- Using the handpad move to some other nice landmark, preferably at a different altitude.

- Note down the ALT and AZ figures

- Tell the scope to slew under computer control back to 0,0

- Check that your first target is smack bang in the middle of the eyepiece

- Slew under computer control to your second target and check that is in the eyepiece

- Play with a few other landmarks, doing 360 pirrouettes, random slews in between etc.

In my experience, until you reach the point where the scope will slew accurately all day long to objects that are fixed to the spot, you're wasting your time trying to hit moving targets, experimenting with different initialisation techniques etc. Had I realised this, I'd have saved myself weeks of frustration under the stars.

Once you are confident that your mechanics are spot on, testing under the stars is more fruitful.               mr

//////  Geoff Dudley

One thing which could cause your problem is that perhaps the output from the Melbox isn't sending all the pulses. What I mean is, have you connected a LED tree to the output and actually seen every LED light up when your handpad is used? If one of the LED's isn't lit, then your step sizes will be out. check the o/p from the Melbox, then at the end of the cable before it connects to the motor.   gd

//////   Dale Eason

Since the scope always comes back to the spot where you started then there can be very little slipping. That leaves only a few posibilities for the axis that does not match the calculated step size.

Two that I can think of are:

1. The motor is not really 400 steps. You can test this by marking the shaft and tell scope to move 800 half steps with one of the move commands. If the mark comes back to the starting location then it is a 400 step motor.

2. The gears do not have the number of teeth you think they have.

Count them.   de

///////   Steve Mitchell

Counting teeth on a gears, especially on large worm gears, CAN be tiring on your eyes! Not only to perhaps help you, but also others with this situation, my solution was this: I took a soft leaded (#2) pencil and marked a starting tooth on the side of the gear with a pencil line and named it 0.  Then at every 10 teeth I marked another pencil line and wrote 1, 2, 3, etc. When I got back around to the beginning tooth, I wrote the actual number of teeth in the last space, which in my case, with a Byer's 10" gear, was a 9, as my total number of teeth was also 359. After counting them all two or three times, I multiplied the final number times 10 and added the 9 for 359 teeth.

It then made it much easier to double and triple check my count without necessarily recounting every tooth again each time.   sm

//////  Ken Hunter

Following the wire colors is too complicated without a diagram at this end. Here's something to try...

Use the parallel port test function and measure the results at the Collectors of the output transistors. Select the "H" key and all the Base inputs should go HIGH causing ALL of the transistors to conduct and making ALL of the Collector voltages go LOW. (a voltage around 1 volt is EXPECTED). Make these measurements fairly quickly as the transistors will be ON HARD for the duration of the "H" test and may overheat if left in the ON HARD state (Collectors LOW) for very long

Select the "L" key and all the Base inputs should go LOW causing ALL of the transistors to NOT conduct and making ALL of the Collector voltages go HIGH. (a voltage very close to the power supply input). You can leave the transistors in this state forever without worry. If this is not the case, then the problem is in the portion of the circuit that is different from the rest. (All 8 channels are

identical). You may find that the behavior is exactly the opposite as regarding the "H" and "L" due to circuit differences BUT ... ALL 8 TRANSISTOR COLLECTORS SHOULD BE IN THE SAME LOGIC STATE DURING THE PARALLEL PORT "H/L" TEST AND SHOULD CHANGE STATES TOGETHER WHEN YOU CHANGE FROM "H" TO "L" AND VICE-VERSA.

If you get through this test OK, the issue is either software or motor wiring. I'm suspicious of the RED wire that you read ZERO volts on. Assuming that the RED wire is the one connected to the Collector, to get ZERO (REPEAT ZERO) volts there, either the transistor is shorted directly to ground or the path between the RED wire leading to the supply (motor winding, connection) is OPEN.  kh

//////  Chris Guerra 

IT WAS THE LEVELING "GAGE" (ANGLE GAGE ACTUALLY)...I KNOW IT SOUNDS HARD TO BELIEVE BUT HERE'S THE BACKGROUND AND HOW I DISCOVERED IT. This is one of those "calibrated" angle gauges with a magnetic bottom made by "STARRET" ( a well known American Tool making company) it operates with a moving needle against the 1/2 degree angular scale shaped in a radius of ~2". The needle operates by gravity and springs, it is held in its runway between plastic walls (front with clear view screen so as to read the thing and back of a red polycarbonate). What I found was that if the gauge is not set level front to back on its magnetic foot the needle has a tendency to hang up on the rear wall (or possibly the front wall).....and thus give inaccurate readings, though repeatable in this case, as the motion of the RA (counterweights) is repeatable as the tests are performed. What happens is the gauge starts out with an accurate reading, but as the RA shaft rotates the gauge magnetically held to the counterwieghts does not stay in a perpendicular position relative to the ground and pull of gravity and thus the gauge stops reading accurate travel.  cg

 Problem  -  MOTORS DON'T RUN SMOOTHLY:

What is smooth output?   My motor shafts turn with a sort of clock second hand motion; rotate stop, rotate, stop

 +++

You can check the steppers and cables individually by swapping them from alt to Az connection. You could have a bad stepper cable.  You could have a dropped stepper, and thus damaged the magnet.

Problem  -  MOTORS OVERHEAT

Q.  my english is not so good, but i hope you can read it. :-)  I build the PCB from Mel Bartel and everything working at the beginning fine. I use two Sonceboz 6500 12V 1A Motors (8 wires unipolar). The Power of the motors are great and  the mircostep with 20 is working fine. I only have one Problem. The  current of the two Motors and the PCB are 10 Ampere. Thats to much  for my Batteries. The Motors runs hot at Microstep, at Halfstep it  works fine. Can i resolve the problem with an current limiter  (resistor) or what i can do, that i come down with the ampere.

A.  make sure that InvertOutput in config.dat is set properly (either 0 or 1). With software running, but tracking off, the motor shafts should be free to turn. If not, change this value.  Make sure that you have InvertOutput in config.dat set properly otherwise when you first turn on the circuit, all 8 windings between the two motors will power on, and cause a tremendous current draw.  InvertOutput should be 0 if using my board.  Mel Bartels