After a center object, the camera driver threw this exception:
[06/12/2015 4:19:37] [DEBUG] [Camera Thread] ASCOM Camera : CheckDotNetExceptions ASCOM.Atik.Camera StartExposure System.ApplicationException: StartExposure - Camera not idle (See Inner Exception for details) (System.ApplicationException: StartExposure - Camera not idle)
at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 630
at ASCOM.DriverAccess.MemberFactory.MethodTargetInvocationExceptionHandler(String memberName, Exception e) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 678
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 487
at ASCOM.DriverAccess.Camera.StartExposure(Double Duration, Boolean Light) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Camera.cs:line 594
at ew.ay(cu A_0, he& A_1)
The problem is that after giving the exception, the center object dialog was opened for hours and the sequence was neither retried nor aborted. So the tracking of the mount went on an on causing a dangerous situation.
Maybe if some exception like this arise, instead of waiting the camera to complete the capture (something that never happens), just propagate the Exception and make it fail, so that the recovery mode may go ahead.
It would really help if people said what equipment they have.
There’s nothing that can be done because no one ever provides any useful information. Whenever I hear about this sort of thing I ask for driver log files and I NEVER get any.
All I can see is that the camera driver reports that it can’t start because the camera is in the wrong state. It reads the state from the camera.
Driver logs would help, also what has to be done to recover so the camera works again?
[quote=“ManuelJ, post:5, topic:2678”]
Do you need something else from me?. Is there any driver log file?.
[/quote]Yes driver log files.
Check the Trace On checkbox in the Atik driver setup dialog window.
Run until you get the error.
Zip up the Atik driver log and the SGP log and post them.
The Atik log is in My Documents\ASCOM\Logs , named something like ASCOM.Atik.nnnnnn.nnnnnnn.txt
It would also help to know what you do to get things working after this problem.
All right Chris, I’ll do as you say. I’ve just updated to the last ascom and atik drivers. I’m also considering removing the usb hub. One thing at a time to see what is the source of the problem.
I’m a software engineer, and I fully understand your point!.
In case it helps I was running last night with two Atik cameras connected through a USB extension and a 13 port hub. This is actually 4 4 port hubs and at least one of the cameras is connecting through two hubs.
No drop outs of the cameras or any of the other USB stuff at all over several hours.
W10 64 bits but a fairly powerful laptop. I can surf the net and do emails at the same time as imaging and guiding.
I’m using my latest drivers of course, they may be more up to date than what is released.
@ManuelJ Chris is 100% right… I just can’t figure out why. What happened is bad timing and a condition we did not fully consider (as is evidenced by this thread). What happens is that your sequence falls apart… clouds or, in this case looks like a complete failure of the mount… this also probably caused PHD2 to freak out and stop moving the mount, which in turn led to a “star lost” event from PHD2. This event aborts the exposure and the sequence goes into recovery (if you have it enabled or aborts the sequence if not).
21:27:49.344 CanAbortExposure always true
21:27:49.348 AbortExposure
21:27:49.394 StartExposure Duration 60, Light True
21:27:49.395 StartExposure: bin 2,2: subframe 0,0:2748,2198: high priority True, amplifier switched-True, StartExposure, started
Like @Chris pointed out, this is called in the wrong order, but the abort on top is called because of a lost star event. What I can’t figure out is why the camera received them that way… The SGPro logs show it in the correct order. But… instead of pondering over this for long periods of time (regardless of this log, it can still clearly happen), I think it will be OK to place an abort event in front of any new capture start. It will not be called if the camera reports it is idle, but this will help sync camera status when it can be modified from multiple threads. Not the most elegant fix, but you probably won’t see this issue again.
You will need to use the 2.5 beta to see this. It will be in 2.5.0.2
I’m uneasy about this, it’s what I call a band aid fix, adding something to hide an underlying problem.
While the camera drivers should handle this it’s putting an additional load on them, adding what could be an edge case. People don’t expect AbortExposure to be called frequently.
These thread synchronisation issues are really difficult, In this case I guess that the various calls are marshalled onto a single thread in the driver - or the interface between SGP and the driver.
Would it help if the calls to a device were to be marshalled onto a single thread in SGP? That way you would have more control and ability to diagnose problems.
There really is no extra load on the camera so only in very infrequent conditions would this ever happen. 99.9% of the time abort will be called no more than it is currently. If the camera is in the expected state (which it obviously is most of the time), we will not call abort. If it’s not, we will abort the exposure before the call to start a new one (or fail if abort is not supported). There is no extra load here and abort is not called frequently… just checked to see if it needs to be called more frequently. There is likely a better way to architect this, but right now we are saying that a camera’s ability to start a new exposure is predicated on the fact that only one exposure can be in process at any given time. If something modifies the expected state, it is truly from an unexpected (kind of) event.
This is the current architecture of SGPro… there is a camera thread, a focuser thread, etc. They all subscribe to message queues for pub/sub. These threads act in a synchronous manner and events are handled one at a time when the device is ready to support it. That said, sometimes we are forced to circumvent the device threads because we need to execute an action immediately (like abort or stop or whatever). These events are issued outside of the device threads and this is where we run into marshaling issues.
One other point is that we are looking at the possibility of actively moving any device activity out of persistent threads (entirely… meaning no direct calls to devices from the sequence thread, no direct calls from the device threads). All device calls will be discrete and compartmentalized to protect other areas of the sequence. I’m not exactly sure how it will work yet, but we’re looking at methods that would allow devices to behave as badly as they want… enter infinite loops, never return control, etc and still maintain control of the overall sequence.
Anyhow, with respect to this particular change, it’s not really much change at all…
You should never depend on only one application to protect your gear… often the ASCOM driver will have it’s own protection built in.
Again, I am not sure if we can do much to fix the root cause of the issue (camera timeout), but my hope is that we can find the hang and, at least force a graceful sequence failure.
Many thanks Ken. I’m developing my own piece of software to avoid the mount to track past meridian. But this bug was occurring more than I wish, and was ruining my imaging sessions.