Date
1 - 20 of 39
Problem with absolute encoder AS37
|
Hello, Howard,
I had already written at other places that I can't get my AS37 encoder to run and I had the assumption that it is because of the low supply voltage. But now I took a look into the code and found out that the ESP8266 is actively sending a clock on the MA line. But it does not do that for me. I just measured this with the oscilloscope. Here is my Config.h, which is very similar to the original Config.h. Otherwise the ESP8266 runs without any problems. The web server works as well as the output of debung info via the USB port. What could be the reason for this behaviour? -- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|
|
I don't really know why, but I get some values displayed in the webserver, although I don't measure any usable signal on the lines. But the values, which are shown to me are complete nonsense. Either there are utopian high values or "***Fault***".
-- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|
|
Howard Dutton
Same software + same hardware = same result: something isn't the same over there.
Not that I think this is the cause of the problem, but this is a 23bit encoder so (2^23)/360 ticks per degree not 22.222: #define AXIS1_ENC_TICKS_DEG 23301.688
|
|
|
|
Howard Dutton
You really have it wired correctly right?
(A/CW/MA) & (B/CCW/SLO.)
|
|
|
|
Hello Howard, Another Question:
|
|
|
|
On Wed, Dec 2, 2020 at 07:17 AM, Thomas Westerhoff wrote:
I've never seen a fault indication with the current software here... except when I unplug the encoder. 1. It's probably not accurate enough and 2. there is no facility in the software to do that.
|
|
|
|
Howard Dutton
On Wed, Dec 2, 2020 at 07:37 AM, Howard Dutton wrote:
On Wed, Dec 2, 2020 at 07:17 AM, Thomas Westerhoff wrote:I could add to the software a re-try count, say up to three successive reading attempts are ignored before giving up and flagging the failure.
|
|
|
|
On Wed, Dec 2, 2020 at 07:37 AM, Howard Dutton wrote:
1. It's probably not accurate enoughWell the encoder has a 23bit resolution so there are theoretical 23301.688 ticks per deg. 11650.844 is the correct value that works for me. 23301.688 results in 6h (RA) value difference when turning the encoder 180 deg. Ok. 11650.844 ticks per degree gives a resolution of 0.3089 arcsecs per tick and this is extremely precise. What would happen if I set the "Max angular distance (Encoders vs. OnStep)" to 1 arcsec with this encoder directly mounted on the RA axis? With a periodic error this difference would be achieved if the tehoretical position (from motor coordinates) is different from PE induced encoder values of 1 arcsec. Will the sync simply overwrite the internal coordinates with the encoder coordinates or will the motor move faster or slower to compensate the difference? -- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|
|
On Thu, Dec 3, 2020 at 04:24 AM, Thomas Westerhoff wrote:
Well the encoder has a 23bit resolution so there are theoretical 23301.688 ticks per deg.Accuracy = +/- 80 arc-seconds according to the datasheet.
|
|
|
|
Howard Dutton
On Thu, Dec 3, 2020 at 05:35 AM, Howard Dutton wrote:
On Thu, Dec 3, 2020 at 04:24 AM, Thomas Westerhoff wrote:My encoder works properly with the 23301.688 value.
|
|
|
|
Howard Dutton
On Thu, Dec 3, 2020 at 05:37 AM, Howard Dutton wrote:
On Thu, Dec 3, 2020 at 05:35 AM, Howard Dutton wrote:I wonder if yours is slightly different, what is the exact model#?
|
|
|
|
Hello Howard,
it's an AS37-H39B-B12S The fact that the encoder has an accuracy of +-80 arc seconds is something I didn't realize. But I wonder why then a resolution of 23bit is used. That is completely unnecessary. Or are there still encoders in the series that are more precise than the AS37? -- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|
|
Howard Dutton
On Thu, Dec 3, 2020 at 07:55 AM, Thomas Westerhoff wrote:
The fact that the encoder has an accuracy of +-80 arc seconds is something I didn't realize. But I wonder why then a resolution of 23bit is used. That is completely unnecessary.Still useful in some applications I'm sure since it can register a very small movement. I'm just not so sure it'd be useful for tracking correction. And the 80 arc-seconds is "with electrical correction" (whatever the heck that is) and at 25°C. To play the devils advocate there might be enough underlying accuracy to do something with but I'm really not sure. It's tricky to tell what's going on when you don't have an uber accurate device to conveniently compare it against. Or are there still encoders in the series that are more precise than the AS37?Not that I see in the datasheet.
|
|
|
|
Howard Dutton
For the cost and what it does it's still pretty darn impressive.
Just wondering do you have the battery backup attached and if so does your encoder forget its position when powered off?
|
|
|
|
Howard Dutton
On Thu, Dec 3, 2020 at 08:26 AM, Howard Dutton wrote:
Just wondering do you have the battery backup attached and if so does your encoder forget its position when powered off?Note the encoder doesn't forget its angular position 0 to 360 degrees (0 to 8388608 counts or half of that in your case) I'm talking about the multi-turn position. So if the angle is 720 degrees and you power off it ends up near zero or 360, that sort of thing.
|
|
|
|
On Thu, Dec 3, 2020 at 08:26 AM, Howard Dutton wrote:
Just wondering do you have the battery backup attached and if so does your encoder forget its position when powered off I made a video this demonstrate what happens if battery is attached. Multi-turn postioning I will investigate now.
|
|
|
|
So here is my second video with multi-turn. Multi-turn may be a problem but I think this is unimportant to me because I do no multiturn on our large mount. That would wind up the cables :-)
https://www.youtube.com/watch?v=nFyPrTZbb3k -- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|
|
Howard Dutton
On Fri, Dec 4, 2020 at 04:09 AM, Thomas Westerhoff wrote:
Multi-turn may be a problem but I think this is unimportant to me because I do no multiturn on our large mount.OnStep doesn't, or shouldn't, allow Axes to exceed +/- 360 degrees. That still allows situations where certain users would need that battery on the encoder to work... though the vast majority wouldn't require it AFAIK just make sure the encoder is positioned properly during installation so the code disk doesn't cross zero (home for each axis is at 180 degrees for the encoders.)
|
|
|
|
Hello, Howard,
I tried a little bit more and found out the following. When I turn the encoder everything works fine until I reach the value 1000 (degrees?). In the code in the Command.ino the -999.9 and 999.99 is also set as limit. Then I get the message MSG: CMD_CH_B "SX40.1004.075070", Error parameter out of rangeInterestingly, it is not possible to turn back the encoder to get back into the valid range. I have to set it to zero via the web-interface. Then it counts again. Couldn't you just set the range of values to a very high value in Command.ino, because if the encoder is not directly connected to the axis, but with a gear ratio, then it can do much more rotations than the one. -- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|
|
Hi,
After the AS37 encoders worked great at home in the experimental setup on the desk with an older OnStep firmware version (i think it was 4.22), I added such encoders to the large mount in the observatory. The conversion lasted a few weeks because of mechanical adaptions and in this context I have also provided the OnStep control with the latest firmware to be up to date. The cables to the encoders are now 1 meter (RA) and 2 meter (DE) long. But now I have the problem that only occasionally valid data come from the encoders. Something seems to be wrong with the communication (see video). It is also the case that I can only synchronize the telescope at the moment when BOTH encoders do not return an error. Otherwise, the sync is incomplete, that is, either only the RA or the DE coordinate is taken over or none at all. Could there be a problem with longer cables? What is specified in the BISS hardware specification? During the troubleshooting I also found also some new entries in the Config.h files. Is there also a suitable documentation for them? https://youtu.be/MZa9IgqORoE Here is my Config.h from the WiFi directory. // ENCODER SUPPORT ----------------------------------------------------------------------------------------------------------------- #define ENC_AUTO_SYNC_DEFAULT ON // ON, Automatically sync Encoders to OnStep. Option #define ENC_AUTO_SYNC_MEMORY OFF // OFF, ON Remember automatic sync setting across power cycles. Option #define AXIS1_ENC BC_BISSC // OFF, CWCCW, AB, BC_BISSC. RA/Azm Axis (A/CW/MA) & (B/CCW/SLO.) Option #define AXIS1_ENC_REVERSE OFF // OFF, ON to reverse the count direction. Adjust #define AXIS1_ENC_TICKS_DEG 33650.1731 // 22.222, n, (ticks/degree.) Encoder ticks per degree. Adjust #define AXIS1_ENC_DIFF_LIMIT_TO 300 // 300, n, (arcsec.) Minimum diff. between encoder/OnStep for sync. to OnStep. Adjust #define AXIS1_ENC_DIFF_LIMIT_FROM OFF // OFF, n, (arcsec.) Maximum diff. between encoder/OnStep for sync. from OnStep. Adjust // For absolute encoders, leave off when setting Zero, then enable. #define AXIS2_ENC BC_BISSC // OFF, CWCCW, AB, BC_BISSC. Dec/Alt Axis (A/CW/MA) & (B/CCW/SLO.) Option #define AXIS2_ENC_REVERSE OFF // OFF, ON to reverse the count direction. Option #define AXIS2_ENC_TICKS_DEG 49259.08495 // 22.222, n, (ticks/degree.) Encoder ticks per degree. Adjust #define AXIS2_ENC_DIFF_LIMIT_TO 300 // 300, n, (arcsec.) Minimum diff. between encoder/OnStep for sync. to OnStep. Adjust #define AXIS2_ENC_DIFF_LIMIT_FROM OFF // OFF, n, (arcsec.) Maximum diff. between encoder/OnStep for sync. from OnStep. Adjust // For absolute encoders, leave off when setting Zero, then enable. // ENCODER RATE CONTROL #define AXIS1_ENC_RATE_CONTROL OFF // OFF, ON Rate control for RA high resolution encoder. EQ mounts only. Infreq #define AXIS1_ENC_INTPOL_COS OFF // OFF, ON enables cosine compensation feature. Infreq #define AXIS1_ENC_RATE_AUTO OFF // OFF, n, (Worm period in seconds.) Adjusts avg encoder pulse rate to account. Option // For skew in the average guide rate over the last worm period. Option #define AXIS1_ENC_BIN_AVG OFF // OFF, n, (Number of bins.) Enables binned rolling average feature. Option Do I need ENC_AUTO_SYNC_MEMORY if my AS37 encoders are battery buffered and stores the position in internal memory? When I switch it ON then I will get ALWAYS the same coordinates after repowering OnStep regardless of what position the telescope was in when I turned it off. Apparently a value was stored at some point and is now always retrieved. ENC_AUTO_SYNC_DEFAULT ON: Does this mean that OnStep automatically gets the position data of the encoders cyclically, or that the encoders get the Onstep coordinates transmitted cyclically? What does zeroing the absolute encoder via the web interface? -- Thomas Westerhoff Kirchheim Observatory /Germany http://sternwarte-kirchheim.de/ https://www.facebook.com/VolkssternwarteKirchheim/
|
|
|