I can’t imagine the satisfaction in getting a bug fixed. Im very thankful for it.

I don’t see a setting to enable that feature? Is it in Ekos or in the INDI driver?

I guess I would wonder why the routine wouldn’t judge the first picture taken and adjust from there as opposed to relying on a stored value that may or may not be relevant.

I use the same PA (during these tests) night after night and it does a 180 flip each time.

I don’t see a setting to enable that feature?
There is no such setting, the initialization should be activated by default.
But the problem is timing: I had to introduce a delay because very often the rotator did not return its current state. Thus if you do not see this message, the routine is not able to fetch the initial state of the rotator. (See also capture log: "Rotator Settings: Reading initial raw angle failed.") If you can confirm this behaviour, I have to find another way for initializing the angle.

This does not explain the 180°-rotation though! Which flip policy do you use? If the reference image was taken on the opposite pier side and flip policy is "Preserve Position Angle" the rotator will always turn about 180°.

ADDENDUM: When did you take the screen shot in the attachment? Directly after a new start of EKOS?

Hi,

Is there any way to do plate solving and syncing without issuing a goto in 3.9.6? As of now all options end in the error message "No Target - Please pick an object."
Since my motor controller (EQDrive Unitrack) is completely erratic, when it comes to goto (just happily goes round and round until the end of time), I was relying on manual slew-platesolve-correct cycles, that are now not possible anymore, since it is not allowed to do any action.

Lehel

Hey Toni,

Yea, that screen shot is right after startup of the server/connections made. I checked tonight and there is no message on any of my module pages that match your initial alignment angle. I'm assuming that's why it's defaulting to something random. How do you create a delay on connection? I can't seem to find a setting for that. Or, is a manual thing where you connect to the focuser individually?

This wasn't an issue in previous iterations... I feel like it's a bug related to how it's figuring out rotation.

Is there something specific I can turn on inside the align module or some other tool that would help ID what I'm seeing for you?

Is there any way to do plate solving and syncing without issuing a goto in 3.9.6?
Hi Gyuro
I suppose you mean version 3.6.9, right? There was an edition of this version with this "feature" I introduced by mistake. Meanwhile there is a new edition of 3.6.9 without this restriction. So an update of KStars should bring back the accustomed behaviour.

How do you create a delay on connection?
The delay is hardcoded, so there is no possibility to change it. But even such a facility would not correct the initialization, because the "Goto"-field does not return an OK (the led button stays gray!). In some respects this is flaw of the driver. I suppose however, that a majority of the rotator drivers have this problem and I'll try to circumvent this weak point with a change in the code of the EKOS rotator module.

Toni,

I think your implementation of the rotator is fundamentally flawed... while I agree that it should be the driver that does the work, it needs a 'seed'. Aka the first plate solve needs to populate what the current is into the driver for that session. As an example, I take my camera off and shift the angle... it needs to be updated. I shouldn't have to manually do that.

On the flip side, I can 'sync' my rotator. Perhaps there needs to be a warning that there has been no 'sync' this session and that unexpected movements will occur.

My mount defaults to a random -114 degrees. Why? I dunno. But, if your implementation relies on better device drivers, that probably should be worked out with the developers before implementing. What it breaks is scheduler automation.

Hi Chris
There are a lot of discussions about the features a rotator driver should have or not have. Here is an interesting one from the past. One of the crucial points seems to be the so called "homing", which sets a rotator like NiteCrawler typically to instrumental position 0. Perhaps this could be a worth a try?

Of course a proper functioning of your NiteCrawler - as all rotators - depends on reading the initial angle when EKOS is starting. As I said the problem with the NiteCrawler driver is the fact that it does not set the control led to green (see below) and thus does not confirm the value in "Goto" angle field is correct. Currently the rotator module does read in the angle only if this is fulfilled.

I use the same PA (during these tests) night after night ..
Can you confirm that the displayed rotator angle of 129.18° in the "Goto" field corresponds to this PA? If this is the case, I can try to let the rotator module read in this value without checking the control led.

Hey Toni,

That value does correspond to the last sync'd value. It was set to something else previous before I did a 'sync' inside the driver and set it to that...

A pull request to correct the initialization routine for the rotator angle is underway.

Thanks Toni. I’d still send you a cup of coffee or something if you take donations. I know the problem was fairly tailored to a few of us.

Any idea on the timeline from pull to nightly build?

Jasem already merged the PR, so it shoudn't last long until it is in the nightly build.