Print

[pterodyne]

Ive been trying to track down an issue that seemed to appear after I upgraded, but I cant say for sure because the mount was in a closet for a long time.

It seems that after a goto slew it does a sort of consistent approach procedure end to the goto (as in always approach the target from the same direction).  Not sure if that is implemented in astroeq or not. Just trying to describe the behavior.  Anyhow, It seemed that the mount used to hunt a little at the end of the slew and then settle on the target, Now it does that, except it goes WAY past the target and back and forth several times before it settles on the final spot.  Also the gotos are way off.

Stats:

CG5
purchased astroeq /drv8825 (8.11)
current limits set
.9 degree Nema 17 steppers
GT2 Pulleys 38:18 (2:1)
144:1
1/32 uStep
ustep gear changing flagged on

[pterodyne]

36::18 i mean

[pterodyne]

Tom, any thoughts on this?  when you watch the telescope indicator in maximdl when it is at the end of the slew, it wildly moves around the target many many degrees, then eventually settles.  Pretty much dead in the water for now.  Because I have to plate solve every slew as it is degrees off.  It sounds like it is ramping up and down for  each correction at the end  of the slew.

[TCWORLD]

Sorry, things are a bit hectic again at the moment (been teaching two modules at uni). I will look in to this once I get a chance, probably over easter.

[pterodyne]

just checking back to see if there were any more thoughts on this issue...

[TCWORLD]

I haven't had a chance to have a look yet. It's tricky to do so working a full time job at the same time as studying full time for a PhD.

It seems an unusual issue, and possibly related to the acceleration/deceleration routines. I will try to find some time to investigate.

[pterodyne]

I just replied to the other post about read failures.  Re-seating the chips seemed to do it.  Ill test out the current config with the TMC2100 drivers and see if I still have the issue with hunting at the end of slews.

Thanks again for responding. 

[Washy]

Does it hunt on straight slews? 

If I slew to a target for example using CdC it goes straight there and stops.

To get the hunting behaviour you describe (and I do get it) I have to be using plate solving and be close to the target after the initial slew.  What is happening I think is this, camera takes a shot, plate solves, off target, syncs, re-slews to target, takes a shot etc....

Now the issue (for me) appears to occur when the target is close but not within the plate solving threshold so it has to capture and resolve, but the new required slew is tiny but the motors accelerate to the a slew speed beyond what is required which coupled with the deceleration puts the scope off target, so it solves and overshoots back again ad infinitum.

I've found the easiest fix for this issue is simply to plate solve to a new target a few degrees away, then back again with model points close to your target you tend to land bang on your objective and the plate solving sequence will end without hunting.

[pterodyne]

I see what you are saying, but no Im not plate solving at that time, Just a basic slew from maximDL to an object.  Good thinking and thanks for the suggestion.

Plate solving makes the issue less relevant as it is near the target and never gets to full speed.  Tom suspected it's possibly a ramp related issue, and the prior sentence does make that seem so

So yes, it seems to only happen on long slews that make it to full speed. It's almost like it's not using the right speed to center the object at the end of the slew.

Also, Tom is there a consistent approach feature in astroeq at the firmware level?  EQMOD I don't believe has it, but things like Sitech servo and ACP do have it.  I ask because what it seems to be doing is overshooting the object and then going back and forth eventually settling near the object.

[TCWORLD]

There is an inherent overshoot or undershoot in the RA axis, simply because by the time the slew completes, the stars have moved - the RA tracking is effectively disabled while slewing. This will affect all mounts controlled by EQMOD, not just AstroEQ. EQMOD corrects this by performing a short slew at the end to get back to the target.

What's likely happening is that the acceleration table for your specific settings is some edge case that I haven't tested. Each mount settings will have a different acceleration table to try to achieve linear ramping. To allow for deceleration, the go-to is stopped short of the target by the total number of steps that it should take to decelerate, thus theoretically ending the ramp at the target.

However this process is an open-loop control (no feedback). If there is a mistake in the table, your slews can potentially keep going for a litter or a lot longer than intended as the mount takes many more steps to decelerate after the go-to completes than intended.

If this occurs, you will likely see lots of oscillations as the mount overshoots, then EQMOD tries to correct, but it overshoots again, EQMOD tries again but it overshoots, etc. It would either eventually settle on the target, or EQMOD will give up trying after I think three correction attempts.

[pterodyne]

, I just put the AstroEQ my Titan mount. I'm still having this problem. I would love to get it solved

Current specs
Drv8825 @ 32uStep
Gear changing disabled (needed or motors stall)
270 worm wheel
3 motor gear
1.8° nema 23 1.5A
Slew speeds 325

Thanks forr any advice

[TCWORLD]

Which version of EQMOD are you using?

I've just tried the settings you gave with an AstroEQ and V8.12 firmware (albeit no motors attached), Cartes Du Ceil, and EQMOD V2.00q. Watching the scope move in CdC and monitoring serial comms, I don't see any back and forth.

Kind Regards,
Tom.

[pterodyne]

Latest from the website.  Here is a video of the action

[url]https://youtu.be/DikBOi_hP54[url]

[TCWORLD]

I've just tried in CdC slewing around between the same galaxies as in your video and get no overshoot issues.

[TCWORLD]

Could you try following the instructions here, albeit performing goto movements that replicate the issue. Then attach the log files that are produced.

That should give me a better idea of what commands are being sent and what actions the AstroEQ is performing (I can then also replay the exact same sequence of commands at my end).