Obs Dome time out during SGP Shutter.Status check


#1

A few weeks ago I had the HitecAstro ascom roof controller fitted to my ROR observatory. After a couple of failed attempts I had repeated success slaving the observatory to the scope - just manually unparking/parking, not as part of a sequence.

I have ran two short imaging sessions - 1 x 1800s Ha - and the session worked flawlessly. My workflow was:

  1. Start HitecAstro Obs software, connect to mount (this started Eqmod)
  2. Start PHD2, connect all
  3. Start SGP, select sequence, connect all, set Slave to Telescope with only close at park selected
  4. Start Observatory in HitecAstro Obs software. This unparks the mount and opens roof
  5. Start sequence.

This worked without any errors but are only of a short duration.

Last night I intended to capture 5 x 1800s of Ha. However, only 2 subs were captured and an "Unhandled Exception Error’ occured, the text of which I saved in a text file. I think Recovery Mode was activated as guide star was lost (unexpected clouds) and SGP eventually tried to park the mount, Eqmod showed ‘parking’. The mount did not infact park and Eqmod and HitecAstro Obs software were both unresponsive and frozen. The end of sequence tasks had completed, eg warmed up ccd.

My workflow was as above.

I have two D-link powered usb hubs (which may be the problem?), my laptop only has 2 USB ports.

  • Hub 1 - Eqdir, Obs and QHYLii
  • Hub 2 - ccd, filter wheel, focuser

This combination (excluding the Obs usb) has worked without a problem for many months.

I’m not sure where the problem lies, but the SGP log shows the time out with the HitecObs.Dome ShutterStatus at 00:17:36.

I am currently testing capturing darks. This time I have amended my workflow:

  1. Start PHD2, connect all
  2. Start SGP, select sequence, connect all, set slave settings, open with unpark, close with park (ie I have omitted connecting via Hitec Astro software and will unpark within SGP)

I have emailed Hitec Astro support for comment as well.

Two logs in drop box- zipped SGP log and Text from Unhandled Exception Error.

https://dl.dropboxusercontent.com/u/32050952/sg_logfile_20150708232303.txt.zip
https://dl.dropboxusercontent.com/u/32050952/Unhandled%20exception.txt

I’using a W7 laptop with 2.4.1 SGP.

Any pointers from your experience/knowledge will be helpful. Thank you in anticipation . . .

Barry


Post sequence events - calling for script
#2

Update after 2 hours of darks:

  1. Roof opened fine after unpark within SGP, mount unparked
  2. At end of sequence, Unhandled Exception Error once again flashed up onto the screen, SGP reported parking mount.
  3. Mount didn’t park, roof didn’t close (although SGP reported within Telescope dock mount was at park position).
  4. Eqmod frozen and couldn’t park.

https://dl.dropboxusercontent.com/u/32050952/sg_logfile_20150709182039.txt.zip
https://dl.dropboxusercontent.com/u/32050952/Unhandled%20exception2.txt

Thanks,

Barry


#3

I don’t know much (anything) about the Hitec Astro Obs software…but you generally don’t want 2 things slaving your dome to your scope. It sounds like you’re connecting the mount in the Hitec Astro Obs AND in SGP. You probably only want to do that in once place (likely just SGP if you want to automatically open/close the OBS when the sequence starts/ends.

Thanks,
Jared


#4

Thanks Jared.

In my second trial capturing only Darks I didn’t connect using the Hitec Astro software and only used SGP.

Hitec tell me that another customer is experiencing these Unhandled Exception Errors when their capture software calls for status.

What is confusing is everything works well when the sequence is of short duration, eg 45 minutes or less. For the two occasions I’ve imaged for 2 hours +, the communication between SGP and the dome controller has failed, it’s almost as if the dome has hibernated.

I would have thought the issue lies with Hitec and will wait to see the outcome of their investigations. I’ll report back.

As a general call for help I’ll ask the community in a separate thread if anyone can help me with a script for roof closure to execute post-sequence, it may work in the interim until I/Hitec have solved this issue.


#5

Looks like you’re correct about the exception coming from the ASCOM.HitecObs.Dome.

Also it appears that the log you provided is showing that all of the events were complete and there were no other targets. Is this correct? Just wondering as it looks we were not in recovery or anything and that the shutdown was normal. But when we asked for the status of the Dome we got the exception.

Thanks,
Jared


#6

Thanks Jared.

My first session, I only collected 2 of the 5 subs, so something happened and there were clouds when I went out to check on progress.

The second darks session I collected all of the darks and the error (and eqmod hang) only happened when the end of session events were triggered.

I have a sneaking suspicion this is a usb cable or powered hub issue, but I don’t understand why it has worked flawlessly for two sessions each only collecting 1 x 1800 Ha sub, so only lasting 45 minutes or so.

Barry


#7

My guess would be a timing issue in the driver.

For instance I see a timer in the driver that may be updating the shutter state from the hardware. If SGP asks for the shutter state at the same time this timer is writing to the variable bad things could happen. This is likely why the error seems random and it happens after running for a little bit (better odds for bad things to happen after a little bit of time).

Jared


#8

Thanks for the pointer.

I have forwarded this info to Dave Grennan at Hitec Astro, I trust you don’t mind.

Barry


#9

Well I installed an updated Hitec Astro Obs software last night and spent 3 hours capturing RGB. Unfortunately there was no succes with the auotomatic roof closue upon the park command during the end of sequence events. As before, SGP reported parking, Eqmod reported parking, but immediately froze, the mount stopped tracking, the roof did not close and the mount did not park. Interestingly, my Atik ccd did not enter the warm-up routine as normal (don’t know if it became unresponsive).

I have updated Hitec Astro of these events and sent them screen shots and logs (which I link to below).

https://dl.dropboxusercontent.com/u/32050952/ASCOM.Diagnostics.0305.594990.txt
https://dl.dropboxusercontent.com/u/32050952/Capture.PNG
https://dl.dropboxusercontent.com/u/32050952/sg_logfile_20150717230447.txt
https://dl.dropboxusercontent.com/u/32050952/log2.txt
https://dl.dropboxusercontent.com/u/32050952/Screen%20Shot%202015-07-17%20at%2023.33.36.png

Interstingly, the ‘Unhandled Exception Error’ box appeared after the first 300s sub and appeared in total 3 times. I copied the text into Log2 (on the dropbox link). Clicking ‘continue’ apparently did not halt the sequence and I gathered 3 hours of RGB :smile:

If you’re able to rule out SGP it will be helpful as I understand that Hitec Astro are not able to replicate this error (don’t know whether they have a licence for SHP though, and test with the Maxin, ACP, CCD AP etc). For clarity in my last sentence, HitecAstro are not suggesting that there is an issue with SGP. Other users of the HitecObs are also reporting this Unhandled Exception Error and loss of fucntion.

The Hitec Support engineer I am dealing with, Dave Grennan, can be contacted on david.grennan@hitecastro.co.uk. I have given him the info@mainsequencesoftware.com email incase he needs to contact yourselves.

Ken, Jared - many thanks for your help.

Regards,

Barry


#10

The error, some sort of profile persistence exception, is almost certainly nothing to do with SGP and the way it happens with the ASCOM diagnostics seems to confirm this.

My guess is that it’s something to do with writing the ASCOM profile data to the registry and that it might be something specific to your system, some sort of registry access permissions problem. This should be sorted by the ASCOM installer but maybe the security on your system is set differently.

It may be useful to run the ASCOM Conform application on the dome. This checks things and hopefully it will fail in the same way.

Otherwise it will be a matter of working with the Hitec people to find out what is happening.

Chris


#11

Thank you Chris.

Do you suggest I should uninstall and then re-install ascom? Is the ascom confform application something within my ascom software I can use (never really opened ascom)?

Barry


#12

Chris

I just fully read the instructions for installing Ascom 6.1SP1 on a W7 machine (which I have) and then checked the Microsoft .NET Framework 3.5.1 within Control Panel/Program & Features/Turn Windows Features on or off - and saw that the Microsoft .NET Framework 3.5.1 was not fully enabled, only partially. I ticked the boxes and then windows reconfigured.

I plan to reinstall ascom 6.1SP1.

Do you think this might be the issue?

Barry


#13

Reading the instructions is almost never the issue :smile:

Ensuring that .NET 3.5 is installed will do no harm. ASCOM needs .NET 3.5 and 4.0 (the minor version should not matter).

You may not need to reinstall ASCOM 6.1. I’m a little surprised that it would even install without .NET 3.5 installed.

In any case don’t bother to uninstall the ASCOM platform, just reinstall it. It will remove things it doesn’t need.

If this persists I suggest taking it to the ASCOM-Talk group. The people who know about the detail of this are more likely to be there than on an application forum.

Chris


#14

Chris

I’ve just finished reintsalling Ascom 6.1SP1 and a couple of messages popped up in the status/icon tray (? name?) in the bottom right corner of the screen referring to the ascom registry being repaired along with a sequence of zeros (3 or 4 of them). The message disappeared before I could take a screen shot.

I wonder if I’ve repaired a problem?

If I get a chance I’ll do some testing tomorrow.

I’m sharing these emails with Hitec Astro BTW and thank you for the pointer about the ASCOM-Talk group.

Barry


#15

Hitec Astro have issued an updated driver a few days ago, which gave me success without error after a 1 hr 20 mins sequence of darks, closing the roof, then carrying out the chosen end of sequence options: parking the mount and warming up the ccd. Great, progress.

Last night, I imaged for 2 hrs 25 mins. I connected to the Obs in SGP only, slaved to allow roof open on unpark, roof close on park; unparked from within SGP telescope module.

I woke up in readiness to watch the end of sequence events to check all was OK with roof closure. When I got to my Obsy in the garden, Recovery had started as clouds where coming in. I waited for a few minutes and could see that the seeing wouldn’t improve, I let the mount do its meridian flip and then aborted the sequence. I chose to abort immediately and ticked the box for end of sequence options.

Immediately the the roof ‘beeped’ and then closed. So far so good I thought. The SGP status bar in the bottom left then reported mount parking. The roof closure took about 10 seconds and I waited for the mount to park. I waited for what seemend like a long time at 1:20am . . .

  1. The mount didn’t park.
  2. My TEC switched to warming but the process then froze after a couple of minutes and the ccd didn’t warm up (though the status bar continued to show a small sliver of green).
  3. The sequence window ‘aborting’ message remained and didn’t clear.
  4. The mount kept tracking.
  5. Eqmod did not report parking (which it did with the previous Hitec Astro driver and it went unresponsive).
  6. I then clicked ‘park’ in Eqmod and this worked; the mount parked.
  7. After this I tried to disconnect from the Obs in SGP. It did not disconnect. The sequence window then greyed out and SGP reported ‘(unresponsive)’ in the top left. Shortly after the whole SGP window greyed out.
  8. I had to Ctrl-Alt-Del to exit SGP and disconnect from all equipment.

The SGP log is here, https://dl.dropboxusercontent.com/u/32050952/sg_logfile_20150818221346.txt

The end of the log at 01:21:09 shows an Ascom error with the Dome.

I was using the 2.4.2.5 beta.

I don’t know whether the error occured whilst collecting the lights (as oppose to functioning fine collecting the darks a couple of days ago) because I aborted the sequence, whether it is due to the beta, both of these, or neither because the Hitec Astro driver still has a flaw (the favourite theory).

Once again, any insight that you can give will help.

BW

Barry


#16

I’ve heard from Hitec Astro who have advised that I reset the sensors at the open/close position as my problem may have arose because the sensor in the close position didn’t detect the roof close. This then never confirmed to SGP that the roof had closed, the abort therefore never terminated and the mount didn’t park.

I’ll reset when the weather allows (lovely August rain at the moment).

Also interested to read the thread on ‘Bug Report - Dome & Scope Slaving’ and the park/unpark within SGP telescope module. This is the method I have been using to unpark and I wonder if this is also a factor with my current issues?

Barry


#17

I’m really pleased to report that imaging last night I had complete success after 2.5 hours of imaging: the roof closed and the mount parked!

I had reset the open/close limits as suggested by Hitec Astro and was also using the latest SGP beta, 2.4.2.8 (don’t know whether this latest beta incorporating 2.4.2.7’s dome slaving fix also helped) - very pleased.

Another step closer to unattended imaging . . . cloud/rain sensor next.

Barry


#18

Good to know it is working, I did look at the Hitech controller at Astrofest and wondered how well it would work. Decided to build my own hardware and software as have locks I need to release before I open the roof and not sure if the Hitech controller handles that,


#19

Barry, have you succeeded in getting the roof to open automatically when the sequence starts and the telescope unparks?
I too have a HitecAstro Roll Off Roof, and have it slaved to the telescope, but the roof stays shut when the scope unparks.
Peter


#20

Yes I have. The last revision, v162, that Dave Grennan sent works fine.

It is important that you follow the instructions on his email and clear out the files via the ascom utility and rest the limit sensors.

From your email I presume you connect to the ascom driver via SGP? It is importnat to only connect this way. You also check the options within the Slave Settings to open roof when mount unparks? You must also unpark within SGP using the telescope module, otherwise it doesn’t work.

Outside of SGP integration, I presume if you use Hitec Obs the roof opens/closes fine when you connect to the scope?

Let me know which revision of Hitec Obs you are using and I could send you a private email for the link to the driver if you are on a previous version.

I’m more than happy to help Peter, so email me if you’re stuck after confirming the above.

HTH

Barry


www.mainsequencesoftware.com