Note that for a truly automated solution, you should first mount the share and store the credentials in Keychain. Here's how to use Automator to work around this issue. With Automator we can get around these annoyances. So we are forced to use the 'Connect to Server' window. It will not let you drag a share into the Sidebar. But what about mounted server shares? Nope. You can drag almost anything into it, and those items act like aliases. Something that frustrated me, though, is the Finder's Sidebar window. 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.Mac OS X is great in how it allows you to skin a cat in a multiple of ways. All device calls will be discrete and compartmentalized to protect other areas of the sequence. 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). These events are issued outside of the device threads and this is where we run into marshaling issues. 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 threads act in a synchronous manner and events are handled one at a time when the device is ready to support it. They all subscribe to message queues for pub/sub. This is the current architecture of SGPro… there is a camera thread, a focuser thread, etc. 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. If something modifies the expected state, it is truly from an unexpected (kind of) event. 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. There is no extra load here and abort is not called frequently… just checked to see if it needs to be called more frequently. If it’s not, we will abort the exposure before the call to start a new one (or fail if abort is not supported). If the camera is in the expected state (which it obviously is most of the time), we will not call abort. 99.9% of the time abort will be called no more than it is currently. There really is no extra load on the camera so only in very infrequent conditions would this ever happen. People don’t expect AbortExposure to be called frequently. While the camera drivers should handle this it’s putting an additional load on them, adding what could be an edge case. You will need to use the 2.5 beta to see this. Not the most elegant fix, but you probably won’t see this issue again. 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. 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. What I can’t figure out is why the camera received them that way… The SGPro logs show it in the correct order. Like pointed out, this is called in the wrong order, but the abort on top is called because of a lost star event. ASCOM Camera: Exposure aborted…Ģ1:27:49.344 CanAbortExposure always trueĢ1:27:49.394 StartExposure Duration 60, Light TrueĢ1:27:49.395 StartExposure: bin 2,2: subframe 0,0:2748,2198: high priority True, amplifier switched-True, StartExposure, started This event aborts the exposure and the sequence goes into recovery (if you have it enabled or aborts the sequence if not). 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. What happened is bad timing and a condition we did not fully consider (as is evidenced by this thread). Thanks Chris is 100% right… I just can’t figure out why.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |