Date   

Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Roland Christen
 


'm afraid to repeat these tests as there could be potential problems with the hardware,
The "Motor Stall" warning will occur when unsafe limits are exceeded. This is not a warning that something is wrong with the motor or electronics, it is simply telling you that the software has turned off the power to the motors to prevent your scope from being damaged. At this time we use the same error code for all situations where the motor power has been turned off. It probably could be changed to indicate not "motor stall" but "motor power deactivated".  However, we have many other software challenges right now and this one will have to wait a bit. Be assured that nothing bad has happened to your electronics or the motors.

Rolando


-----Original Message-----
From: Leo Shatz <leonid.shatz@...>
To: main@ap-gto.groups.io
Sent: Fri, Jul 31, 2020 6:22 am
Subject: [ap-gto] Testing homing limits resulted in motor stall errors with Mach1 #APCC

Hello,

Recently I had a very good remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:
 
- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.
 
- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).
 
I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz
 


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Dale Ghent
 

So, the primary cause of a motor stall is an external mechanical force that is countering the direction that the motors are driving the axes in question. Sometimes it's electrical, such as your power source (such as a battery) furnishing too little voltage to the mount.

Since you didn't mention verifying the physical condition of the mount and the stuff you have hanging off of it, have you checked balance of both RA and dec and looked for any cable wrapping or snags that could be catching and preventing one of the axes from turning past a certain point?

You assertion that the issue might be software-based is misinformed - APCC and the ASCOM driver sends commands to the mount controller to slew and move to the requested point; so the software on your computer is not responsible for actually driving the motors themselves every micrometer of the way. It's impossible for APCC to be directly responsible or the cause of a motor stall.

Describe your mount's load in more details and the work you have done to verify balance, as well as any other mechanical configuration issues that would be the most likely causes of a stall event.

/dale

On Jul 31, 2020, at 7:22 AM, Leo Shatz <leonid.shatz@gmail.com> wrote:

Hello,

Recently I had a very good remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:

- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.

- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).

I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz


Re: Testing homing limits resulted in motor stall errors with Mach1 #APCC

Leo Shatz
 
Edited

I'm using APCC Pro version 1.8.3.1 and VCP4-P01-13 firmware.


Testing homing limits resulted in motor stall errors with Mach1 #APCC

Leo Shatz
 
Edited

Hello,

Recently I had a very productive remote session with Howard Hedlund from A-P, who helped me to setup meridian and homing limits. I did some tests following the session and I've got some issues I'd like to raise here:

Meridian flips were fine, I didn't run in any problems with flips going the wrong way, as long as the red telrad circle was staying within meridian limits. However, I had motor stall event triggered a couple of times in the following situations:
 
- I've defined an action of "stop tracking and slewing and park in place" in homing limits and let the mount perform unsafe pier flip. When it hit the homing limit (well before colliding with the pier), the mount stopped, the message saying that limit was reached and dialog box flushing. Few moments after that, since SGP was configured to perform parking on its own, it tried to perform parking but failed as mount was already parked. I've seen a yellow flashing sign in APCC indicating an error and there was freshly triggered "motor stall" event.
 
- I did the slow slew (at rate x200) to move CWs up higher until it reached the homing limits, the mount stopped again with a message from APCC and there was another motor stall event.

After both cases I was able to unpark the mount and perform slewing in both axis (without manually turning power off/on to the mount).
 
I'm afraid to repeat these tests as there could be potential problems with the hardware, although it looks to me more like a software glitch under these circumstances. I hope it's not actually caused by a physical issue with the mount, but possibly a software issue where there is some race condition in detecting abrupt change in motor speed and control signal stopping the slewing/tracking at horizon limit.

Leo Shatz
 


Re: APPC refraction correction question

Craig Young
 

Thanks Ray.  Here is the pnt file.  It consists of 22 samples along a DEC arc of -15 degrees from HA -3 to the meridian.  With refraction correction turned off the Offset error in HA is -170.12.  With refraction correction disabled the model terms are reasonable numbers.  With refraction correction enabled you will see the model terms go really bad.  So the model seems good without refraction and samples along a DEC arc, but when refraction is turned on the model is off the scale.  Something dramatic happened.  But, if you remove the offset terms then the model is back to being realistic.  Am anxious to see what happened.

Craig


Re: APPC refraction correction question

Ray Gralak
 

Post your PNT file here for analysis. I'll let you know why your model is acting that way.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Thursday, July 30, 2020 11:08 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPC refraction correction question

That is what I said in my first post to this thread, that others are using this temporarily, but it would be useful to
summarize the process for others who are not familiar with the technique to try it out on their system. Which brings
me back to my original question, why is it that when I turn on refraction that it throws the Offset error from 100 or so
to 100 million or so .. I cannot envisage any change due to refraction that would cause the HA error to jump so
high. It might be a sign that there is problem in the refraction calculation to the model terms.

Craig


Re: APPC refraction correction question

Craig Young
 

That is  what I said in my first post to this thread, that others are using this temporarily, but it would be useful to summarize the process for others who are not familiar with the technique to try it out on their system.  Which brings me back to my original question, why is it that when I turn on refraction that it throws the Offset error from 100 or so to 100 million or so .. I cannot envisage any change due to refraction that would cause the HA error to jump so high.  It might be a sign that there is problem in the refraction calculation to the model terms.

Craig


Re: APPC refraction correction question

Ray Gralak
 

Actually, you can try DEC ARC modelling now. It is very simple, fast and easy to setup. Here is what you do:
I believe Dean and a few others have already been creating models that way, so it's nothing new.

It's just that the tracking rates produced from those data points result from a full-sky model. The actual Declination Arc Tracking feature does not even use the full-sky model terms and hasn't been released yet.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Thursday, July 30, 2020 9:12 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPC refraction correction question

Dean,
Actually, you can try DEC ARC modelling now. It is very simple, fast and easy to setup. Here is what you do:
1. Run APCC (I am running latest version (v1.8.2.1)
2. Click Pointing Model tab
3. Click APPM button
4. Setup APPM as you always do
5. click Measurement Points tab
6. DEC settings:
DEC spacing: 1 degree,
DEC offset: 1 degree,
Min DEC: set this to the DEC arc (e.g., -25 declination),
Max DEC: same number (e.g., -25)

7. RA settings
Right Ascension spacing: 2 degrees (this will define the # samples along the arc to be tested)
RA Offset: 0
Min Hour Angle (east): -3 (set these to the span of the arc)
Max Hour Angle (west): 3

8. Click Show Points button, this will show a map with the DEC arc displayed

You can change the length of the arc and the number of samples along the arc. I found 20 samples or so was
excellent but have also tried 10 points and that works also. So far I have only tried sampling the East sky but on
next clear night will try West sky.

9. Click Start button on Run tab.

It won't take long to measure the samples and when finished it is saved to disk as a .pnt file. You can later change
the name of the pnt file to be something like "DEC ARC -25 degrees". When finished you will be asked to
immediately load the model .. click yes. Your DEC ARC model is now running. You can build up a library of these
and load them as needed. For example, I created a specific DEC ARC for a star cluster and another for a galaxy
where I took lots of images over several nights along the same DEC arc.

Use the GoTo/RECAL tab to move the scope to any point along the DEC arc, e.g., I start at -3 HA. Then begin
imaging .. I can now do 5 minute images with 1 arcsec accuracy. Then, if you enable Refraction Correction you
may notice the tracking rate goes out of whack. Simply disable the top two model terms (Offset Error) in the
Pointing Model tab and you should see the tracking correction go back to normal, but different due to refraction
correction. When I do this I can now do 10 minute images with less than 1 arcsec tracking error.

I suspect Ray's new feature will automate a lot of this, but you can try it out now manually.

Craig


Re: APPC refraction correction question

Craig Young
 

Dean,
Actually, you can try DEC ARC modelling now.  It is very simple, fast and easy to setup.  Here is what you do:
1. Run APCC (I am running latest version (v1.8.2.1)
2. Click Pointing Model tab
3. Click APPM button
4. Setup APPM as you always do
5. click Measurement Points tab
6. DEC settings:
  DEC spacing: 1 degree,
  DEC offset: 1 degree,
  Min DEC: set this to the DEC arc (e.g., -25 declination),
  Max DEC: same number (e.g., -25)

7. RA settings
  Right Ascension spacing: 2 degrees (this will define the # samples along the arc to be tested)
  RA Offset: 0
  Min Hour Angle (east): -3 (set these to the span of the arc)
  Max Hour Angle (west): 3

8. Click Show Points button, this will show a map with the DEC arc displayed

You can change the length of the arc and the number of samples along the arc.  I found 20 samples or so was excellent but have also tried 10 points and that works also.  So far I have only tried sampling the East sky but on next clear night will try West sky.

9. Click Start button on Run tab.

It won't take long to measure the samples and when finished it is saved to disk as a .pnt file.  You can later change the name of the pnt file to be something like "DEC ARC -25 degrees".  When finished you will be asked to immediately load the model .. click yes.  Your DEC ARC model is now running.  You can build up a library of these and load them as needed.  For example, I created a specific DEC ARC for a star cluster and another for a galaxy where I took lots of images over several nights along the same DEC arc.

Use the GoTo/RECAL tab to move the scope to any point along the DEC arc, e.g., I start at -3 HA.  Then begin imaging .. I can now do 5 minute images with 1 arcsec accuracy.  Then, if you enable Refraction Correction you may notice the tracking rate goes out of whack.  Simply disable the top two model terms (Offset Error) in the Pointing Model tab and you should see the tracking correction go back to normal, but different due to refraction correction.  When I do this I can now do 10 minute images with less than 1 arcsec tracking error.

I suspect Ray's new feature will automate a lot of this, but you can try it out now manually.

Craig


Re: APPC refraction correction question

Ray Gralak
 

Yes, the full sky model works, as evidenced by many unguided images produced with various setups. However, when only a portion of the sky is sampled the accuracy of the model depends on the solidity of the setup and the proper matching of pointing terms to the actual mechanics of the mount.

But the Declination Arc Tracking model is entirely different and is not based on the full sky model's pointing terms.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Thursday, July 30, 2020 6:39 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPC refraction correction question

Call it what you want Ray, the fact is it does work, as long as you do not use the Offset Error terms with refraction.
And it is a lot easier to say than "Building an APPM model by sampling only points along a declination arc". I think
the users get the idea.

If enabling refraction changes the model terms then is it correct that APPM goes back through all the sample
points and adjusts them for refraction effects? If so, these would be minor changes, a few arc seconds at most
for each sample when sampling above 45 degrees in the sky, and fitting the adjusted data points should still be
very close to what the terms are without refraction. Not the huge changes I see.

Craig


Re: APPC refraction correction question

Dean Jacobsen
 

On Thu, Jul 30, 2020 at 05:56 PM, Ray Gralak wrote:
First, you are not creating "DEC ARC" models because that version of APCC has not been released.
Now that is interesting.  I will be looking forward to that feature.
 
--
Dean Jacobsen
http://astrophoto.net/wp/
Image Gallery - http://astrophoto.net/wp/image-gallery/
Astrobin - https://www.astrobin.com/users/deanjacobsen/ 


Re: APPC refraction correction question

Craig Young
 

Call it what you want Ray, the fact is it does work, as long as you do not use the Offset Error terms with refraction.  And it is a lot easier to say than "Building an APPM model by sampling only points along a declination arc".  I think the users get the idea.

If enabling refraction changes the model terms then is it correct that APPM goes back through all the sample points and adjusts them for refraction effects?  If so, these would be minor changes, a few arc seconds at most for each sample when sampling above 45 degrees in the sky, and fitting the adjusted data points should still be very close to what the terms are without refraction.  Not the huge changes I see.

Craig


Re: APPC refraction correction question

Ray Gralak
 

Can anyone, who is using APPM to build DEC ARC models,
First, you are not creating "DEC ARC" models because that version of APCC has not been released. You are creating a full-sky model based on a limited area of the sky.

Second, unchecking/checking any option will re-calculate the best-fit values from the supplied data. "Best-Fit" depends on the quality of the data and how the model terms match the mechanicals. If you have a scope with unmodeled behavior then the terms can vary significantly.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of PEMPro V3: https://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Thursday, July 30, 2020 5:38 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPC refraction correction question

Can anyone, who is using APPM to build DEC ARC models, confirm that enabling refraction correction changes
the model terms significantly. You can easily run this test during the day by slewing to any location in the sky and
toggling the state of the refraction correction checkbox and noting the change in the Offset Error-Hour Angle term,
located at the top of the model terms list.

I am trying to find out if this is an error in APCC or something in my system. As discovered above, if I remove the
Offset Error term when refraction correction is enabled, then the tracking rates look reasonable. But I am not sure if
refraction correction is now accurate when removing the model term. I thought I would check with others before
reporting this formally as a software error in APCC.

Craig


Re: APPC refraction correction question

Craig Young
 

Can anyone, who is using APPM to build DEC ARC models, confirm that enabling refraction correction changes the model terms significantly. You can easily run this test during the day by slewing to any location in the sky and toggling the state of the refraction correction checkbox and noting the change in the Offset Error-Hour Angle term, located at the top of the model terms list.

I am trying to find out if this is an error in APCC or something in my system.  As discovered above, if I remove the Offset Error term when refraction correction is enabled, then the tracking rates look reasonable. But I am not sure if refraction correction is now accurate when removing the model term.  I thought I would check with others before reporting this formally as a software error in APCC.

Craig


Re: A query about AP mounts / APCC & Indi #APCC

David Trappett
 

Thanks Ray,

I appreciate there are only so many hours in a day.

I'll have a look at Voyager and fingers crossed their scheduling engine is released in the near future for a Windows solution.

Regards,

DT


Re: Questions about how to test my Mach2 indoors #Mach2GTO

lmbrabec@...
 

Thanks Dean!  I'm going to try this out next time out.  All the best, Scott


Re: How To Check That Your AE's Are Doing Their Job

Tony Benjamin
 

Wasn’t asking how to turn them on…but how to properly check that they are working correctly J

 

 

Tony

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of uncarollo2 <chris1011@...> via groups.io
Sent: July 30, 2020 4:04 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] How To Check That Your AE's Are Doing Their Job

 

That's one way. You can also turn them on using our encoder utility or via APCC.

 

Rolando

 

 

 

-----Original Message-----
From: Tony Benjamin <tonybenjamin@...>
To: main@ap-gto.groups.io
Sent: Thu, Jul 30, 2020 4:08 pm
Subject: [ap-gto] How To Check That Your AE's Are Doing Their Job

I've had my AE's for a few months now but have never checked to see that they are doing what they should be doing.

Do I just run PEMPro - with a proper calibration - (with PEC Off) and watch the line - which should be pretty much flat?


Re: How To Check That Your AE's Are Doing Their Job

Roland Christen
 

That's one way. You can also turn them on using our encoder utility or via APCC.

Rolando



-----Original Message-----
From: Tony Benjamin <tonybenjamin@...>
To: main@ap-gto.groups.io
Sent: Thu, Jul 30, 2020 4:08 pm
Subject: [ap-gto] How To Check That Your AE's Are Doing Their Job

I've had my AE's for a few months now but have never checked to see that they are doing what they should be doing.

Do I just run PEMPro - with a proper calibration - (with PEC Off) and watch the line - which should be pretty much flat?


Re: Renishaw encoders

Roland Christen
 

You have a much bigger ring that has an adjustable carrier that we trammed in here. It will be very accurate and you haven't lost anything in terms of accuracy.

Rolando

-----Original Message-----
From: sbasprez via groups.io <beneckerus@...>
To: main@ap-gto.groups.io
Sent: Thu, Jul 30, 2020 3:30 pm
Subject: Re: [ap-gto] Renishaw encoders

I have a 1100GTO that originally had a CP3 controller that was upgraded to a CP4.  I later installed the Renshaw encoders.  You stated:  "The ring error is mapped, stored in the CP controller and becomes part of the mount's control loop system".  Since my encoders were not factory installed by AP, this mapping has never been performed and stored in my CP4.  How much accuracy is lost by not having this mapping?

Greg


How To Check That Your AE's Are Doing Their Job

Tony Benjamin
 

I've had my AE's for a few months now but have never checked to see that they are doing what they should be doing.

Do I just run PEMPro - with a proper calibration - (with PEC Off) and watch the line - which should be pretty much flat?

5681 - 5700 of 77737