Still a beginner, but I thought I'd give my take
To verify the quality of my guiding, I like to do the following test.? I try to get the polar alignment as accurate as possible and disable guiding (i.e. guiding assistant in PHD2).? I minimize dec drift as much as possible to simulate what a "perfect" guided sub would look like.? If I take that dec RMS error, and assume I got the same error in RA, I can calculate a reasonable limit on guiding performance based on seeing conditions.
With my skies, I often see numbers like 0.5" on dec.? This would result in a total RMS error of 0.7" if I assumed the RA error was the same.? The RA axis is never going to be that accurately guided, so for more realistic numbers I assume my RA is about 1.5x worse (based on experience) resulting in a total RMS error of about 0.9" in this example.
I am guessing that a lot of people are hitting their seeing limits like me.? One day I'll get a chance to verify what guiding performance looks like with a mount with absolute encoders, but my guess is that I will only get closer to approaching RA=dec error.
Lately, I am finding my subs get ruined most by wind...
Thanks,
Dwight
|
As a rule of thumb, without adaptive optics you will not get better resolution for apertures larger than 8".? So for visual, a 6" frac will be as good as a 12" SCT for almost every day of the year.? Of course resolution is not everything, light flux matters too.? For planetary observing imaging at 120+ Hz we depend on lucky seeing so the stacker picks the frames for which the Dawes limit matters.? So yes, it matters.
PS I made a mistake, 130/30 is not 0.25 but more like 0.4 but the conclusion remains that 0.7 is not good enough.
|
Derek et al
If you live in anywhere but space, your viewing with air turbulence is about 1" at best. I'd say of all the parameters, the air turbulence limits is far more than mount accuracy. What say you?
Chuck
On Sunday, June 13, 2021, 12:30:09 PM PDT, Paul Kanevsky <yh@...> wrote:
Hi Derek,
You raise some good points. It is important to remember that RMS guiding error while important, is just one measurement that tells only part of the story. The ultimate goal is the best possible resolution of the image, and that depends on much more than just guiding.
Regards,
? ? -Paul
On Sun, Jun 13, 2021 at 01:52 PM, Derek C Breit wrote: The REAL question is WHY?? ? PHD2 guides to a fraction of a pixel *and* most everyone has seeing that is not good enough to realize such an improvement in encoder resolution.. Add in the size of the imaging chip, Nyquist /proper sampling)and.. ? WHY?? It¡¯s a semi rhetorical question, but there is also ¡°Why should I not be happy with *my* 0.7¡± rms guiding?¡± i.e what am I missing (aka teach me) that makes people want more.. What imaging theory points to needing 0.2¡± rms guiding?? I mean I understand inventing, tinkering, etc.. ? I see people ¡°struggling¡± with the adjustment of spring loaded mounts, changing encoder resolution, or swapping out 25:1 for 50:1 gearboxes.. Frankly I am *GLAD* I have my 2 piece worms.. My rms values are exceedingly stable, my imaging scale is at 0.5¡±.. Even if I switch out my perfect 130mm refractor for my less than perfect 12¡± SCT to increase resolution, why would my 0.7¡± guiding not be ¡°pretty darn good¡±?? ? I don¡¯t mean to disparage anyone, I want to know what I am missing.. Whether we are talking guiding or pointing, why isn¡¯t a 1/2 arcsecond sufficient, especially considering seeing (environmental, as well as local).. ? Derek ? ? Page 31 of the Gemini-1 users manual has a table. It says the G11 and? GM8 have 6400 steps per worm revolution (25 gearbox x 256 motor encoder revolution).? There are 360 degrees per revolution and the G11 ring gear has 360 teeth, so that's one degree per worm revolution.? So each degree having 3600 arcsec per degree is divided by the steps per worm revolution that is 6400.? ? So that's 3600/6400 arcsec per step = 0.56 arcsec per step.?? As for reasons not to go with a higher motor encoder: the Gemini-1 clock is 1.5 MHz (per the G-1 manual).? I don't know the clock speed of a G-2.? You might find the encoder detector chip unable to keep up with the codes at a high slew rate....but that's only a factor of 2...so it might be just fine.? It's worth a test.? Getting the motor encoder out is a major soldering challenge.? Replacing the fragile encoder disk is easier but really...these motors are hard to get apart and repairs of them are rare.? (Brendan Smith and David Partridge are expert in this subject.? I tried and had no success.)?? To double the step accuracy, you can also replace the 25:1 gearbox with a 50:1 gearbox.? [I'm only familiar with the McLennan versions.? The McLennan company didn't recommend using their 50:1 gearbox with a HiTorque motor because it's shaft is ~3.2 mm and the small 50:1 gearbox pinion gear is 3.0 mm...they thought enlarging the pinion ID would get too close to the teeth.? Alternatively, Stuart Hutchins recommended using the motor rotation and a file to reduce the shaft OD to 3.0 mm to fit the pinion ID.? Stuart thinks this is the best way to keep everything I have not tried that idea...the question is what is best to modify. ].? ? Here is my math:?(360*3600)/(256*25*360) = 0.5625 arc sec per step.
This seems rather coarse. We have 2.3 million steps per rotation of the Ra shaft. From talking with Sideral Technologies high end mounts have a greater number of steps. If it is possible to change the encoder used in the motor this could be increased to 4.6 or even 9.2 million steps. So 0.28 or 0.14 arc sec per step. This I think should have a significant impact on improving guiding performance, especially in the Dec axis, as right now the minimum correction is 0.56 arc sec. My imaging system is 0.76 arc sec per pixel. I would welcome any thoughts. Perhaps Losmandy can comment on wether the controller will work with a higher resolution encoder. They cost around $65 per axis to do the upgrade, so well worth running a test I feel.
|
The Dawes limit for a 130 mm telescope at say, 6000 Angstrom is 6e-7/130e-3=4e-6 radians or 4e-6*180/pi=240e-6 degrees or 240e-6*3600=1".? An RMS of 0.7" would be fine for that.? A 12"=300 mm SCT has a Dawes limit of 130/300=0.25 of the above which is 0.25" so 0.7 is not good enough.
|
Hi Derek,
You raise some good points. It is important to remember that RMS guiding error while important, is just one measurement that tells only part of the story. The ultimate goal is the best possible resolution of the image, and that depends on much more than just guiding.
Regards,
? ? -Paul
On Sun, Jun 13, 2021 at 01:52 PM, Derek C Breit wrote:
The REAL question is WHY??
?
PHD2 guides to a fraction of a pixel *and* most everyone has seeing that is not good enough to realize such an improvement in encoder resolution.. Add in the size of the imaging chip, Nyquist /proper sampling)and..
?
WHY?? It¡¯s a semi rhetorical question, but there is also ¡°Why should I not be happy with *my* 0.7¡± rms guiding?¡± i.e what am I missing (aka teach me) that makes people want more.. What imaging theory points to needing 0.2¡± rms guiding?? I mean I understand inventing, tinkering, etc..
?
I see people ¡°struggling¡± with the adjustment of spring loaded mounts, changing encoder resolution, or swapping out 25:1 for 50:1 gearboxes.. Frankly I am *GLAD* I have my 2 piece worms.. My rms values are exceedingly stable, my imaging scale is at 0.5¡±.. Even if I switch out my perfect 130mm refractor for my less than perfect 12¡± SCT to increase resolution, why would my 0.7¡± guiding not be ¡°pretty darn good¡±??
?
I don¡¯t mean to disparage anyone, I want to know what I am missing.. Whether we are talking guiding or pointing, why isn¡¯t a 1/2 arcsecond sufficient, especially considering seeing (environmental, as well as local)..
?
Derek
?
?
Page 31 of the Gemini-1 users manual has a table. It says the G11 and? GM8 have 6400 steps per worm revolution (25 gearbox x 256 motor encoder revolution).? There are 360 degrees per revolution and the G11 ring gear has 360 teeth, so that's one degree per worm revolution.? So each degree having 3600 arcsec per degree is divided by the steps per worm revolution that is 6400.? ? So that's 3600/6400 arcsec per step = 0.56 arcsec per step.??
As for reasons not to go with a higher motor encoder: the Gemini-1 clock is 1.5 MHz (per the G-1 manual).? I don't know the clock speed of a G-2.? You might find the encoder detector chip unable to keep up with the codes at a high slew rate....but that's only a factor of 2...so it might be just fine.? It's worth a test.? Getting the motor encoder out is a major soldering challenge.? Replacing the fragile encoder disk is easier but really...these motors are hard to get apart and repairs of them are rare.? (Brendan Smith and David Partridge are expert in this subject.? I tried and had no success.)??
To double the step accuracy, you can also replace the 25:1 gearbox with a 50:1 gearbox.? [I'm only familiar with the McLennan versions.? The McLennan company didn't recommend using their 50:1 gearbox with a HiTorque motor because it's shaft is ~3.2 mm and the small 50:1 gearbox pinion gear is 3.0 mm...they thought enlarging the pinion ID would get too close to the teeth.? Alternatively, Stuart Hutchins recommended using the motor rotation and a file to reduce the shaft OD to 3.0 mm to fit the pinion ID.? Stuart thinks this is the best way to keep everything I have not tried that idea...the question is what is best to modify. ].?
?
Here is my math:?(360*3600)/(256*25*360) = 0.5625 arc sec per step.
This seems rather coarse. We have 2.3 million steps per rotation of the Ra shaft. From talking with Sideral Technologies high end mounts have a greater number of steps. If it is possible to change the encoder used in the motor this could be increased to 4.6 or even 9.2 million steps. So 0.28 or 0.14 arc sec per step. This I think should have a significant impact on improving guiding performance, especially in the Dec axis, as right now the minimum correction is 0.56 arc sec. My imaging system is 0.76 arc sec per pixel. I would welcome any thoughts. Perhaps Losmandy can comment on wether the controller will work with a higher resolution encoder. They cost around $65 per axis to do the upgrade, so well worth running a test I feel.
|
The
REAL question is WHY??
?
PHD2
guides to a fraction of a pixel *and* most everyone has seeing that is not good
enough to realize such an improvement in encoder resolution.. Add in the size
of the imaging chip, Nyquist /proper sampling)and..
?
WHY??
It¡¯s a semi rhetorical question, but there is also ¡°Why should I
not be happy with *my* 0.7¡± rms guiding?¡± i.e what am I missing
(aka teach me) that makes people want more.. What imaging theory points to
needing 0.2¡± rms guiding?? I mean I understand inventing, tinkering,
etc..
?
I
see people ¡°struggling¡± with the adjustment of spring loaded
mounts, changing encoder resolution, or swapping out 25:1 for 50:1 gearboxes..
Frankly I am *GLAD* I have my 2 piece worms.. My rms values are exceedingly
stable, my imaging scale is at 0.5¡±.. Even if I switch out my perfect
130mm refractor for my less than perfect 12¡± SCT to increase resolution,
why would my 0.7¡± guiding not be ¡°pretty darn good¡±??
?
I
don¡¯t mean to disparage anyone, I want to know what I am missing.. Whether
we are talking guiding or pointing, why isn¡¯t a 1/2 arcsecond sufficient,
especially considering seeing (environmental, as well as local)..
?
Derek
?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Michael Herman
Sent: Saturday, June 12, 2021 6:47
AM
To: [email protected]
Subject: Re: [Losmandy_users_io]
Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do
this?
?
Page 31 of the Gemini-1 users manual has a table. It says the G11
and? GM8 have 6400 steps per worm revolution (25 gearbox x 256 motor encoder
revolution).? There are 360 degrees per revolution and the G11 ring gear
has 360 teeth, so that's one degree per worm revolution.? So each degree
having 3600 arcsec per degree is divided by the steps per worm revolution that
is 6400.? ? So that's 3600/6400 arcsec per step = 0.56 arcsec per
step.??
As for reasons not to go with a higher motor encoder: the Gemini-1
clock is 1.5 MHz (per the G-1 manual).? I don't know the clock speed of a
G-2.? You might find the encoder detector chip unable to keep up with the
codes at a high slew rate....but that's only a factor of 2...so it might be
just fine.? It's worth a test.? Getting the motor encoder out is a
major soldering challenge.? Replacing the fragile encoder disk is easier
but really...these motors are hard to get apart and repairs of them are
rare.? (Brendan Smith and David Partridge are expert in this
subject.? I tried and had no success.)??
To double the step accuracy, you can also replace the 25:1 gearbox with
a 50:1 gearbox.? [I'm only familiar with the McLennan versions.? The
McLennan company didn't recommend using their 50:1 gearbox with a HiTorque
motor because it's shaft is ~3.2 mm and the small 50:1 gearbox pinion gear is
3.0 mm...they thought enlarging the pinion ID would get too close to the teeth.?
Alternatively, Stuart Hutchins recommended using the motor rotation and a file
to reduce the shaft OD to 3.0 mm to fit the pinion ID.? Stuart thinks this
is the best way to keep everything I have not tried that idea...the question is
what is best to modify. ].?
?
Here is my math:?(360*3600)/(256*25*360) = 0.5625 arc sec per
step.
This seems rather coarse. We have 2.3 million steps per rotation of the Ra
shaft. From talking with Sideral Technologies high end mounts have a greater
number of steps. If it is possible to change the encoder used in the motor this
could be increased to 4.6 or even 9.2 million steps. So 0.28 or 0.14 arc sec
per step. This I think should have a significant impact on improving guiding
performance, especially in the Dec axis, as right now the minimum correction is
0.56 arc sec. My imaging system is 0.76 arc sec per pixel. I would welcome any
thoughts. Perhaps Losmandy can comment on wether the controller will work with
a higher resolution encoder. They cost around $65 per axis to do the upgrade,
so well worth running a test I feel.
|
Re: Spring Loaded Worm Question
I added Belleville washers at the bottom of the motor side screw.? It leaves a small margin? for correct operation.? It is not difficult to feel how far you can go before it gets too tight to keep the blocks from moving.? The idea is to have no gap by adding the Belleville spring.
|
Re: ASCOM Device Hub or not
To be clear: Gemini.NET ASCOM driver works with 64- and 32-bit applications. It executes as a stand-alone 64-bit process on Windows 64 and as a 32-bit process on Windows 32-bit.
The driver is never loaded into other applications, so it doesn't care about the number of bits for those applications.
If there's an issue with TheSkyX 64-bit, it is not the number of bits. There's something else in the set up or configuration that's causing this. Regards, ? ? ?-Paul
On Sat, Jun 12, 2021 at 10:20 PM, Greg Crawford wrote:
Hi Brian,
?
Just recently, I disassembled my Losmandy mount and replaced it with a mount with greater weight-carrying capacity, so I cannot double-check this. However, from memory, I connected the ASCOM Device Hub to the ASCOM Gemini NET driver. I then connected TheSkyX 64 bit to the ASCOM Device Hub. That seemed to work fine and get around the 64 bit issue.
?
Greg
?
?
yeah that's fair.
TSX is it's kind of it's own thing, especially the 64 bit version.?
Greg how do you connect - i would assume??-> TSX and TSX 2X ascom to all other apps?
?
On Fri, Jun 11, 2021 at 11:13 AM Greg Crawford <rover53@...> wrote:
Edward,
?
The answers given to you may not apply well to all users, especially those who use TheSkyX Pro 64 bit. I found that the Gemini driver did not connect with the 64 bit version. It threw an error. I could bypass the error by using the ASCOM Device Hub. I am not particularly literate with software parlance, but I found using he ASCOM Device Hub overcame problems with using the 64 bit version of TheSkyX.
?
Greg
?
?
In my previous GM8/Gemini-1, I connected PHD2, imaging tool, and planetarium to the mount via POTH to share the mount connection.?
Now, with my new G11/Gemini-2,??I connect to the mount with Ethernet and?assumed I still needed to use ASCOM Device Hub to share the mount connection.
?
Based on some reading today, I am questioning whether this true. Do I need the device hub software at all??
How are you all connecting multiple clients to the ASCOM Gemini driver via Ethernet in the simplest manner. I am transitioning to NINA so my target suite is PHD2/NINA/Cartes du Ciel.
Thank you,
--
Edward
?
--
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
On Sat, Jun 12, 2021 at 11:17 PM, John Kmetz wrote:
Will adding a more precise encoder on the motor really do anything for better guiding on these mounts? This will only better tell the computer brain where the rotational axis of the motor shaft is, but will that translate to a better known position of the RA (or Dec) axis? In between motor axis and sky coordinate axis you have so many meshing surfaces. On the G11, there is motor pinion gear, gear box gear #1 outer gear, gearbox gear number #1 inner gear, gearbox gear #2, spur gear #1, spur gear #2, left and right Oldham coupler mating surfaces, and finally worm to ring gear contact. The number of contacting surfaces here is at least 7 if I am counting right.
Each gear to gear mating is going to have its own slight backlash and periodic error, though worm and ring will have the largest contribution. Even if the motor turns more precisely will that motion be transmitted proportionally to the RA axis without be absorbed by the gear slop??
Well, yes, it does matter.? (Like in my case) Let's assume that you have a very very slight polar misalignment so that the DEC generally drifts in one direction.? And also that seeing is pretty good so the axis is not constantly correcting back and forth.? In that case, the DEC motor will give a pulse every x minutes in the same direction.? It will take up all the backlash slack and elasticity.? Eventually, the telescope will move the same amount as required for every step.
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
You can buy AVAGO HEDS Broadcom encoders...and I think even though they are stamped different numbers It'll fit ok.
like 9100#F00 for 256tick (for Gemini motors) ........I find it hard to believe that you have to replace the "#F00"? optical pick-up when changing to a 512Ktick? encoder disc "9100#I00".? I mean as a manufacturer.....why would you limit or make them different its all about costs...I'd suspect the optical pick-ups are much the same they just change the code wheel
Pretty sure I suggested this some time back to someone who needed an encoder pick-up and could not get the "F00" so I said get the "I00"....
Would be interested if it works for you Aliexpress is a source of these Broadcom parts.....though 256 tick at 2mm shaft appears to have disappeared.? The Min shart is 3mm these days.
cheers
--
Brendan
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
Just thinking out loud:
Will adding a more precise encoder on the motor really do anything for better guiding on these mounts? This will only better tell the computer brain where the rotational axis of the motor shaft is, but will that translate to a better known position of the RA (or Dec) axis? In between motor axis and sky coordinate axis you have so many meshing surfaces. On the G11, there is motor pinion gear, gear box gear #1 outer gear, gearbox gear number #1 inner gear, gearbox gear #2, spur gear #1, spur gear #2, left and right Oldham coupler mating surfaces, and finally worm to ring gear contact. The number of contacting surfaces here is at least 7 if I am counting right.
Each gear to gear mating is going to have its own slight backlash and periodic error, though worm and ring will have the largest contribution. Even if the motor turns more precisely will that motion be transmitted proportionally to the RA axis without be absorbed by the gear slop? If anything, there should be a high precision encoder directly on the RA axis itself. I think some older mounts tried these but they did not work that well. Perhaps the tech has changed to the point where a new encoder disc and sensor could be added there for better control.
Just re-watched this video on the new?Skywatcher EQ8Rh-Pro:?
Although this is a much more expensive mount at $7000 just for the mount head, perhaps some of this tech could be transferred to the Losmandy mounts in the future. Firstly get rid of the present gear system and add a high torque motor and belt drive directly to the RA (and Dec) axis. If I am understanding how these Skywatcher mounts operate, the tracking is ultra-precise without even using a guide camera; the computer just knows where the scope is pointing right from the encoders. Wouldn't that be nice for a Losmandy mount? But of course anything for a price.
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
During periods of good seeing, I can have very good guiding in DEC, due to the DEC axis not having to do anything.? (Kind of a back-handed compliment, LOL)? The RMS value is.. I dunno, less than 0.5 arc-sec?? But then I would occasionally see a jump in DEC from +0.5 to -0.5, or something like that.? I figured that it must be stiction in the axis, but maybe it was the discrete step sizes after all?? This is for a G8 axis)
At the same time, during these periods of good seeing, the RA guiding is always a bit worse than DEC.? Could it be the axis banging away at 15/0.56=27 times a second?? (G11 RA axis)? Nah, that seems too fast.
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
It's really the step control accuracy we are after here. I do think finer control is key to better guiding if you are shooting for sub arc second performance. I think I'll just have to buy two encoders and give it ago as this does not appear to have been done before?
|
Re: ASCOM Device Hub or not
Hi Brian,
?
Just recently, I disassembled my Losmandy mount and replaced it with a mount with greater weight-carrying capacity, so I cannot double-check this. However, from memory, I connected the ASCOM Device
Hub to the ASCOM Gemini NET driver. I then connected TheSkyX 64 bit to the ASCOM Device Hub. That seemed to work fine and get around the 64 bit issue.
?
Greg
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]>
On Behalf Of Brian Valente
Sent: Saturday, 12 June 2021 5:26 AM
To: [email protected]
Subject: Re: [Losmandy_users_io] ASCOM Device Hub or not
?
yeah that's fair.
TSX is it's kind of it's own thing, especially the 64 bit version.?
Greg how do you connect - i would assume -> TSX and TSX 2X ascom to all other apps?
?
On Fri, Jun 11, 2021 at 11:13 AM Greg Crawford <rover53@...> wrote:
Edward,
?
The answers given to you may not apply well to all users, especially those who use TheSkyX Pro 64 bit. I found that the Gemini driver did not connect with the 64 bit version. It threw an error. I could bypass the error by using the ASCOM Device Hub. I am not
particularly literate with software parlance, but I found using he ASCOM Device Hub overcame problems with using the 64 bit version of TheSkyX.
?
Greg
?
?
In my previous GM8/Gemini-1, I connected PHD2, imaging tool, and planetarium to the mount via POTH to share the mount connection.?
Now, with my new G11/Gemini-2,??I connect to the mount with Ethernet and?assumed I still needed to use ASCOM Device Hub to share the mount connection.
?
Based on some reading today, I am questioning whether this true. Do I need the device hub software at all??
How are you all connecting multiple clients to the ASCOM Gemini driver via Ethernet in the simplest manner. I am transitioning to NINA so my target suite is PHD2/NINA/Cartes du Ciel.
Thank you,
--
Edward
--
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
@Brenden
I think you might be onto something with the slew rates. If you change the encoder to say 512 do all the speed rates have to be halved? While the gear settings are per axis this does not seem the case the speeds. This implies one would have to do both the RA and Dec motors. You may be right about not being able to increase encoder resolution. There has to be a reason why they did not use a higher res encoder in their design.
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
No soldering required. You can buy a 512 or 1024 encoder with a 1/8th inch shaft plus the associated sensor for $65. The sensor is a plug in component. I spoke with a technician at US Digital and the current sensor will not works only with the 256 encoder wheel. The question I have is will the Gemini II support a higher resolution encoder? I do not thing it an issue with clock frequency but what the Genimi II software will allow you to do.?
I am experimenting with McLennan gear boxes from RS components in the U.K. Funny they cost the same as the much inferior gear box from Losmandy but are unfortunately metric. I failed miserably to enlarge the pinion gear hole from 2mm to the required 1/8" for the 25:1 gear box. I just bought a chucking reamer and a new pinion gear to have another go at it, but I might have to go to a machine shop to do the work. The 9.2s pinion gear error jumped from under 0.1 arcs to a whopping 0.6 arcs that is how sensitive things are. There error appeared close to a sine wave on the PHD2 graph. ?It seems much easier to change out the encoder that the gear ratio of the gearbox for the reasons you stated.?
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
yes but he's saying the sampling accuracy of this .56 is at 1/4 electronically controlled..
You can instruct the motor to do lots of things in the settings.?? But no better than .56 without changing encoders....and while its interesting I've yet to be 100% sure any better tick accuracy would benefit.....and the question of how many ticks at fastest slew the system can compute.
--
Brendan
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
Sadly not true. If you step the motor it will be 0.56 arcs. There is no micro stepping with a servo motor. The whole purpose of the encoder to ensure the motor moves one step in a closed loop fashion. You cannot intruct the motor to move a quarter step as far as I'm aware.?
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
Research of the threads finds...this from Rene' many years back...2001!? wow!
I do understand the feelings of the users who experienced the accuracy problems caused by the wrong cables, but I'm sure this will be transient.The motors are DC motors with encoders attached. Mechanical gear ratio is 360:1 (worm gear) times 25:1 (motor gears), resulting in 9000:1.Since a DC motor is no stepper, the resulting "step" size derives fromthe encoder attached to the motor (256 ticks), giving 2,304,000:1 (0.5625) arcsec resolution. This "step" size is fully maintained by the Gemini main CPU software, allowing positioning of the motor axes to givethis 0.5625 arcsec accuracy. Considering the play in the motor gears and the coupling, about 20 arcsec repeatable pointing should be the real world accuracy value possible.For smooth tracking, the servo processors internally work at 4 times thenominal resolution (.14 arcsec) resulting in very smooth, vibration-freetracking at very low current consumption.There is a huge difference between stepper motor control and servo motor control. Rene'
In short yes .56 arc sec step for G11 but in quadrature.....is at 1/4 this resolution = 0.14 arcsec per step -- Brendan
|
Re: Changing the servo motor encoders from 256 to 512 or 1024. Any reason not to do this?
hmmm my cals might be NQR the Lvl 4 manual says .56 arc sec but The encoders act in quadrature giving 4 times the resolution =.145arc sec Also remember the system has a prescaler divisor for systems division see lvl 4 manual pg 31.? Page 45 mentions step accuracy but doesn't mention quadrature.? As to the encoders.?? I have often thought of just this but I think there may be an issue with "motor jitter" (especially on the old 3 pole motors) in that rotational movement "jitters" and higher resolution encoders may miss-count because of this jitter.?? I am not sure but this would be my bet.? I do know the new motors (5 pole) jitter less as do the maxon. The other issue is I'm not sure if the IC devices are fast enough to handle the signal frequency if encoder resolution is increased.?? I suspect it could handle a step to 512K ...but it may induce more jitter.?? I'm sure the G2 DsPIC33s can handle greater resolution ..not so sure of the old G1 PEEL devices and PIC42Cs. Lastly obtaining encoders with the correct shaft ID is imperative.?? I know Aliexpress sells many encoder wheels (obvious its like a US digital 1" wheel") I have found it hard to find 256 tick encoders but plenty of 512K tick units.? Consider at sidereal rate its (for a G11) 256 ticks in 9.56s...is 27 ticks a second and at 1200X slew that's 32,133 ticks per second the encoder Dspic33 has to read at. 512K in same conditions is 54 ticks per second...@1200X is 64,267 ticks per second the Dspic? has to read at.? Double.? IMHO it can do this...but really unsure of using higher... The PWM freq of the servo loop is around 32Khz which would match the 256K encoder almost 1:1 at max slew.?? I suspect greater resolution above this is not possible. I think this is the key...its PWM sampling drive at 32KHZ matches the 256K encoder at max slew....sounds like they did this for an engineering reason.?? Obviously you can lower max slew. All in all...in reality I do not know but suspect it may be ok to 512K on the newer G2.?? Rene' may be best to answer this...indeed I'd like to know as well.? FWIW.... I guess the question is why change to higher resolution when seeing is at best 7-8 time (if not more) step resolution -- Brendan
|
Paul Kanevsky