OnStep fails completely!!!


Thomas Westerhoff
 

Hi Howard,

I don't know what to do anymore. Mine OnStep shows an absolutely inexplicable behavior. There are several errors that I would like to address here.


1. how can I turn off the automatic meridian flip. No matter what I do, after the restart it is active again.



2. in the Config.h I have entered the following for the limits

    #define AXIS1_LIMIT_MIN               -180 //   -180, n. Where n= -90..-270 (degrees.) Minimum "Hour Angle" for Eq modes.      Adjust
                                          //         n. Where n=-180..-360 (degrees.) Minimum Azimuth for AltAzm mode.
    #define AXIS1_LIMIT_MAX               180 //    180, n. Where n=  90.. 270 (degrees.) Maximum "Hour Angle" for Eq modes.      Adjust
                                          //         n. Where n= 180.. 360 (degrees.) Maximum Azimuth for AltAzm mode.

nevertheless in SkyPlanetarium a hemisphere is shown to me as not accessible.When I change the Pier Side in SkyPlanetarium, the dashed area jumps to the other side. Unfortunately, this change is not executed in OnStep. With we dimmer pier side West is displayed in the webinterface and in the smarthandcontroller.

in the Config.h of my old Steueurng I had at  #define AXIS1_LIMIT_MIN 180  a positive value of 180 in it and it has worked.  But this is no longer possible with the 5.1v. I can not compile the program because I am told that the value must be between -90 and -270. In the Web interface of the SmartWebServer I can not ente a value greater than 180.

In any case, the whole thing leads to the fact that the pier side switching no longer works cleanly for me.  I need a possibility to set the pier side manually at the beginning and it must not change until I tell OnStep.
On my GEM telescope I have no counterweight, but on the counterweight stand another telescope. The axis is continuous and provided with an encoder. So if I use the one telescope, I have to choose Pier Side West. I must also select Pier Side West when I use the opposite telescope. Only when I manually make a flip, then I have to switch and exactly here the automatic pier side switching of the OnStep constantly interferes. The main problem is then just that the DE encoder is then evaluated incorrectly and since I verwedne absolute encoders suddenly the encoder zero point is no longer correct.  

--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 

First thing to do is forget about version 5.x, use the beta.

At times the master branch can be pretty bug free and tested, this isn't one of those times, and in-fact I plan to drop the master entirely so no work will be done on it.


Howard Dutton
 

In the beta and master branch one must also keep in mind that many of the axis settings in Config.h are the defaults, once you enable runtime configuration (in the SWS) those settings are overridden by the runtime ones read in from NV/EEPROM.


Howard Dutton
 

On Sun, Apr 25, 2021 at 04:21 AM, Howard Dutton wrote:
In the beta and master branch one must also keep in mind that many of the axis settings in Config.h are the defaults, once you enable runtime configuration (in the SWS) those settings are overridden by the runtime ones read in from NV/EEPROM.
Even if you've never entered new values for AXIS1_LIMIT_MIN and _MAX from the "Config" webpage all it takes is enabling runtime settings (on that page) and all future changes of those in Config.h will be ignored.  Ignored unless you turn off runtime configuration or press the button to reset that axis's settings to the defaults at which point the Config.h settings will be applied.


Thomas Westerhoff
 

Hello Howard,
The errors refer to the thread I had already started here. However, I have noticed that the whole thing seems to be a bit more complex. Therefore, I had deleted my post in the other thread and restarted here further
https://onstep.groups.io/g/main/topic/how_can_i_fix_the_pier_side/82331786?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,82331786

My Config.h file is attaced
#define SYNC_CURRENT_PIER_SIDE_ONLY    ON
#define PIER_SIDE_SYNC_CHANGE_SIDES   ON
#define PIER_SIDE_PREFERRED_DEFAULT  EAST

This is the Mount with the two telescopes on each side.



As I use the Newton on the right side most of the time preferedPiersSide for me is EAST. EAST is also displayed to me when I turn on the controller in this orientation (say south). But as soon as the values of the AS37 absolute encoders are read in, the pier side jumps to WEST and can no longer be changed. By the way, this was not always the case! 
I recently had a thread here in which I wrote about the encoder problems. That has settled. I had synchronized the telescope to the sun (in the southwest) in the late afternoon and then zeroed the encoders. There everything was in order (at least apparently). The correct coordinates were displayed and the pier side was EAST.
Then I aligned the telescope to Regulus in the late evening and noticed that the absolute encoders were still a bit inaccurate. I centered Regulus, synchronized OnStep to Regulus and zeroed the encoders again. Then I moved to Aldebaran (far to the southeast) and measured the deviation between encoder and real position there. Also there the pierside was still on OST. Now it becomes interesting. I have now centered Aldebaran and synchronized OnStep to it to have a starting point for measuring in the opposite direction. Probably the pierside jumped to WEST, but I didn't pay attention to that. I then zeroed the encoders again. Afterwards I adjusted the AXISx_ENC_TICKS_DEG in the Smartwebserver according to the measured deviation. By the way, this was only possible by reflashing the ESP8266 and not via the web interface!
Now I drove the telescope manually again in the proximity of Regulus the RA agreed amazingly well, however not the DE. Now I have determined that there is something wrong. When turning the DE axis to the south, suddenly the declination increased, which is exactly the wrong direction. This is also normal, as I then noticed that the pierside was WEST and OnStep assumed that I had done a meridian flip. But I did not. Since then the pier side is "always" WEST, no matter what I do, as soon as the encoders deliver values after connecting the ESP8266 with OnStep.  
Surprisingly, I can't turn off the meridian flip either. I tried this via SkyPlanetatium, but in the web interface it is still displayed ON. The same applies to the setting of the piersife, which can be set to EAST, WEST, Use ASCOM. When I click there, nothing at all happens at the Onstep. WEST, always WEST. :-(


--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 

1. I'd turn off the SWS "from" limits, they aren't suitable for how you are attempting to use OnStep, it has to sync to the encoders every time.
#define AXISn_ENC_DIFF_LIMIT_FROM OFF

2. The inability to change the encoder AXISx_ENC_TICKS_DEG at runtime is due to SWS protective checks to keep silly values from being set.  They were too restrictive, should be fixed now.

3. I have no confirmation of what version of OnStep is being used.

4. I don't know what the meridian limits or min/max limits are.


Thomas Westerhoff
 

Hi Howard,

I have checked out the aBeta branch and also downloaded the latest version of SWS. I have also set #define AXISn_ENC_DIFF_LIMIT_FROM OFF. Unfortunately the result was the same as before.

But I noticed something different. I looked again at the first picture in this thread and there the axes have very high values. So I loosened the encoders, aligned the telescope to the south about the intersection of meridian and equator, turned the encoders to about 0 and reattached them. Already by this the pierside jumped to EAST, as I wanted it. Even after I synced the telescope to the sun and zeroed the encoders, east remained.
You had written that the function getInstrPierSide() determines the pier side based on the positions of the axes. Is it possible that this function could not handle the high axis values I had before? Now it looks like this.  


I think I can work with this condition. What I haven't tried yet, of course, is to swing the complete telescope around when I want to observe to the northwest, for example. I will do that sometime in the next few days.

My limits are set to 177. I cannot enter values above 180 in SWS. So something is still wrong with the range check. If I enter a value of 180, then in Sky Planetarium the whole sky is hatched. That is surely not wanted so or?


--
Thomas Westerhoff
Kirchheim Observatory /Germany
http://sternwarte-kirchheim.de/
https://www.facebook.com/VolkssternwarteKirchheim/


Howard Dutton
 

On Mon, Apr 26, 2021 at 05:53 AM, Thomas Westerhoff wrote:
My limits are set to 177. I cannot enter values above 180 in SWS. So something is still wrong with the range check. If I enter a value of 180, then in Sky Planetarium the whole sky is hatched. That is surely not wanted so or?
It's a bug in Sky Planetarium, darn polygon fills there are a tricky thing to get right.  I will investigate but need time, I have a new compiler and so other new bugs here need addressing before I can even begin to look at that.


Howard Dutton
 

On Mon, Apr 26, 2021 at 05:53 AM, Thomas Westerhoff wrote:
You had written that the function getInstrPierSide() determines the pier side based on the positions of the axes. Is it possible that this function could not handle the high axis values I had before? Now it looks like this.
Valid encoder range is +/- 360 degrees, if it exceeds that then yes you have an issue.


Howard Dutton
 

I've noticed the SWS set zero function (absolute encoder only) doesn't handle the encoder reversal properly, I think.

I'll test tonight and then patch as required.


Howard Dutton
 

A heads-up, the SWS main branch has some new work on encoders (among other things) that may impact stability.

I branched off a SWS beta before making those changes and that should be used until we have time to prove the main branch is ok.


András
 

Hello Thomas,

can you tell me which hardware you used to handle the encoder and the external drivers (I suppose)?

I tried it on a MaxESP but it is sensible to the levels and will not start with the external driver connected.
A CNC3 is better but the Wemos ESP8266 has problems handling the encoders, the wifi fails to init normally.


Howard Dutton
 

On Wed, Jul 21, 2021 at 03:43 AM, András wrote:
can you tell me which hardware you used to handle the encoder and the external drivers (I suppose)?

I tried it on a MaxESP but it is sensible to the levels and will not start with the external driver connected.
If you could elaborate, such as details about the hardware attached to the MaxESP3, I might be able to comment.