Auto Flats max exposure error

Error when using Auto Flats: something like “max exposure error” and then Auto Flats aborts.

Last week Auto Flats worked perfectly: sky flats in the evening before imaging that night. This weekend it did not work. I set up for sky flats again, in the evening. The Auto Flats routine started by taking a 2.5s exposure, the frame was fully saturated. Instead of starting again with a shorter exposure, I received a pop-up with an error message (stating something like max exposure error) and Auto Flats quit. I tried a few times and then gave up myself.

I don’t think I set anything differently and don’t understand what went wrong to keep Auto Flats from working. I really like the feature when it works, not so much when it doesn’t. :slight_smile:

AutoFlats is a complex tool and very difficult to troubleshoot without logs. SGPro keeps them for 30 days and if you were able to share them, they’d likely provide the insight to show what is happening. It’s possible that there is a bug, but it’s also possible that one of the exposure limits was set and AutoFlats could not constrain the exposure length.

Additional guidance here: SGPro - Help

I am still unsure about a max exposure violation, but I did run a scenario where it was impossible to bring ADU within tolerance for sky flats when too much sun exists (this produces min exposure violations). I found a bug here in that it would simply fail (similar to what you note). The expected behavior is to wait and try again, but ONLY if the start time is configured to use dusk otherwise failure is expected.

I was setting up Auto Flats to take flats before dark prior to imaging.

I set it to start at a certain time (18:55) rather than “at dusk”. I set min exposure = 0.01s. I set max exposure = 1.0s. Those settings worked well the previous week at approximately the same time of day.

I set up for sky flats, manual positioning of my scope (close to zenith, but “eye balled”). If I remember correctly, I left the number of flats at the default twenty-five. I planned to click the Capture button manually rather than add them to my sequence (I haven’t figured out how to do that yet, but I’m not automated at all so there’s no trouble there).

When I clicked Capture, Auto Flats took a 2.5s exposure, which is puzzling, but I think it did the same thing last week. Then it reported something like " max exposure error" and shut Auto Flats exited. I didn’t expect an exposure longer than my defined maximum, last week Auto Flats took several other test flats until the exposure length which resulted in the “well depth” I defined was reached and then proceeded. This week it exited instead.

Link to Logs

https://www.dropbox.com/scl/fi/srcctr84wmf6amv466fhb/sgpro_log_archive_d81198c8-43a8-4fbd-8559-fa0f1141b296-241003?rlkey=wm47y2qe8t5abwqsjwmozuxn9&dl=0

Approx time of issue: 7:00 PM

Useful Info

OS: Microsoft Windows 11 Home
Ver: 4.4.0.1339 (32-bit)
.NET: 4.8
ASCOM: 6.6.2.4195

Those logs don’t contain an AutoFlats run (they start at 19:46… I think maybe you want the previous logs). Logs that contain an AutoFlats run will always contain the following text

AutoFlatsRun=>start

That said, I did use your textual description of the run and recreated it here and when I force the first few exposures to be blown out, it still fails with a minimum exposure violation (and now it properly retries in a bit… though it won’t on the version you are using).

Not really related, but just curious why you are doing this manually. Is the automatic positioning not working for you? Does it need to do something different? Or had you just set up and the mount has no alignment yet maybe?

This is normal behavior for Sky Flats we need to start somewhere and starting on the high end yields faster results.

This is the part where logs would be very useful. All I can produce (and even fathom) is a minimum-exposure error and I’m unsure how high ADU exposures could produce a maximum exposure error. Not that I’m doubting you, just that I am baffled by it at the moment.

I’ll try to find the log which has the information you requested. I picked it based on time, when I tried to open a log in Notepad the display was gibberish.

No real reason for positioning my scope manually. I just did it that way.

I figured a 2.5s initial exposure was standard, but I was surprised the initial exposure isn’t either the maximum or minimum length defined for the Sequence. I was also surprised Auto Flats didn’t try again on the day I was having trouble.

When I read “max exposure error” I thought Auto Flats was telling me the entire field was saturated. When I checked the ADU values by moving my cursor over the preview, the whole frame appeared to be fully saturated, or nearly so. That made sense to me since the sky was so bright and the initial exposure so long.

I haven’t been able to try Auto Flats again, but will report back when I do try again.

I tried Auto Flats again last night, approximately 1800 Oct. 12 (I hope the log didn’t record me making a sequence for last night, that would be boring reading). The routine behaved the way I remember it performing during my last outing. I hope the logs I attached have the information needed to decipher what happened.

I was able to get sky flats the old fashioned way.

Link to Logs

https://www.dropbox.com/scl/fi/z40xb173zi7tam5fvxwzi/sgpro_log_archive_a288220a-68bf-41a8-9a91-267631d953d3.zip?rlkey=ljloow8rj21q5155mw8j9hza4&dl=0

Approx time of issue: 6:00 PM

Useful Info

OS: Microsoft Windows 11 Home
Ver: 4.4.1.1441 (32-bit)
.NET: 4.8
ASCOM: 6.6.2.4195

1 Like

The attacked logs run from 20:49 to 20:57, but do include an AutoFlats run. Is that the run to look at or did you want to include the previous logs?