Home sensors


rambro@...
 

Hello,
I have converted iOptron ieq45 HC8406.It's works very well. I used MAX ESP v3, wifi adeon , SHC, 400 stepper motors and 16:40 belt GT2 gears.
I made this for planed remote observatory.  Now I am trying with home sensors. I have glued magnetics straps and two hall sensors. I have one question.
How to channge code (beta) that before first goto mount first go home ?.  If I loose power during session I have manualy order mount to go home, then goto to object. If i goto to obejct without go home before, mount "think" is already at home and go to wrong position.   I can make automatic plate solve before goto but with wrong coordinates its dificult. Maybe I misunderstoodhome how to use home sensors ?.  Going to home position with sensors is working very well. Mount slow down and precisly point at home.
p.s. Sorry for my bad English

short test photo M3 (without calibration, L only, 20 x 1 min). RMS for two axis about 0.8" I had very similar result before conversion, but mount now has more features and no terrible iOptron bugs in firmware


Mark Christensen
 

Rambro,

First, if you lose power all bets are off unless you have set HOME as the PARK position.

If the Park position is set to be HOME then It is possible that after a power failure (which means the mount is in an unknown orientation) you can turn the mount back on and then explicitly command HOME and then UNPARK. If the EEPROM that contains the alignment data and park position (set using Set Park) is scrambled for some reason this won't work. But if the EEPROM data is good it should work.

Why would you want it to automatically home after power up? If the mount was Parked, then just UnPark. That would keep all your alignment data intact.

Finally, to reduce the risk of this happening, power the system of an UPS (Uninterruptable Power Supply). They also function as lightening and surge protectors.
Jesteś Anglikiem lepszy niż mój polski!
Mark Christensen


Martin Bonfiore
 

Rambro,

I had a similar expectation on how the HOME sensors would work after powering back up in order to reestablish a mechanical reference for the telescope and mount.  As I can best understand the design of Onstep, based on a number of discussion on this forum, the designers of Onstep have a different philosophy on PARKING/UNPARKING the mount. 

Personally, I would prefer to establish a mechanical reference when powering the telescope mount back up using the HOME sensors.  In my implementation, they are opto-interrupters with a few microns of repeatibility error.  On the other hand (based on my understanding which could be mistaken) the designers of Onstep chose to base the PARK/UNPARK operaton on an assumption that the mount and the relationship of the telescope to the mount did not change between power on and power off sessions. 

The case that the scope did not move is for most cases very reasonable in my opinion...any movement would require (for most implementations) back driving a worm gear which is typically not possible and/or bumping the scope such that any clutches slipped.  

While I accept that argument and certainly highly respect the designers (I could not have designed this system), I have been experimenting with changing the software (small modifications) in order to change the HOME with sensors operation to allow the homing after power up approach without needing to redo the alignment.  I am not sure where this will take me...understanding the code has not been easy for me, but certainly an interesting challenge and I have gained a great appreciation of what it takes to provide Onstep functionality.  I am no where close to sharing anything in that regard since my hacking is at the moment, not well understood or tested.


rambro@...
 

Thank you for replays. I will make this solution in Ekos starting script. I will add:
If mount is not parked goto home, home restet, etc. If mount is parked after power on run normal startup procedure.

I have to learn dbus interface to KStars. In onstep  wiki I found that if home sensor are used i dont have to align?. I always do plate solving so I don't need good model and super point acurracy before plate solve in Ekos. 


Howard Dutton
 
Edited

On Tue, May 25, 2021 at 07:43 AM, Martin Bonfiore wrote:
Personally, I would prefer to establish a mechanical reference when powering the telescope mount back up using the HOME sensors.  In my implementation, they are opto-interrupters with a few microns of repeatibility error.  On the other hand (based on my understanding which could be mistaken) the designers of Onstep chose to base the PARK/UNPARK operaton on an assumption that the mount and the relationship of the telescope to the mount did not change between power on and power off sessions. 

The case that the scope did not move is for most cases very reasonable in my opinion...any movement would require (for most implementations) back driving a worm gear which is typically not possible and/or bumping the scope such that any clutches slipped.  

While I accept that argument and certainly highly respect the designers (I could not have designed this system), I have been experimenting with changing the software (small modifications) in order to change the HOME with sensors operation to allow the homing after power up approach without needing to redo the alignment.  I am not sure where this will take me...understanding the code has not been easy for me, but certainly an interesting challenge and I have gained a great appreciation of what it takes to provide Onstep functionality.  I am no where close to sharing anything in that regard since my hacking is at the moment, not well understood or tested.
Think this should work in release-4.24 ...

Just find this line in OnStep.ino:
VLF("MSG: OnStep is ready"); VL("");

Then add this one under it:
goHome(true);

Having the mount do an un-commanded rapid motion on startup is not a feature I will be adding.

I understand the appeal of (the option for) doing a home operation before the first Goto and that doesn't seem especially worrisome to me, just takes more effort to stage the events so not trivial and so not something I'll add to 4.24.


Martin Bonfiore
 

Howard,

Thanks for the idea about adding the goHome(true)...I will give it a try..  I totally agree that an un-commanded rapid motion on startup should not be added and is not something I was looking for.  


rambro@...
 

  VLF("MSG: OnStep is ready"); VL("");
  #if (HOME_SENSE != OFF)
    if (parkStatus!=Parked) goHome(true);  // by RA
  #endif

How to add this to unpark procedure ?. It is not good idea to move mount during power on. Even if mount is not parked I can provide unpark command and goto home.