Date   

ServoConfig/Ticks Determination Problem

Raphael T Vilardi
 

Dear All
When using the ServoConfig/Ticks Determination tool I'm having the following problem: The angles reading and TPR are double counted, that is, the mount would turn 180º
but the angles reading would show 360° and the TPR would also display the expected figure for a full 360° turn. I didn't pay much attention to it when I used the tool and until  I first started to use the go-to feature with the Sitec last evening. I've found out that, when choosing a given object and hitting go to button, the slew would stop halfway. Has anybody run in this kind of problem?? Best regards to ALL


 


Re: scope and motor encoders fighting?

Joshua Hufford
 

You could also try running your controller from a battery. Dan helped me figure out a problem several years back when I was running my controller from a 24V power supply and Losmandy Gemini motors which were made for 12 volts. Even though I had the output set to 50% in the config, for some reason the motors did not like this, Dan suggested trying a battery and the problem went away. I switched to a 13.8V power supply and still had no problems. 

I know your problem is different but batteries give very clean power. 

Josh

On Mon, May 3, 2021 at 5:49 AM Huw O <huworwig@...> wrote:
Thanks both. PSU could be an issue, I have a spare one, will try using that for the mount, with the dome on the present supply. The dome motors are on a PWM soft start circuit, so should not be too bad.
Will check secondary lockdown screws, but why am I not seeing any motion with Gurley ignored.
Next clear night, I'll try running PHD with corrections off, to see the effect clean.

Keep suggestions coming please, I really want to get this sorted, I've invested a whole lot of time in this mount, and its so close...

Huw


Re: scope and motor encoders fighting?

Huw O
 

Thanks both. PSU could be an issue, I have a spare one, will try using that for the mount, with the dome on the present supply. The dome motors are on a PWM soft start circuit, so should not be too bad.
Will check secondary lockdown screws, but why am I not seeing any motion with Gurley ignored.
Next clear night, I'll try running PHD with corrections off, to see the effect clean.

Keep suggestions coming please, I really want to get this sorted, I've invested a whole lot of time in this mount, and its so close...

Huw


Re: scope and motor encoders fighting?

paul K
 

Also Huw, I appreciate what you've said about the RA axis and Gurley, has anything else changed in your equipment?
Paul


Re: scope and motor encoders fighting?

paul K
 

Hi Huw, I have had problems that cused images to look like this and in my case it was mirror movement in my sct (I had both a C11 and a C14 with these problems). However, your PHD2 graph shows periodicity in those RA spikes and looking at the graph, it's obvious that PHD2 is trying to guide these movements out. If you haven't done so already it's good to post your PHD2 log in the PHD2 help forum. Bruce and the help team have seen most things over the years and will be able to point you in the right direction. To me it looks like a mechanical problem of some kind.

best wishes
Paul


Re: scope and motor encoders fighting?

Don W
 

Hi Huw,
Please CHANGE the power supply for the mount - the none that powers the USB and cameras.  The dome motor "could" be your problem.  Domes generally use motors that are simply switched ON and OFF, causing spikes in the power, especially on start of move.

The controllers switch power at something like 50 khz, so cameras and usb hubs are mostly unaffected (the high frequency switching is easy to filter out.  But BIG spikes like a dome motor starting are not filtered out.

Don W


Re: Servo controller 1 vs 2 #question

Czar <czar551@...>
 

Thank you Don for the reply, helped me a lot.

best regards


Re: scope and motor encoders fighting?

Huw O
 
Edited

That's the annoying part, the Gurley is really bringing the mount under control, but I'm afraid the spikes are real Don, here's the resulting effect on a sub:



And here's the detail of a spike, probably not corresponding to the above image, but they are all quite similar:



The rig is powered by a pair of beefy, 10 Amps plus 12V bench supplies, one for the mount and dome, the other, 'clean' supply handles the cameras, usb hub etc.
PC is mains powered.

Huw


Re: scope and motor encoders fighting?

Don W
 

Hi Huw,

Well, it looks like the Gurley is working pretty well.  But those spikes in RA - are they real?  They are so large and narrow - but your setting doesn't show the PHD2 corrections.  It is hard to imagine guide corrections making those fast correction.

When I ask if they are real, does an image of stars show a big spike (using an imaging camera) when the guider shows these spikes?

What kind of power source are you using for the mount, guide camera, PC and imaging camera.  Your spikes a month ago were at roughly 1 hour intervals, these are at 24 to 28 minute intervals. Strange!

Don W


Re: scope and motor encoders fighting?

Huw O
 
Edited

Right, after work, weather and moon got in the way I've finally got back to this.
I've tried a different camera and cable loom, and a new PC, and this was the result last night.
First, with the RA Gurley set to 'ignore'

And with the encoder enabled and set to 'TM'

All cables were dressed so as not to impede the movement of the mount, also the comm Loop was set to 100.
Not sure what else to try, anybody with any sugestions?

Huw


Re: saving the tracking change to the controller

Gary Hug
 

Thanks for the clarification Dan. I imagine the tracking rate is determined almost totally by the ticks/revolution numbers in SiTechExe. And I'm also guessing the tracking rate would be adjusted to some degree by changing the servo clock numbers? Is that a way to fine tune the tracking rate?
I've never used offset tracking but I'm going to try the offset tracking mode on a few NEO's in the near future. SiTech's been a great system for my 22" 'tank' for more than a decade.

cheers
Gary

On 4/29/2021 11:31 AM, Dan Gray wrote:
Hi Gary and Don,
The equatorial rate is designed only for stand alone operation, no computer..
When you have a rate here, and checkbox the Equatorial, the Servo Controller starts up tracking at the rate you specify.
If you run SiTechExe, the equatorial rate has absolutely zero effect on the tracking, as soon as SiTechExe sends a motion command, the equatorial rate is stopped.
The rate now comes from motion commands from SiTechExe.
Dan
On Wed, Apr 28, 2021 at 3:54 PM Gary Hug <garyhug@mercurywireless.net <mailto:garyhug@mercurywireless.net>> wrote:
Thanks for the information Don.
I'll work on that a bit more when skies clear.
cheers
Gary
On 4/27/2021 8:28 AM, Don W wrote:
> Hi Gary,
> In ServoConfig when changing the Equatorial Rate, you then must both "Send
> Configuration to Controller" and "Save Controller Configuration to Flash
ROM".
>
> When you run SiTechexe and watch the value for RA, it won't change the RA
value
> shown at the bottom of the SiTech window nor in the SkyView display.  The
only
> way to check if the rate has actually changed is to track a star in the sky.
>
> However there is another way to modify the tracking rate (separate from
> ServoConfig), in SiTechexe you can use Offset Tracking Rates in the Features
> Tab.  This will definitely change your tracking rates, but it can not be
saved
> for another session.
>
> Don W
>


Re: A question for Don

Dan Hummel
 

Thank Dan for your help. Glad we have someone with your knowledge of the system to give us a hand.


Re: A question for Don

Dan Gray
 

The absolute encoder checkbox should not be used unless both encoders are absolute.  The only effect on the system is when you start SiTechExe, it reads the encoders and saved offsets and starts up initialized, no need to unpark or sync on a star or something.
Dan


On Mon, Apr 26, 2021 at 8:01 PM Russell R via groups.io <rem.64=yahoo.com@groups.io> wrote:
Hi Dan H,

From what I see, if you shoot from the hip, I definitely don't want to get in a gun battle with you! 

Regarding the absolute check box, I'm not sure, maybe Don knows.  If it was me, I would tick the box and see what happens. I live on the edge.
 
I keep looking at that Dec clamp....... I'm assuming it is to stop the Dec axis from freewheeling?   It would be good if you could put that Renishaw in that spot and somehow make a brake on that stacked harmonic drive.
Now look at who's shooting from the hip. ;-)

I always wondered if split rings have a problem with eccentricity on the ring, is that an issue?

Well done and thanks for sharing those photos!!

Russell R.


Re: saving the tracking change to the controller

Dan Gray
 

Hi Gary and Don,
The equatorial rate is designed only for stand alone operation, no computer..
When you have a rate here, and checkbox the Equatorial, the Servo Controller starts up tracking at the rate you specify.
If you run SiTechExe, the equatorial rate has absolutely zero effect on the tracking, as soon as SiTechExe sends a motion command, the equatorial rate is stopped.
The rate now comes from motion commands from SiTechExe.
Dan


On Wed, Apr 28, 2021 at 3:54 PM Gary Hug <garyhug@...> wrote:
Thanks for the information Don.

I'll work on that a bit more when skies clear.

cheers
Gary

On 4/27/2021 8:28 AM, Don W wrote:
> Hi Gary,
> In ServoConfig when changing the Equatorial Rate, you then must both "Send
> Configuration to Controller" and "Save Controller Configuration to Flash ROM".
>
> When you run SiTechexe and watch the value for RA, it won't change the RA value
> shown at the bottom of the SiTech window nor in the SkyView display.  The only
> way to check if the rate has actually changed is to track a star in the sky.
>
> However there is another way to modify the tracking rate (separate from
> ServoConfig), in SiTechexe you can use Offset Tracking Rates in the Features
> Tab.  This will definitely change your tracking rates, but it can not be saved
> for another session.
>
> Don W
>






Re: Quite A Learning Curve

CandCShaw
 

Enjoy Rusty!!!!

Chuck


On Apr 29, 2021, at 9:29 AM, Rusty Fletcher <rusty@...> wrote:



[Edited Message Follows]

Thank you for your reply Paul,

Good Idea! After I get the the new servo motors mounted, electronics installed, and all the software running on one computer, I will star test everything and check the Task Manager performance tab. The upgrade may take a month or more. I haven't started yet. When I'm doing an upgrade like this I like to take my time and work carefully. Right now I am thoroughly studying everything so I understand how the new servo system will work. I appreciate you guys advice.

Thank you,
Rusty


Re: Quite A Learning Curve

Rusty Fletcher
 
Edited

Thank you for your reply Paul,

Good Idea! After I get the the new servo motors mounted, electronics installed, and all the software running on one computer, I will star test everything and check the Task Manager performance tab. The upgrade may take a month or more. I haven't started yet. When I'm doing an upgrade like this I like to take my time and work carefully. Right now I am thoroughly studying everything so I understand how the new servo system will work. I appreciate you guys advice.

Thank you,
Rusty


Re: Quite A Learning Curve

paul K
 

The concept of multi threaded application software and computer processors running at many millions of instructions per second means that for all intents and purposes, the processes in the machine (cameras, mounts, guide camera, etc) run concurrently, with no interference between them. Your guide cam and main cam can download simultaneously with no delay /lag to other processes. The computer processor(s) switches between the processes to ensure they are serviced effectivley.

'Simultaneous' is not entirely technically true and depends on many things, but the huge processor and bus (internal data transfer ) speeds mean the tasks you need to perform in terms of astronomy gear (mount, camera, guide camera, rotator, dome and shutter robotics, add anything you like to this list) means that your computer's capablity is barely taxed. The amount of downtime the processor has is huge (even when it is simultaneously downloading a hi res image and a guide cam image) - you can see this for yourself on a Windows computer by running Task Manager and looking at the performance tab.

USB connectors can be daisy chained if you don't have enough on the laptop, just buy as many usb hubs as you need. I use two four port hubs to connect eight items of gear to my old (2001 vintage) Dell with 4 GB RAM.

Going back to your dual core laptop. My Toshiba dual core with 4 GB of RAM ran Sitech, PHD2 guiding, image capture software, my dome control robotics, and played youtube videos simultaneously.

you won't have any computer capacity problems with a single computer running all your gear.

good luck with it.
Paul


Re: Quite A Learning Curve

Rusty Fletcher
 

Hello Don,

I have been trying for over a week to fully understand this? You said " Pulseguide measures the error and sends a required correction in terms of arc-sec to the controller (inside the PC)". My question is: How does Pulseguide measure the error? Doesn't the guiding camera (not the main imaging camera) have to take an image (1 or 2 sec exposure), download that image to the computer, then PHD analyze the amount of error correction that needs to be done, and then send a correction to the SiTech controller? It seems to me if I have only one computer constantly downloading small images (I use a Meade Deep Sky II camera for auto-guiding on a second guide-scope) every 3 or 4 seconds, and (that same computer) downloading high resolution color images from my ZWO ASI533 camera through a USB 3.0 cable every 20 to 40 seconds, and that same computer running planetarium software (The Sky 6.0), things are going to start lagging and running slow. And, sometimes there will be delays between the computer trying to download auto-guiding images and trying to download the main images at the same time, which will cause lots of tracking problems. For ALT/AZ auto-guiding I like for my guiding corrections to occur in less that 5 second intervals. That is when I get the best images. I usually take about 200 or more images of one deep space object and stack them. Attached is an image I did recently.


Re: saving the tracking change to the controller

Gary Hug
 

Thanks for the information Don.

I'll work on that a bit more when skies clear.

cheers
Gary

On 4/27/2021 8:28 AM, Don W wrote:
Hi Gary,
In ServoConfig when changing the Equatorial Rate, you then must both "Send Configuration to Controller" and "Save Controller Configuration to Flash ROM".
When you run SiTechexe and watch the value for RA, it won't change the RA value shown at the bottom of the SiTech window nor in the SkyView display.  The only way to check if the rate has actually changed is to track a star in the sky.
However there is another way to modify the tracking rate (separate from ServoConfig), in SiTechexe you can use Offset Tracking Rates in the Features Tab.  This will definitely change your tracking rates, but it can not be saved for another session.
Don W


Re: saving the tracking change to the controller

Don W
 

Hi Gary,
In ServoConfig when changing the Equatorial Rate, you then must both "Send Configuration to Controller" and "Save Controller Configuration to Flash ROM".

When you run SiTechexe and watch the value for RA, it won't change the RA value shown at the bottom of the SiTech window nor in the SkyView display.  The only way to check if the rate has actually changed is to track a star in the sky.

However there is another way to modify the tracking rate (separate from ServoConfig), in SiTechexe you can use Offset Tracking Rates in the Features Tab.  This will definitely change your tracking rates, but it can not be saved for another session.

Don W

581 - 600 of 33597