Date   

Re: ServoConfig/Ticks Determination Problem

Don W
 

Hi Raphael,

When you run the ticks measurement in Servo Config, you put the 360 degrees into the box.  When you are measureing the tics, whatever is in the box is probably wrong, since the data is not yet set into the controller.  Try YE's suggestion.
Don W


Re: ServoConfig/Ticks Determination Problem

Raphael T Vilardi
 

Hi Yann. Thanks for the suggestion. I'll try it and let you know. But what bugs me is that, the very first time I did the Ticks Determination it was working fine. It did the first full 360° CW cycle and showed the correct TPR. However, when it was doing the CCW, the AC power cord disconnect and I switched to a 12V power pack, that I’ve been using all the time. That's when the odd behavior started. Perhaps I should uninstall the Serco Config App and reinstall it. Unfortunatelly I won't be able to do it before next Friday. I'm loosing some rare clear skyes around here... best regards


Re: ServoConfig/Ticks Determination Problem

Yann-Eric Boyeau
 

Hi,

 

Does the mount move as it should if you just put manually 44,000,000 TPR in the number of ticks per revolution. ?

 

YE

 

 

De : Sitechservo@groups.io <Sitechservo@groups.io> De la part de Raphael T Vilardi
Envoyé : mercredi 5 mai 2021 09:11
À : Sitechservo@groups.io
Objet : Re: [Sitechservo] ServoConfig/Ticks Determination Problem

 

To be more clear: the scope would have moved 180º but the angles display would show 360º and 22,000,000 TPR


Re: ServoConfig/Ticks Determination Problem

Raphael T Vilardi
 

To be more clear: the scope would have moved 180º but the angles display would show 360º and 22,000,000 TPR


Re: ServoConfig/Ticks Determination Problem

Raphael T Vilardi
 

Hi Don

Thanks for the comments. However the situation is the following:  when I check  the box Azimuth and input 360° for instance and hit the second button, two things happen as the mount starts to move: 1) one can clearly see that the angles displayed do not correspond to the physical movement (I had a laser attached to the mount and pointed at a target hanging on the wall as the start and finish point and I could  easily track the red dot movement); for instance you are visually at, roughly 45° and the angles count would show 90° . 2)  the slew would stop at 180°, regardless of 360° number input, as if it would have completed the full circle. And the encoders TPR would also show the figure expected for a full circle. I’m pretty sure of this figure as I know the encoders quadrature ticks, the gearbox exact reduction and the main gear number of teeth (500 X 4 X 50 X 220 = 22,000,000). There is no way this number of TPR could be reached with a 180° turn. The system is actually counting both in double.

And if this data is  transferred to the Servo Controller, it could explain the strange behavior I've noticed yesterday; when hitting the go to button the telescope would slew and stop halfway as if it would have completed twice the angular distance between the starting point and the selected object.. How can I fix this?

Best regards
Raphael


Re: ServoConfig/Ticks Determination Problem

Don W
 

Hi Raphael,

Tics per rev is for 360 degrees.  In ServoConfig.exe, when you use Ticks determination, the RA defaults to 360 degrees.  However, there is a box labeled "Ending Degs" where you can put in 180° or any other setting.

So you have two choices:  either run ServoConfig ticks determination with 180° in that box, or simply go into "Edit Parameters" and put in twice the ticks/rev for RA.  Then you have to save the results to the controller and also to Flash memory.

Don W


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
>





941 - 960 of 33963