Hey All,
Yes, we were apparently looking at AtHome like the dome was Parked. This has been removed. We are still checking if the Dome is AtPark. I believe this should only return true when the dome is actually parked and NOT just when it’s at the park position (like AtHome does). This should resolve the need to slew off of the home point.
Will be out in the next 3.0 beta and we’ll also address this in 2.6.
Thanks,
Jared
Halleluiah and fantastic news, thank you very much Jared. I look forward to the next release, which should be imminent, my beta is about to run out!
Yeah!! This is great…awesome…to see this dome work as expected will be a gret Christmas gift!!
I do not think I have this problem (nexdome) but I’m still using 2.6.0.24
but during tracking my magnets typically don’t pass each other. But I’ve never noticed this stopping any other time.
Should I not update until resolved?
I DO WISH there is a way to keep SLAVE toggled… (auto toggle upon device connect?) Or another faster way to toggle it on maybe in the main menu display in the observatory mini window. As is - I have to open control panel and click OTHER
to access teh “SLAVE” toggle.
This isn’t what the ASCOM specification says. It says that any time the dome is close enough to the home position the AtHome property will be true.
I would absolutely NOT rely on ‘atPark’ to suggest the dome is parked. The ascom spec does have a park method, but, it does NOT have an unpark. This is a problem for trying to make an intelligent dome driver, because it’s vastly different than a mount where one expects the mount to throw an exception if it’s given a slew command when parked. Any slew commands to a dome will inherently move it away from the park position, and it cannot throw an exception to say ‘this is an error, i am parked’ because, there is no other way to ‘unpark’ it.
Even if this has been changed since I grabbed the spec and wrote the current driver, it’s the kind of change that’ll break all sorts of older software, so, I wont change the driver to honor park as a place to ‘stay parked’.
the AtHome return will return true any time the sensor is detecting home postion. Likewise, I would expect the AtPark to return true any time the dome is at the park postion. There really is no difference in getting there from a park command, or a slew command. Consider this scenario. Dome is sent to the park position by a valid slew command while tracking, and stops at the park position. Now for whatever reason, computer is restarted without restarting dome hardware. When the computer re-connects after drivers are re-initialized, the dome will be at the park postion, therefore it SHOULD return true for AtPark, as there is no way of knowing if it got there from a slew, or from a park command in the last session.
The worst case scenario for this, home and park are the same place. Dome ‘wakes up’ at the home postion, so, AtHoome must be true. There has been no park command issued, but, since we are at the home position, and it is the park position, then AtPark should also be true.
If ascom had a specific ‘unpark’ for the dome, this would be different and it could be done the way it should be done, once parked it stays there till unparked, but a driver has to assume it’s never truely parked because it cant be unparked. The only way to deal with this that follows everything, is to treat AtPark and AtHome essentially the same, return true any time the dome is at the position in question.
A quick report to say that I have just installed version 3.0.0.4 and initial testing shows that the dome slave problem has been solved. Fantastic, thank you Jared, you are a complete star. I am now very happy to give you my money!!
Gav.
Great news!! I will try it out tonight. Appreciate the quick response on this.