Atik One filter wheel and cooler in unstable status, when Frame and Focus is aborted

I encountered an issue in running SGP on Atik One.

The filter wheel hang with cooler status lost, when stop is clicked in SGP Frame and Focus.

I reported the issue to Atik support, and would like to see if we can do something in SGP, to mitigate the issue.

Previously, I have to power off and on the camera, to reset it when this problem occurs.

Here is how the issue is reproduced:
18:16 Connect the camera and filter wheel, turn on the cooler
18:19 Reach -10C, start bin 2 frame and focus
18:22 Click stop to abort the frame and focus

           This is where and when the problem (filter wheel and cooler status) occurs:

18:22:14 ASCOM camera log, AbortExposure
18:22:16 ASCOM filter wheel log, position get became -1, filter wheel showed as moving in SGP
18:22:17 ASCOM camera log, get CoolerOn False, in SGP it shows temp = 0C/NA and power at 0%
18:28 I click Take One to download one frame, to flush the camera

            Filter wheel awake

18:28:32 ASCOM filter wheel log, position get return to 0, filter wheel showed as LUM
18:28:32 ASCOM camera log, temp get is -10, Cooler On False, in SGP it shows temp = -10C/NA and power at 0%
18:32 I click Cooler off and On

            Cooler status becomes normal after reset the cooler to On by SGP

18:32:03 ASCOM camera log, CoolerON set True
18:32:03 ASCOM camera log, CCD temp get is -10C, and CoolerOn = True. Cooler status in SGP returns to normal, i.e. -10C/10C (75% power)

            Camera back to normal, tested filter wheel and it responds to filter change, cooler status shown.

Is it possible to include a configurable flag, with a choice by the user?

  1. To complete the existing frame exposure and download, when Stop is clicked in Frame and Focus
  2. A hard stop when Stop is clicked

Option 1 may allows a chance, for not reaching a condition getting the camera’s filter wheel and cooler into an unstable status.

I attach the logs for investigation, and evaluation of options.

Thank you.

sg_logfile_20160102181412.txt (57.6 KB)
ASCOM.Atik.1816.244910.txt (341.0 KB)
ASCOM.AtikInternalFilterWheel.1816.270800.txt (18.4 KB)

I think I can narrow down the condition when this problem occurs:

  • When stop is clicked during the exposure

Clicking stop during download after the exposure, seems not trigger this issue.

Thanks for conduction that thorough research.

We can compromise here, but as a general rule we don’t write code for misbehaving drivers. Your description of the problem seems like this is the case. Otherwise, I’m not sure how aborting a camera exposure would cause the filter wheel to think its moving? Our code would turn into a huge mess if we weren’t allowed to make conformance assumptions for drivers. Also aren’t the camera and CFW two separate devices? How can aborting an exposure on the camera affect the CFW? Does the CFW connection pass through the camera?

So… what is the compromise? It’s pretty simple and fully within ASCOM standards. We are “kind of” handling this properly right now so I am not sure if this compromise will do you much good, but here it is: The ASCOM camera contains a property that lets us know if it is able to abort an exposure. The docs don’t go into much detail about this, but one must assume that this property can be dynamic (meaning there are some states that the camera allows abort… like integration and others where it does not… like maybe reading the CCD). If you attempt to abort an integration and the camera doesn’t want to allow this, SGPro will force the exposure process to finish (it will not provide you the data, but the capture process will have completed normally). This will effectively stop abort calls when they are not allowed. Since the code I wrote tonight is just a better version of this (meaning that we never allowed abort if the camera told us not to do so), I am not sure it will be of much help to you. The guarantee here is this: If the camera driver somehow affects the CFW (is that possible?) and it is because SGPro causes integration abort at a bad time, fixing this property on the camera will stop this behavior from happening.

Please don’t misunderstand this as me pretending SGPro has perfect code, we don’t and work hard to fix it when it needs fixing. If someone points out that we are misusing ASCOM, we will, of course, change it. I just don’t see that as the case in your description.

I’ve had a bit of a look. As I’ve said while I wrote the Atik camera driver I didn’t write the Atik Filterwheel driver.

The Abort command seems to be turning the cooler off. This seems to be something that’s happening in the low level driver, all that the ASCOM driver does is send a command to the Atik lower level driver. It looks as if it may also be doing things to the filter wheel.
I don’t see this with my 383L+ camera.

It looks as if the filterwheel commands are going through the camera low level driver in some way, I’m not sure how the camera and filterwheel are sharing the same connection. I don’t do anything in the camera ASCOM driver.

The ASCOM Can* properties are not intended to be dynamic. They are intended to report what is generally possible and not change. Drivers will throw an exception if some operation can’t be done while the device is in some state.

The Atik CanAbort will always return true.

It will be almost essential to contact Atik about this. i’m not sure that there is a viable solution elsewhere.

Chris

I too am experiencing some flaky Atik EFW2 filter wheel behavior, and
have contacted Atik about it. Basically what happens is the first time
I connect the filter wheel in SGP the FW connects but reports "moving"
constantly (it’s not physically moving) and I can’t begin the sequence
because the FW is basically unavailable. If I disconnect from SGP, cut
the power to the FW and power up again, when I reconnect in SGP it works
as it should. This is repeatable and points to a driver or
communication issue I would think.

IIRC the issue only showed up after I updated the Atik drivers due to
setting up a new computer. I’ve contacted Atik support.

I also note that I do not have to start and stop frame and focus for the
issue to crop up. It just happens every time upon first power up and
connect.

Subaru, our issues are a little different but I would be very curious to
hear what Atik says if you get a response from them.

Thanks for looking into this issue.

I agree with all of you, if Atik can identify the root cause and make the driver more robust, that would be the ultimate solution.

In fact, SGP is the software which got my Atik One works in the first attempt when I acquired it. SGP is really a fantastic software, especially with this all-in-one camera.

I reported the issue with the ASCOM logs to Atik support, waiting for their reply when they are back from holiday.

Atik previously suggested me to ship the camera back for their investigation, while during the New Year holiday, I took more tests and suspect this would be more a driver/firmware issue instead of a hardware failure.

I did the test with my friend’s Atik One 9 with his computer and cables, and encountered similar issue. It would be rare, I guess, if it is a particular hardware issue.

Let’s keep the fingers crossed and hear from Atik.

The reason why I raised here, is to see if some other Atik users encounter similar issue, to share, and to see what can we do with it.

At the moment, at least I know I should not click stop during the exposure during frame and focus, to reduce the chance of getting the camera into this unstable state.

I am experiencing exactly the same peculiar filter behavior as @joelshort with my SBIG 8300M connected to it’s 8 filter filter wheel: ie. when I first run SGP and connect to the SBIG camera then connect to the filter wheel, often the filter wheel is locked in a “moving” state and does not have any valid filter loaded. No notice of the problem is provided until SGP tries to take an image, at which time it fails because it cannot load the requested filter. My solution to this is when I first open the camera and filter wheel, I bring up the filter page of the control panel, select the L filter and click Set. With this it always loads the L filter and works fine thereafter.
Same problem occurring with both Atik and SBIG seems like more than just a coincidence. Perhaps there might be some other issue?

I sent a mail to my contact yesterday afternoon, they are investigating. Reporting to Atik Support will do no harm of course.

Chris

An update on this, I’ve identified a condition where SGP locks up every time. After I connect the filter wheel in SGP, it will report “moving” and never report LUM. If I then choose LUM (or any filter) in either the control panel or the module, and press “set”, SGP locks up. This is repeatable and I did it about 6 times in a row. SGP LOG

The solution for me: after I first connect the filter wheel and it reports “moving”, I then disconnect in SGP, unplug the power from the filter wheel, plug it back in and re-connect in SGP. After doing that the filter wheel works fine and reports the current filter. This is also repeatable.

What I can’t tell is if this is a Atik driver issue, communication issue, or SGP issue. But whatever the case, what causes SGP to lock up?

I honestly don’t know. In my experience though, only three things cause SGPro to lock up.

  • We try to do something stupid in the thread that controls the UI
  • We pass control of the program off to a driver and the driver never returns (ultimately a very low level malfunction will have caused the entire process to have stopped running).
  • There is a flaky error dialog that has somehow opened itself behind another Window (an unfortunate issue when you abuse .NET like we do)

Lock up, freeze and crash are all relative terms. In your case, can you describe the behavior?

Hi Ken,

I did a test on the 2.5.0.1 beta which I found in the release note about the handling of abort.

Unfortunately, the filter wheel and cooler status still went into moving and off respectively if stop is click during frame and focus. I can rewake the camera with a take one and using SGP to turn off and on the cooler.

Here is the log, and it happened starting 3:00:43pm.
sg_logfile_20160109145245.txt (41.0 KB)
ASCOM.Atik.1453.083180.txt (228.6 KB)
ASCOM.AtikInternalFilterWheel.1453.107300.txt (4.6 KB)

We may still need to wait for Atik for their finding and ultimate fix.

P.S. the forum server bounds back this message, I retry.

Edit; you are talking about the filter wheel, there’s no indication that any connection to the filter wheel is being made.

A filter wheel log may be useful.

Chris

When I push “set” to change the filter while “moving” is reported:

Probably unrelated, but I also get this pop-up error from the SX ascom driver:

I assume this is some connection problem since SGP was forced to close?

Chris, since I’m only using the EFW2 filter wheel I have only installed the EFW2 ascom driver and the Atik “pre-install” drivers from the Atik install package. I do not see any setting in the ascom dialogue to turn on logging, and there is no Atik log generated in the ASCOM log folder.

The SXCamera Driver server window is the local server window for the ASCOM driver. It’s supposed to be minimised but sometimes appears. Ignore it. Don’t close it, that will close the entire camera driver down and SGP will get RPC errors. I think it is unrelated.

The EFW2 filter driver is Atik’s and you will need to contact them for information. Most drivers are based on the ASCOM templates and these have some logging built in. It is different to the internal filter wheel that is being discussed in this thread.

Chris

Understood Chris, thanks. I didn’t know if these filter wheels used the same driver or not, which is why I mentioned it here. I’ve contact Atik and they are looking in to it.

Is there any solution found for this issue (either in SGP or for the EFW2 driver)?

I’m got an “Error setting the filter” error in the middle of shooting a particular color (between shot 9 and 10 for Red) in the middle of the night (happens multiple times) and then my sequence is frozen (I suspect without doing a recovery attempt).

Also no error reported in the Event Notification notes…

I’m using 2.5.0.23