I put together a SharpCap Sequencer and I have used it the past few nights. It stopped abruptly both nights with the same error. This is my first attempt at using the Sequencer, so I'm pretty sure this is "user error", but I'm unsure what I did wrong. What I want the Sequencer to do, is to first do a focus, then cycle over "x" number of hours, doing this each hour:
-Start loop
-Capture 4 300 s images
-Dither
-Capture 4 300 s images
-Dither
-Capture 4 300 s images
-Dither
-Refocus
-Repeat loop as many times as I request
Here is a screen capture of my Sequencer code for this loop:
SharpCapHourlySequence.JPG (204.21 KiB) Viewed 3744 times
The problem comes up at the end of the loop when it tries to perform a Dither and a Refocus. I get an error that PhD doesn't respond (at least I think that's what it says). This error doesn't happen every time, though. Two nights ago, this loop ran flawlessly for the first 3 hours, then it stopped with this error at the end of the fourth hour. Last night, it ran flawlessly for the first hour, but stopped with this same error at the end of the second hour. So, this is an intermittent problem, but it did happen on consecutive nights.
I've attached the log file from last night. At around 23:21 is when the Sequencer processed the Dither and Refocus successfully at the end of the first hour. An hour later, at around 00:22 (near the end of the file) is when the Sequencer reported a problem accessing PhD. I'm not sure if the way I set up the Sequencer to do the Dither and Refocus causes some problem (I am a newbie at this), or if there is something else wrong. Any help in solving this problem would be appreciated.
yes, I think your analysis is correct - PHD2 is not responding to API requests. Looking at the code, SharpCap will send the request to stop guiding 5 times and wait 5 seconds each time for some sort of response from PHD2 (basically a 'yep, I did that' response), but it isn't getting one. After 5 attempts and no response, SharpCap gives up.
It's difficult to be sure about what might be causing PHD2 to have issues, but PHD2 does create its own log file, which might be worth investigating to see if there is anything of interest in it at that point in time. Searching for 'evsrv' in the PHD2 log should find the commands that SharpCap sends to it.
I wonder if PHD2 is having trouble with its camera at that point in time and hence fails to respond?
Thanks for the response. It sounds like the way I have the sequencer constructed is correct for what I want to do, right?
PHD2 doesn’t report that anything is going “wrong” that I can see. It guided up to the point of failure, and the errors were running about 0.42”. Up until the point of failure, everything seems to be working perfectly.
I did come up with one possible reason: MS Windows (it’s easy to blame that). I checked “Device Manager – USB Serial Bus Controllers – USB Root Hub (USB 3.0) – Properties – Power Management” (there were 2 listed). For both, the box was checked to “Allow the computer to turn off this device to save power”. I have, and I know others who have also had some problems with this setting in the past. I unchecked those boxes, so I’ll be running with that from now on. Unfortunately, I’ve seen cases in which a Windows update restored settings like these back to what they were. Anyhow, I plan to run the exact same sequence tonight, so we’ll see if this change takes care of things. This is a stretch though, because like I said, everything looked great up until this point. The PHD2 log file showed that a dither had just completed, which required communication with PHD2, and PHD2 had resumed very good guiding. At that point, the sequencer crashed by not getting a message back from PHD2, so the refocus never got started.
I did get up around 2 am when the sequencer was supposed to end. I saw that the sequencer ended about 90 minutes earlier and that PHD2 was not guiding. I clicked on the “Guiding” symbol on PHD2, and the guiding started again, with very small errors, as before.
Just to be on the “safe side”, do you think it would be a good idea to put the command “Start guiding if necessary” in my loop immediately prior to “Set exposure to 2.000s”, which is the start of doing the refocus? I guess I’m grasping at straws at this point.
to be honest, it's not a failure I was expecting to see. SharpCap communicates with PHD2 over a network interface, but since it's the same machine, that should be robust. However, the fact that it's not actually an error from PHD but no response at all does make you wonder about the communication being broken rather than PHD not responding.
You could tweak your sequence to see if you can make it more reliable. For instance I'm not sure if the 'stop guiding' during the refocus is needed (unless you are using an OAG). With a separate guide camera I think that you could happily let it continue to guide during the refocus, which would let you remove the 'stop guiding' and 'start guiding if necessary' steps inside the loop. I would be tempted though to put a 'start guiding if necessary' before the 'dither every 4 frames' step to make sure that PHD2 was properly guiding when the capturing starts.
Of course, even with that setup, their could be a similar failure at the point of actually dithering if PHD2 is not responding (or the communication is blocked for some reason). It's an interesting point of discussion as to what the behaviour of the sequencer should be if a periodic dither fails - should it stop, should it warn and continue capturing anyway?
I ran my sequencer again last night for a little over 4 hours. As in the previous 2 nights, a "Dither" and a "Refocus" were scheduled at the end of each hour, and they worked all 4 times. There was no loss of connection to PHD2 as there was the past 2 nights. I don't think this proves conclusively that the Windows issue I brought up in my last post on this yesterday (above) was the reason they worked last night, but I'm hoping it is. At least that would be one less thing to worry about and it shows my sequencer does what I want it to do.
I just noticed your reply that you posted earlier today. In response to your one point, yes, I am using an OAG and that's exactly why I put the "stop guiding" line in. For these runs, I'm using an 8" SCT and I've always had terrible flexure issues when I used a separate guide telescope. I'm sold on the OAG now, but I've noticed the SCT loses its focus after 1-2 hours, making the periodic refocus necessary.
For now, I'll consider this issue "fixed" based on last night's performance. I expect to be using it several more times until the moon starts interfering with imaging again later this month. At that point, if this problem does come back on some of my upcoming imaging sessions, I'll do some testing with the sequencer to see if I can get it to run reliably.
I’ve been looking at the structure of the sequence I put together, given in the first post I made on this topic. I’m a little uneasy about the way it is constructed because it seems to be mixing concepts, like “Capture 12 frames” and “Dither every 4 frames”, with one-time requests, like the refocus commands at the end of the loop, all inside one loop. I’ve done a lot of programming, albeit in FORTRAN and UNIX (i.e., I’m old), so I like to see code spell things out exactly as they are to be. Here is my proposed new way of doing things:
ProposedNewSequence.071323.JPG (200.64 KiB) Viewed 3677 times
In this new sequence, there is an outer loop for every hour of integration. The loops starts with the focusing of the system, then there is an inner loop that repeats 3 times. Each pass through the inner loop captures 4 5-minute images followed by a “dither”. Doing this 3 times yields an hour of imaging with 3 “dithers”, one every 20 minutes. Each subsequent cycle through the outer loop would then repeat this process, starting with a refocus followed by another hour of imaging/dithering. This looks “cleaner” to me and I can more easily understand the flow of the sequence and the order in which commands are issued. Does this make sense to you? Do you know if there would be any apparent advantages/disadvantages in terms of performance of one versus the other?
personally, I think you've made it more complex, but then I may be biased since I understand how it works behind the scenes...
Certainly there is no need for the four separate 'Capture 1 Frame' steps - a single 'Capture 4 frames' step is equivalent.
The steps like 'Dither every 4 frames' set up background tasks that the sequencer checks at certain points to see if they need to be run. Those points are between blocks and also between frames in the 'capture still frames' block. You can actually define a custom block of code to be run periodically in this way, although right now that's limited to being time triggered rather than frame triggered.
Anyway, what you propose will almost certainly work fine, it's just that you are manually doing some of the things that the sequencer will take care of for you.
cheers,
Robin
PS... Yes, I spent several years programming fortran too, back in the 90s when I worked in academia... Shudder...
I put in the four separate capture steps because I’m an ultra-linear thinker to the nth degree, and because of my background in programming. Having one separate statement that sets up capturing a number of files, then another separate statement that says to dither, looks disjointed to me, when in fact, they’re not. They are tied together, as you say, “behind the scenes”. What would look “right” to me would be one statement like this one: “Capture x images while dithering every y images”, but I’m certainly not advocating for you to add such a statement. It just looks more like a FORTRAN subroutine to me like I’m used seeing (and writing) when it is expressed that way. Like I’ve said, my experience is very heavily weighted toward FORTRAN. I even did a bunch of BASIC and assembly language programming on my Commodore 64 back in the 80’s (I still have that machine in my garage, and I think it may be the greatest computer ever built, certainly the most fun one).
At any rate, I did test my way of doing things last night, first setting the exposure time from 300s to 5s, so that I could monitor how well all the steps performed without taking too much time away from real imaging later. I set it up to run through 5 cycles and it did that without a problem. Convinced it was working, I then changed the exposure time back to 300s and let it image M27 for 3 hours. That worked perfectly, too.
I’ve not had any problems with access to PHD2 in the Sequencer since modifying the Windows settings for the USB 3.0 Hubs so that they are never turned off to save power. Maybe a coincidence, but prior to doing this, I had a 4/6 success ratio when trying to do an auto-focus, and my success ratio is 12/12 since then.
Finally, after all I said defending my linear-thinking style, I will go to your method of putting in separate statements to capture a number of files, and then to dither every so often. The biggest reason is that I create filenames with the index number on them, and using my ultra-linear method the index number is “001” for every file, whereas in your method, the index number will increase from “001” to “012” over the course of an hour, or at least it will as long as I use an exposure time of 300s. I prefer seeing the increasing index numbers, otherwise it’s not worth having them on the filename if it’s always the same number.
Long live SharpCap! I think I now have it set up for all my imaging needs.
