Date   

Re: Piertech3 Adjustable Pier with AP1600 Experience

Dale Ghent
 

I think Bob's point is more along the lines of don't trust *only* software to keep the unwanted from happening. If you're going to automate roof closures, make sure that your roof control system has the appropriate *hardware* safety interlocks installed to prevent the unintentional guillotining of your telescope. This would mean things like making it physically impossible for the roof motor to run if the mount isn't in the correct orientation.

On Jan 10, 2022, at 12:03, Brian Valente <bvalente@...> wrote:

Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof.
I'm not sure what to make of advice not to fully use automation software from an automation software supplier 🤔

On Mon, Jan 10, 2022 at 8:43 AM Jerome A Yesavage <yesavage@...> wrote:
Yes, I have the Pier and I get fine images in all positions.

I park at P5, but Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof. If I use automation, I have to have the pier lower so the roof always clears the scope no matter what the mount position. Now Vito, says you can put a park position sensor on the controller, but I have never gotten this to work. I have the proximity sensor and an extra toggle for showing the pier down, but I cannot get the roof controller to take these inputs reliably. It will open and then raise the pier, but it closes before the pier is down (notta so good).

This is the proximity sensor:

https://www.amazon.com/gp/product/B07CWT7KW6/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

The toggle sensor is the same Honeywell that is used on my roof. Rock solid.

If any of you have this working reliably, please show me your wiring and settings on the roof controller. I fear I am doing something dumb (again).




--
Brian



Brian Valente
portfolio brianvalentephotography.com


Re: Piertech3 Adjustable Pier with AP1600 Experience

 

>>> Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof. 

I'm not sure what to make of advice not to fully use automation software from an automation software supplier 🤔

On Mon, Jan 10, 2022 at 8:43 AM Jerome A Yesavage <yesavage@...> wrote:
Yes, I have the Pier and I get fine images in all positions. 

I park at P5, but Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof.  If I use automation, I have to have the pier lower so the roof always clears the scope no matter what the mount position.  Now Vito, says you can put a park position sensor on the controller, but I have never gotten this to work.  I have the proximity sensor and an extra toggle for showing the pier down, but I cannot get the roof controller to take these inputs reliably.  It will open and then raise the pier, but it closes before the pier is down (notta so good). 

This is the proximity sensor:

https://www.amazon.com/gp/product/B07CWT7KW6/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

The toggle sensor is the same Honeywell that is used on my roof.  Rock solid. 

If any of you have this working reliably, please show me your wiring and settings on the roof controller.  I fear I am doing something dumb (again).



--
Brian 



Brian Valente


Re: Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

Dale Ghent
 

Just looking through your posts, my first inclination is to check the tracking rate that the AP ASCOM driver is reporting while this condition is happening and verify that it's in sidereal; not lunar, solar, or some other tracking rate. I just looked at the source code for Stellarium's TelescopeControl plugin and it does not manipulate tracking rates at all. PHD2 doesn't manipulate tracking rates at all, so if the driver is reporting a sidereal tracking rate and not some other or custom rate, then tracking rates can then be excluded from a possible cause.

As for your frustrations, I think one must appreciate the many-layered cake that astro software stacks are. This necessitates some solid demarcation of responsibility among software maintainers when it comes to these different components interacting between each other. In this case, things work fine when Stellarium isn't in the mix, but go south when it is. Since the stack is designed such that PHD2 should not have to do anything special if Stellarium (or any other particular item of software) is involved in running things, the first advice is to determine why the act of using Stellarium alters the situation.

There is often a "shoot the messenger" mentality because one piece of software is surfacing a bug or misconfiguration that exists in a different part of a kind-of-complex stack. The best way to debug these kinds of issues is to deconstruct things and first look at the common components such as the driver and verify that its reporting sane settings - it is, after all, the canonical source of information about the mount. There is also the completeness of the problem description to consider. There's often a tertiary actor involved that the user leaves out of the description because they think it's irrelevant, but that can very well not be the case.

On Jan 9, 2022, at 00:38, John Davis <johncdavis200@...> wrote:

Unfortunately the knee-jerk response from the PHD2 support forum is “oh it’s a Stellarium problem – go ask them” or they are trying to tell me I’m not using the AP ASCOM driver to communicate to Stellarium (I am).

As a software tester – I’m used to developers always assuming that it CAN’T be THEIR software that has the bug…. Sigh.





Seeing what you have experienced, I have seen some odd behaviors like that as well – not *exactly* the same – but cases where stars just start tracking off without any explanation.

I know that PHD2 is good – but I got to think that the new multi-star guiding code just might still have some bugs in it. I’m just skeptical that PHD2 has NOTHING to do with any of this.



I’ll let you know if I find anything else on another board.







From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Joel Short
Sent: Saturday, January 8, 2022 11:21 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin



Oh my word John! I MIGHT have observed something similar, but this is with a different mount (CEM120EC). When I first slew to near the meridian/celestial equator in order to do a PHD calibration, I get this:

<image001.png>


The stars keep trailing like this for over a minute until finally it somewhat stabilizes, but even then the stars will oscillate back and forth over about 5-6 star widths. This is definitely NOT expected behavior for this mount, and I've observed this a few times this evening. It is unnerving.

After reading your post I closed PHD and Stellarium, manually slewed to the same spot and immediately started PHD and started looping images (started within 5s of slewing to the spot). The stars stayed bang on immediately. No having to wait a minute for the mount to stop moving and no oscillation.



I can't say this is the same issue, but I'm certainly going to keep my eye on this and see where it goes. Thanks for posting this.

joel



On Sat, Jan 8, 2022 at 9:13 PM John Davis <johncdavis200@...> wrote:

Hello,

I have been seeing this problem for several months now, and I would like some input as to what the nature of the problem might be.


**NOTE: I have also sent this same post to the PHD2 support group **
Just thought I'd send it to the AP list too - in case someone here had experienced and solved the problem.

To summarize, I am seeing problems with PHD2 guiding - most often the RA tracking - when I am running a guiding session in PHD2 and have the mount also communicating with Stellarium via the Telescope Control plug-in.





Re: ASCOM Driver "freezing"?

Ray Gralak
 

There's not enough information to say for sure, but the most likely reason is the serial port hung. Are you using a USB/serial converter on a USB hub with a USB connection to your camera? If so, try moving the mount's USB cable to its own USB port on your computer.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of wbelhaven via groups.io
Sent: Monday, January 10, 2022 8:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] ASCOM Driver "freezing"?

I'm seeing the AP ASCOM driver "not responding" again, multiple times a night now. Seems the cable
replacement was not a permanent fix. Can someone please help? Can't really automate image capture with this
continuing to freeze up.

I just upgraded to the most recent version of the driver and ran it for a few hours without freeze. Are there any
bugfixes in the latest version that would address this, or is this just happenstance (again)? Any help would be
appreciated.

Thanks.


Re: Piertech3 Adjustable Pier with AP1600 Experience

Jerome A Yesavage
 

Yes, I have the Pier and I get fine images in all positions. 

I park at P5, but Bob Denny put the fear of God in me to not use ACP automation to park and then close the roof.  If I use automation, I have to have the pier lower so the roof always clears the scope no matter what the mount position.  Now Vito, says you can put a park position sensor on the controller, but I have never gotten this to work.  I have the proximity sensor and an extra toggle for showing the pier down, but I cannot get the roof controller to take these inputs reliably.  It will open and then raise the pier, but it closes before the pier is down (notta so good). 

This is the proximity sensor:

https://www.amazon.com/gp/product/B07CWT7KW6/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1

The toggle sensor is the same Honeywell that is used on my roof.  Rock solid. 

If any of you have this working reliably, please show me your wiring and settings on the roof controller.  I fear I am doing something dumb (again).


Re: ASCOM Driver "freezing"?

midmoastro
 

On Mon, Nov 29, 2021 at 03:06 PM, wbelhaven wrote:
FTDI-based
Didnt see it listed so just asking, Is the FTDI driver installed?


Re: ASCOM Driver "freezing"?

wbelhaven
 

I'm seeing the AP ASCOM driver "not responding" again, multiple times a night now. Seems the cable replacement was not a permanent fix. Can someone please help? Can't really automate image capture with this continuing to freeze up.

I just upgraded to the most recent version of the driver and ran it for a few hours without freeze. Are there any bugfixes in the latest version that would address this, or is this just happenstance (again)? Any help would be appreciated.

Thanks.


Re: Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

Geof Lewis
 

John,
I've followed your thread both here and over on the OpenPHD forum. I have to agree with Joel; the below extract of the steps you took to diagnose the problem and get a successful guiding session state....
'......then took Stellarium out of the picture – restarted – recalibrated – then successfully guided for 1 hour 30 minutes...'
It seems that the only thing you need to do to fix the problem was stop using Stellarium. I don't use Stellarium as a planetarium for telescope control, as I use SGP to run my observatory and capture images, but I do use Cartes du Ceil (CdC) when I just want to quickly use a planetarium to select targets and control the mount, which works almost flawlessly. CdC is what I used to use regularly several years ago when I too had a mobile rig and need to set up afresh each session, so maybe that's an alternative solution for you.
Regards,

Geof


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Joel Short <buckeyestargazer@...>
Sent: 10 January 2022 14:50
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin
 
John,
Doesn't it seem as if the issue lies with Stellarium, not PHD2?  I have no evidence for this statement but I suspect that Stellarium is the problem.  The internal telescope control is a relatively new feature (vs the old Stellarium Scope) and I've only been using it for a few months.  I haven't noticed this issue with my AP1100 at home, but I've noticed it with a CEM120EC at my remote location.  Next clear night I'm hoping to do some more testing.
joel


Re: NINA not Parking my 1100

Ray Gralak
 

Hi Alex,

For ASCOM client applications (NINA, SGPro, etc.), the ASCOM driver's Park Setting setting is used, not APCC's. So, as others have already mentioned, you should set the park position in the ASCOM driver.

-Ray


Re: NINA not Parking my 1100

ap@CaptivePhotons.com
 

There are two park positions defined when using APCC.  One is APCC and is the position it goes to when you hit Park on the same pane (brown arrow below).  But the one NINA uses is the one set on the AP Ascom V2 driver setup.   See the blue arrow below. 

I keep mine set differently, as below -- that way NINA parks to Park 2, which is safer for sitting in dew or if it rained (which is also where NINA will park on a safety initiated park since it has just the one position).  But when I'm done, I park with APCC to Park 3 which is where I load/unload. 

Be sure you check the ASCOM one with respect to NINA's parking.

Linwood


Re: NINA not Parking my 1100

Dale Ghent
 

Are you running SGPro and NINA under different permissions realms? What I mean by this is, are you perhaps running one as Administrator and the other not?

On Jan 10, 2022, at 02:48, Alex <groups@...> wrote:

On Sun, Jan 9, 2022 at 10:52 PM, Dale Ghent wrote:

Have you checked to make sure that APCC is indeed set to park at your desired park position instead of "Current Position", which is in fact a valid park location?
Yes APCC was configured to park to Park 1. When I checked the mount in the morning and saw it not in Park 1, I checked APCC, which indicated in the Telescope Postion section that it was parked. I simply hit the Unpark from Last Parked, and then hit the park button, where it slewed to Park 1. I have no idea why the mount parked at the current position as it wasn't selected in APCC.


Re: NINA not Parking my 1100

KHursh
 

When I have the V2 ASCOM driver running along with APCC, my MACH2 parks to what is specified in the ASCOM driver, so you may want to check there too.


Re: Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

Joel Short
 

John,
Doesn't it seem as if the issue lies with Stellarium, not PHD2?  I have no evidence for this statement but I suspect that Stellarium is the problem.  The internal telescope control is a relatively new feature (vs the old Stellarium Scope) and I've only been using it for a few months.  I haven't noticed this issue with my AP1100 at home, but I've noticed it with a CEM120EC at my remote location.  Next clear night I'm hoping to do some more testing.
joel


Re: Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

John Davis
 

JUST AN UPDATE for any following this thread.

 

Disappointingly – but not unsuspected… the guys over at the PHD2 group looked at my guiding and debug logs – and blamed the problem, as they almost *always* do – on some cabling problem with the mount/scope. 

 

Now – I appreciate their help – and I guess I understand their position – but that is such a cop-out.  Frustrates me greatly. 

 

The session I sent them logs for – I was *very* careful with my cabling.  I was just using a very light weight setup:  200mm Canon lens attached to an ASI1600mm camera/filterwheel and using an ASI 200mm fl guidescope with and asi120mm guide camera.  AND – I had the problem early… then took Stellarium out of the picture – restarted – recalibrated – then successfully guided for 1 hour 30 minutes – WITHOUT changing anything physically on the scope.   So to me – logically that does not hold water.

 

So – I guess I’m on my own to figure this out.

 

If I were using a cheap lower end mount, I might be more willing to accept their suggestions… but this is a Mach1 and I generally have *GREAT* performance out of it.

 

Sorry – just wanted to rant a little.  PHD2 is an AWESOME piece of software – but it is not perfect… all software has bugs.

 

I’ll post to this further if I find anything more.

 

I do see that I am behind releases on the ASCOM platform and on the AP drivers – so I guess I will do some updates and see if that fixes anything.  I have 2 laptops that I use – one as a backup, so I will apply all the changes to the backup first – to make sure it doesn’t screw up anything.

 

Thanks for your responses, I appreciate your information

JD


Re: NINA not Parking my 1100

Alex
 

On Sun, Jan 9, 2022 at 10:52 PM, Dale Ghent wrote:
 
Have you checked to make sure that APCC is indeed set to park at your desired park position instead of "Current Position", which is in fact a valid park location?

Yes APCC was configured to park to Park 1.  When I checked the mount in the morning and saw it not in Park 1, I checked APCC, which indicated in the Telescope Postion section that it was parked.  I simply hit the Unpark from Last Parked, and then hit the park button, where it slewed to Park 1.  I have no idea why the mount parked at the current position as it wasn't selected in APCC.


Re: NINA not Parking my 1100

Dale Ghent
 


Have you checked to make sure that APCC is indeed set to park at your desired park position instead of "Current Position", which is in fact a valid park location?

Yes, there are no notions of park positions when it comes to ASCOM. NINA and other apps just call the driver's Park() method, and it's up to the driver and the mount to interpret what that means and move the mount there. I do plan on adding advanced sequencer instructions to my NINA plugin that implement the A-P driver's Park 1-5 positions. For now, it's limited to parking the mount and whatever is configured in APCC/the ASCOM driver.


On Jan 10, 2022, at 01:13, Alex <groups@...> wrote:

I’ve been using SGP to automate my rig for a while now, but I thought I’d give NINA a try.  Things mostly seemed to work, but one issue is that the scope wasn’t parked in its usual position at the end of the sequence. Instead of returning the scope to park position 1, which I normally use, the scoped was parked in the position it when it was the end of the sequence.  When using SGP, it always retuned to the scope to park position 1.
 
I know NINA parked the scope from the NINA log:
 
2022-01-09T05:48:34.9198|INFO|SequenceItem.cs|Run|195|Starting Category: Telescope, Item: ParkScope
2022-01-09T05:48:34.9218|INFO|SequenceItem.cs|Run|195|Starting Category: Rotator, Item: MoveRotatorMechanical, Mechanical Position: 90
2022-01-09T05:48:34.9238|INFO|TelescopeVM.cs|ParkTelescope|130|Telescope has been commanded to park
2022-01-09T05:48:35.4005|INFO|StarDetection.cs|Detect|221|Average HFR: 3.1397415442436, HFR σ: 1.15009080928962, Detected Stars 167
2022-01-09T05:48:35.5920|INFO|BaseImageData.cs|FinalizeSave|144|Saving image at C:\Users\Alex Ranous\Documents\Imaging\Markarian's Chain\2022-01-08\LIGHT\Markarian's Chain_2022-01-09_05-45-31_Blue_LIGHT_-5.00c_gain0_180.00s_0012.xisf
2022-01-09T05:48:38.2074|INFO|SequenceItem.cs|Run|213|Finishing Category: Telescope, Item: ParkScope
And this is the bit from the APCC log mentioning parking:
 
0391883 2022-01-09 05:48:35.731:       Info, VPortCheckVPort1(COM4), (RX: :Rc#), TX: APCC,2,4070237,0#
0391884 2022-01-09 05:48:35.732:       Info,    VPort1(COM4), RX: :APCC,4070238,*PARK,0#
0391885 2022-01-09 05:48:35.736:       Info, ProcessVPortCommand, RX from VPort 1: :APCC,4070238,*PARK,0#
0391886 2022-01-09 05:48:35.736:       Info, ProcessVPortCommand, APCC Seq= 4070238, CMD=*PARK,0#
I was running with the advanced sequencer with the beta 26 version of NINA.  I’m running the 1.9.3.1 version of APCC. My understanding of ASCOM is that it doesn't have a notion of park positions, and given a command to park, the AP ASCOM driver should have parked to the last park position.  Anyone have any suggestions as to what I’m doing wrong?
 
Alex
 


NINA not Parking my 1100

Alex
 

I’ve been using SGP to automate my rig for a while now, but I thought I’d give NINA a try.  Things mostly seemed to work, but one issue is that the scope wasn’t parked in its usual position at the end of the sequence. Instead of returning the scope to park position 1, which I normally use, the scoped was parked in the position it when it was the end of the sequence.  When using SGP, it always retuned to the scope to park position 1.
 
I know NINA parked the scope from the NINA log:
 
2022-01-09T05:48:34.9198|INFO|SequenceItem.cs|Run|195|Starting Category: Telescope, Item: ParkScope
2022-01-09T05:48:34.9218|INFO|SequenceItem.cs|Run|195|Starting Category: Rotator, Item: MoveRotatorMechanical, Mechanical Position: 90
2022-01-09T05:48:34.9238|INFO|TelescopeVM.cs|ParkTelescope|130|Telescope has been commanded to park
2022-01-09T05:48:35.4005|INFO|StarDetection.cs|Detect|221|Average HFR: 3.1397415442436, HFR σ: 1.15009080928962, Detected Stars 167
2022-01-09T05:48:35.5920|INFO|BaseImageData.cs|FinalizeSave|144|Saving image at C:\Users\Alex Ranous\Documents\Imaging\Markarian's Chain\2022-01-08\LIGHT\Markarian's Chain_2022-01-09_05-45-31_Blue_LIGHT_-5.00c_gain0_180.00s_0012.xisf
2022-01-09T05:48:38.2074|INFO|SequenceItem.cs|Run|213|Finishing Category: Telescope, Item: ParkScope
And this is the bit from the APCC log mentioning parking:
 
0391883 2022-01-09 05:48:35.731:       Info, VPortCheckVPort1(COM4), (RX: :Rc#), TX: APCC,2,4070237,0#
0391884 2022-01-09 05:48:35.732:       Info,    VPort1(COM4), RX: :APCC,4070238,*PARK,0#
0391885 2022-01-09 05:48:35.736:       Info, ProcessVPortCommand, RX from VPort 1: :APCC,4070238,*PARK,0#
0391886 2022-01-09 05:48:35.736:       Info, ProcessVPortCommand, APCC Seq= 4070238, CMD=*PARK,0#
I was running with the advanced sequencer with the beta 26 version of NINA.  I’m running the 1.9.3.1 version of APCC. My understanding of ASCOM is that it doesn't have a notion of park positions, and given a command to park, the AP ASCOM driver should have parked to the last park position.  Anyone have any suggestions as to what I’m doing wrong?
 
Alex
 


Re: Piertech3 Adjustable Pier with AP1600 Experience

Worsel
 

Psparkman

I have a Piertech adjustable single column carrying an 1100 GT with a 2500mm scope in a 7x10 Piertech rolloff.  I park at P4 to clear the roof when closed.  Good images using a 320 pt APPM model, PHD2 at times.  Image scale = 0.5 to 1.5 depending upon camera. I check polar alignment every 6 months.  It changes a bit or not at all over the last 5 years

The piers are actually made by Linak.  Chris Erickson has been using them for a while and may have more to offer.

Bryan


Re: Problem with PHD2 when also connected to Mach1 mount using Stellarium's Telescope Control plugin

Steven Panish
 

I don't have this particular issue but the AP-V2/Stellarium ASCOM addition has some issues.  I'm using the first Stellarium version that included the code (and thanks to the guy who did it!).  It works fine for me - but only when I connect Stellarium AFTER I've connected to the mount with Cartes du Ciel!  If I don't do that Stellarium connects to the "scope" but won't slew.  This is with a 1200 CP3.  Since it works fine with this workaround, I haven't messed with it further.  I tried a later version of Stellarium and couldn't get it to drive the mount at all.

Steve

On Sun, Jan 9, 2022 at 12:26 PM John Davis <johncdavis200@...> wrote:
I think that possibility has been eliminated by the tests which all involve the same guide camera operating with the same settings. There are no problems in the system until Stellarium is added to the mix with its connection to the Mach1 ASCOM driver. For me the question is how to determine if it is PHD2 or Stellarium that is causing the problem. The PHD2 guys naturally assume that it’s Stellarium, but I’m not convinced you can conclude that from the symptoms 


On Jan 9, 2022, at 10:15 AM, Cheng-Yang Tan via groups.io <cytan299=yahoo.com@groups.io> wrote:

 I think the problem is that there are so many variables :( One possibility is the guide camera not downloading the image and so PHD freezes. I use SBIG St-i and SC-2 for guiding and have not seen this problem.

cytan


Sent from Yahoo Mail for iPad

On Sunday, January 9, 2022, 9:06 AM, midmoastro <teche70@...> wrote:

John, I thought I noticed similar several weeks back but wrote it off to something I was possibly doing. The difference for me is that I was not running Stellarium, that I recall. I was running NINA and PHD would launch via NINA. Guiding would start out normal, then just stop. Mine would auto pick back up and start tracking again though. It was very odd and was repeatable. I was suspecting some kind of issue between NINA and PHD as I believe I ran just PHD to test. My memories are vague but I thought PHD by itself ran fine and the issue only occurred when I launched it via NINA and had them running together. Again vague memories here but if I ever get clear skies again I will test to try and clarify or see if it happens again.
Todd


Re: Anyone using 13035FF Field Flattener with TEC140FL?

Greg Vaughn
 

Thanks, Roland, for your check of optical compatibility of the 13035FF with the TEC160FL.

 

Since it’s not a good optical fit, It appears that I will, in fact, need to remove the OAG from my imaging train to find sufficient room for a PreciseParts adapter to connect with the 160FL flattener.   As I mentioned previously, I think the extra length for the adapter is required because of the nature of the flanged connection to the TEC flattener, which is similar to the connection used to connect a camera to the 2.7in FF for the AP 105 Traveler (67PF562) - and still shown in ‘discontinued products’ on the AP website ( https://www.astro-physics.com/67pf462 ).

 

I suppose the two options with the Mach2 are to master imaging without guiding or move the guide camera to a separate guide scope mounted on the focuser/OTA.   It was a couple years before I moved to the OAG and I’ve gotten quite accustomed to, and fond of, it.   I already use APPM for mapping, however, so hopefully a further jump to imaging without guiding won’t be too difficult.

 

Happy New Year and Clear Skies!

 

Cheers,

Greg

 

Greg Vaughn

Alexandria, VA


Virus-free. www.avast.com

4241 - 4260 of 88264