Just a note that I’ve had the same issue with my QSI690. SGP is not releasing the memory and I’ve been able to fix it with the method mentioned above.
Good that there is a work around for this … I have this issue too every time… but no good for those of us who leave the rig running unsupervised, which I thought was the whole point of SGP?
I have a 16200 on order and this will hopefully be resolved soon? Since the issue can be replicated by two different cameras manufactured by two different entities, does this allow the conclusion that SGP is the issue? I think the work around is totally useless for those who intended to use SGP as it is advertised. I can’t sit around the machine to keep the memory usage down as it images all night long. At this point I usually only have a 30% success rate with captures given the issues with the focus routine and other quirks. Having to commit to this work around is a real problem.
swag72,
What camera are you using?
I’m using a QSI683
So,
The issue is with multiple cameras and multiple manufacturers, although similar models.
Well, you are right you shouldn’t have to do that… That said, this issue does not seem to be too prominent. Some users see it, others do not (same camera and all). This makes the issue very difficult to track.
Also, some of you are fairly long time SGPro users who have never said anything about this behavior in the past. When did it start happening?
Specifics like, it happens most when:
- The sequence is taking normal images
- Auto focus
- Centering
- Or whatever
Would be extremely helpful.
Also, I could be mistaken, but I think the workaround stated that if you close the main imaging window once after sequence start, memory starts behaving itself. It’s not that I think this is acceptable, just trying to provide options while we look at this.
I don’t think the workaround is well documented. At least I don’t fully understand it. But then again I am kind of dense. Maybe that is a good place to start. Maybe it is not that big of a deal. I am okay with workarounds. To those who have actually experienced this. How do they continue to image, and can they hit multiple targets unattended?
Ken,
I get this error message all the time while taking normal images, but my images always download. I’ve never lost a sub because of this error. I just ignore the error because it didn’t seem legit. I first noticed this error with the first beta that included the (!) alert next to Target List in the sequencer window.
I don’t believe I see the error on anything but normal Light images (no errors on autofocus, centering, flats, etc). I’ll try to pay more attention to when the error pops up.
EDIT: SX694 Trius CCD
Hi Ken,
I have been using SGP for years but didnt image for about 4 months due to our weather here.
I upgraded several things at once so hard to say what caused what. I guess the camera upgrade was the biggest and so it was easy to blame it’s ASCOM driver.
Camera: from QSI683 to MI G316200.
PhD: 2.5 to 2.6
SGP to the latest version
Prior to my dark site outing I shot numerous bias, dark and flat frames. No issues whatsoever.
On night 1: I lost 1 frame. I didnt think much of it.
On night 2 I lost practically everything. This prompted the post here.
On night 3: I rebooted the machine, shutdown everything else and pretty much stayed up all night watching the subs. No failures whatsoever.
I was groggy in the morning but atleast I got my data.
Autofocus, centering etc have not caused any issues for me. It has always been light frames.
This has been my experience as well. I started noticing the error when the alert box was added to the target list. Like Joel, my frames always download, so I didn’t think much of it. I’ll get a log next time it happens if that will be helpful.
Tim
Anyone willing to share an sgf file where this occurs?
I too have only had it since that alert (!) next to the target list in the sequencer window. To be fair it doesn’t appear to actually stop anything downloading.
I’m on my way out soon - I’ll upload a log when i get back.
I have a sgp log file where it happens.
Appreciated, but unfortunately log files will be of little use for this particular issue. I need to have known sgf files that produce the issue so I can effectively reproduce. Thanks!
Sorry Ken! Here you go… Hope that helps sort the issue
Alright… just a quick update here. I have been looking at the memory management code here for a few days now. Unfotunately is all looks and seems sound. Doesn’t mean that it is, this is just my observation. I have tested with a Canon T1i (more memory consumption) and a KAF-8300 chip. I should probably test with the ASCOM camera sim and use some ridiculously large image.
Anyhow… memory usage is mostly affected by these things:
- Number of targets (~30MB of memory per target)
- Sequence files (like working images from the MFW). Those images usually occupy about 6MB each (not just the image, but all of the Windows controls supporting them in the framework too).
- Image history: Keeps a history of the last 25 images for each filter / binning combo. The last 4 images (not for each combo) are actually held in memory. For a KAF-8300 chip, this will occupy ~128 MB of memory
- The temporary data display (FF, AF, Plate Solve, etc). For a KAF-8300 chip, this occupies about 32 MB of memory
- The main camera display. For a KAF-8300 chip, this will occupy about 32 MD of memory.
For a KAF-8300 with image history turned on, the temp data window open, 4 targets and at least 5 images into the sequence, SGPro should occupy 315-400 MB of memory. This is what I see when I run sequences. When we “release” image memory, Windows do not release immediately, but rather when the OS determines it is need of memory (a process called garbage collection).
Also, it is important to note that each process (SGPro is a process) can allocate about 2GB of RAM before edging toward failure. If the scenario above gets close to this for you, we will need to take more drastic steps to manage memory. I think somebody reported issues around 600MB? That level of memory consumption should not even be close to flagging a memory issue.
KAF-8300 chips produce 16MB images if you want to reverse engineer the math and apply to your camera.
TLDR: I cannot reproduce this issue, I don’t know why it happens to some people and not others. Memory management looks OK. I will keep looking, but I am just hitting one dead end after another.
Ken, If there is a build you can give us that has some verbose logging turned on, I would be happy to run it and provide you with the logs when this situation reoccurs. It might be rather tough to reproduce it since I saw it happen repeatedly one night and completely resolved itself the next night.
This issue does not arise using my Atik490EX (or at least, I cannot recall it happening very often) but it happens regularly with my G4-16000 camera. The G4 images are 4096x4096 and 32MB each as a saved FITs, but each image appears to use 4x that amount RAM when it is downloaded from the camera. I said it happens @ 600MB or over and by that I mean if the memory usage is sitting at 600MB then the chances are the NEXT image will fail to download. I’ve had a lot of practice at this. I do not have image history enabled.
This error will also occur if I set the machine to take a set of Darks or Flats (no other targets in the sequence - just with the camera set up to take 25 Darks OR Flats and not both). No mount or focuser driver is loaded. It happens with 1x1 binning every time when I reach the RAM limit noted above, it also sometimes happens with 2x2 binned images but the memory usage may also peak a little below 600MB in which case I can get all 25 frames without the issue happening at all. More often than not though I get the first failure at around 20 frames (these 2x2 files are ~8MB in size)
A few experiments (using Dark or Flat frame captures) show that, immediately after the image download has failed, I can abort the sequence and attempt to capture another frame, upon abort the memory usage will drop enough that this is sometimes successful - but not always. So a program restart is not always needed. However, when taking real images it’s not worth the risk of losing a 30min sub so I would always restart SGP which offers the lowest memory footprint to start with.
The fact that I see it rarely with the Atik490EX may suggest the Moravian ASCOM driver is perhaps at fault, but I see no such errors when collecting a set of Darks or Flats with SIPS, and the memory usage remains low and stable.
I don’t know why SGP would need to have the last 4 images retained in memory seeing as no processing is done and all SGP is doing is simply capturing raw data (often unattended), so perhaps an option would to disable all this memory-hungry stuff would be a solution?
ChrisH