Re: RCX400 Primary Focus Questions
- Well....... maybe not!
Last night I was ready to change my optics from f6 (F8 with f6.3 converter). I
have various presets stored and was using f6. Before power up, I changed the
optics over to f8. After power up, I did a focus 'sync on preset' for the usual
f6 setup (of curse the telescope does not know about the change. I then
selected 'goto preset' for f8. The motors hit maximum and before I could hit
'mode' they had reached the stop and lost all my collimation. Clearly this
process is not correct. The loss of collimation has lost me a lot of time.
>Re: RCX400 Primary Focus QuestionsWow! This explains exactly what I have repeatedly noticed but had not
> Posted by: "P. Clay Sherrod" drclay@... drclay2002
> Date: Sun Oct 26, 2008 4:50 pm ((PDT))
>From session to session, the calibration is faulty. I have rarely seen the synchronized
>positions, particularly from one focus extreme to another, stay close from power cycles.
>There should be a re-sync of your first position at the beginning of each new power
>cycle or all presets will be continually and progressively off.
'twigged'. Presumably a check after power on is essential - but do we use 'sync
on preset' or must we re-define the current preset?
- Gday Rod
--- In RCX400@yahoogroups.com, "rcx400" <rodsrun@...> wrote:
> Is there any configuration setting that puts limits to the
> focus so it doesn't hit the stops -
Not that i can tell, and its not trivial, as if you enter the stops
and that blindly cuts the power, how do you get back out :-)
Meade use opto "stops" that fire well before the real hardstops hit
They also use several internal code based mechanisms to enter the
stops and walk back till they clear,
Ie for restoring defaults, calculating lash etc.
hence this effect cant be used to trigger a blind power kill.
I dont know if there is a secondary set of "physical" limit switches,
but based on feedback, i assume not
> I realize the scope doesn't always (ever?) understand where current
> focus is, but geez - I can't accept that this scope is designed to
> self-destruct its focus motors. Meade must have made SOME provision
> to protect the scope from its own exuberance when seeking a preset.
Yep, but i think they missed a bit :-)
If i read the code correctly
When you start a move via "goto preset" or :FP serially,
a separate routine is used, and it works in two stages.
Stage 1 just starts the motors "blindly" moving at full speed in the
required direction, then starts watching the encoder feedback.
When the corrector is within 0.55mm of target, it stops the motors.
In Stage 2 it recalculates how far each motor has to go to hit target.
It then uses a function that moves the motors individually by those
During this second move process, it watches the position and optos.
If any of the stops trigger, it kills the power and beeps.
Where the problem appears to comes in is stage 1
This loop has no stop detection, it appears to "assume" the request
was valid, and charges off into the valley of death.
Sooo, if a "goto preset" etc call requests the corrector to go past
the stops, it will try its best to do so.
Also, if the corrector is moving the "wrong way", and is > 0.55mm from
target, it will never stop either.
The first fault mode is what "appears" to be happening here.
> If Meade truly didn't provide for this, is there any way or program
> space to patch the firmware to sense a limit micro-switch at either
> end of the focus range?
If my understanding of the code is correct, it could be patched, but
i'm not sure how simple it would be.
Andrew Johansen Melbourne Australia
> --- In RCX400@yahoogroups.com, Lawrence Harris <lawrence@> wrote:
> > >Re: RCX400 Primary Focus Questions
> > > Posted by: "johansea" johansea@ johansea
> > > Date: Sat Nov 1, 2008 1:59 pm ((PDT))
> > >
> > >Gday Lawrence
> > >
> > >Just for info
> > >What were the values stored against each preset??
> > >Ie how far did it think there was between them
> > >How close was the corrector to the stop at the time?
> > >Which way did it go Out or Back.
> > >It may not be a runaway, but a controlled crash
> > >due to an incorrect datum.
> > >
> > >Als, there is an option to restore collimation from
> > >a default setting. That should get you back pretty close
> > >fairly quickly.
> > >
> > >Andrew Johansen Melbourne Australia
> > I did originally have these records listed, but I don't know now,
> although I
> > shall check them later. I can't really answer the other questions
> because I
> > simply don't know.
> > Collimation: yes I shall do this first thing next session. I should
> have done
> > it after the 'runaway' but forgot in the stress of the event. I did
> > and got things OK again. I took a series of f8 images using the SX
> AO unit and
> > I am very pleased with the results although the collimation software
> shows some
> > misalignment. When I do a 'restore default' I shall see how good
> the factory
> > data is - and also see whether it (hopefully) just moves the optics
> to the
> > offsets required.
> > Thanks for your interest and helpful suggestions :-)
> > Lawrence