Camera Error after 5 Hours

[bcall]

I've got a recurring problem where my capture plan works perfectly every night for 5-6 hours, then I get a camera error and no more subs are taken. I've attached last night's log, which is typical of what happens each session.

Details: BYE 3.1.16; Canon T6i. I capture raws + jpegs (because my CS5 Adobe Bridge can't read the T6i's raw files) and I capture straight to an external hard drive on my laptop, not the camera's card.

On the log, the last successful sub recorded is at 04:09:08,029. That's when the fun begins. At 04:09:43,799 I get a General Camera Error, followed quickly by an error telling me there's a problem with the camera's card.

Again, I do not record to the camera's card (even though I have a card inserted). And I've checked, and nothing ever gets recorded to the card. But this error apparently stops my capture plan, night after night.

I would love to know what is really happening and how to fix it. Any help at all would be appreciated!

logfile-[20180602-22h02m34s568]-[1504]-2018-06-03.txt

[astroman133]

I don't think that I can help with the General Camera error, but it seems like BYE is starting an exposure but the camera is reporting back that it is busy.

However, I would expect that there is an update (from Adobe) to Adobe Camera Raw that allows it to handle .CR2 files from your T6i. This should eliminate the need for the JPG images.

[admin]

Well, the actual error reported by the camera relates to the SD card.

EDS_ERR_TAKE_PICTURE_CARD_NG.

Each time the camera takes a picture it goes into a system check cycle and all checks must pass for the image to be taken.  This is a camera firmware check, I don't have access to it, it just runs.

Try removing the card completely and set to camera to allow taking images without card.

Keep us posted.

[s3igell]

Check through your PC Power and Device Settings to ensure that your USB doesn't Power-Down after some period of time...

[bcall]

Thanks for the feedback, everyone. I will test things tonight and report tomorrow.

[bcall]

Okay, here's the latest from another run last night. Everything went perfectly for 4 hours and 40 minutes, then the camera stopped taking pictures.

Admin, removing the card had no effect. Obviously, the card error is what's ultimately stopping the process, but it's something else that's generating the error.

s3igell, I didn't try your suggestion last night, but I'm hoping you're right. This morning I looked at the advanced power settings and disabled the USB Selective Suspend setting. I should have clear skies tonight to test this. Regarding general power-down issues, I use Caffe1ne to fool the computer into staying awake all night.

Astroman133, Adobe support for CS5 in this case amounts to letting me use the DNG converter on my CR2 files so Bridge can read them. Way more work than just generating JPGs. But I think I'll also try shooting RAWs only on my next go around, just to see if it lets me squeeze more clicks out of a session.

Thanks, everyone. I'll let you know.

[admin]

You're maybe right in that it is something else generating the error.  But what I'm sure of is that it is the camera itself throwing the error and stopping the exposure form taking place.  There is something in the camera firmware that it doesn't like.

What about the battery level?  It is odd that it happens about 4-5 hours into it.  This seems to be the only common denominator so it must mean something, but what... I'm not sure?

[astroman133]

First, you do not need to wait until you have a dark sky to test this. You can test it anytime, at the kitchen table.

Next, you should be able to set the PC's power management options to not suspend anything when connect to A/C power.

As you figured out, Adobe Camera Raw 9 is needed to convert the T6i raw files, but it is not compatible with CS5. DNG converter is the way to go. I would still do that rather than try to use the JPG images for anything.

[admin]

ummm, take a look at this post.  Were is your BackyardTEMP folder located?  It is a local drive?  If not could it be that the drive suddenly become unavailable?

 

[bcall]

Admin, I agree it's something in the camera firmware, probably. I don't use battery; I have an AC power supply, which is still functioning in the morning. So that's not it.

My Backyard Temp folder is on my laptop's hard drive (not the external drive I send RAW & JPG files to). So I don't think that's it, either.

Astroman: Yep, I could test it anywhere during the day, if I didn't have to work. Might as well test it at night and get 4-5 hours of subs, at least.

Good call on turning off ALL the Suspend options.

I don't process JPGs at all. I just use them in Bridge to quickly decide which files to discard before processing.

Thanks!

[admin]

Ummm... I didn;t catch this earlier.  You use both cr2 and jpg?  What if you only try one as a test and see what happens.

[bcall]

Will do, Admin. Next test will shoot only RAWs, with USB Suspends disabled.

[bcall]

Okay, Admin, problem not solved but more data to consider.

As usual, I set up a capture plan for 900 light frames at 20 seconds each. BYE estimated finishing between 5 and 6 am. The differences last night were: 1) I disabled USB Suspends in my laptop's power management settings, and 2) I set up BYE to shoot only CR2 RAW files (not RAW + JPG). Unfortunately these changes didn't alter the outcome. First shot was taken at 10:16 pm, then the last successful shot was taken at 4:17 am. About 6 hours before the capture plan stopped. Again, the log file shows a card error: ERROR EDS_ERR_TAKE_PICTURE_CARD_NG.

Here are two things to consider, though:

First, with BYE set for RAW only, I got more clicks in before the error. When shooting RAW + JPG previously, I would get 570-600 clicks. When shooting RAW only last night, I got 732. This is to be expected, since there was less write time per click. But what this tells me is: the error is a function of TIME, not of CLICKS. (Although it's possible that the error is not simply a function of X amount of time passing, but something else that happens over time, like heat build-up).

Second, I originally agreed that this seems to be a problem with the camera and its firmware, but something else happened that makes me wonder if there's not a BYE component. After checking this morning and finding the same problem as every morning, I decided to take some dark, bias, and flat frames. With BYE and the camera still running, never powered down, I entered a capture plan for 30 flat frames. When I clicked Start Capture, nothing happened. BYE recognized the mouse click and it looked like it was going to start, but then returned to a ready state with the Start Capture button lit up again. I tried clicking Preview instead, and it took the picture. But it would not start the capture plan when clicking Start Capture.

So I exited BYE and started it up again. At no time did I power down the camera. With BYE newly started, I entered the same capture plan for flats and it performed perfectly.

I looked at the log file later and found that the capture plan failed because of the exact same card error. Restarting BYE solved the issue. Restarting BYE, not the camera.

Tell me if I'm wrong, but here's my conclusion: This may be a BYE issue. Here's my thinking: after 5-6 hours, BYE logs a card error and can't continue a capture plan. Can't perform any capture plan after the error. But stopping and restarting BYE fixes the problem. I leave the camera powered on, so nothing changes on the camera. But after restarting BYE, there is no card error. I'm no expert, but that tells me there's a problem in BYE.

To be fair, my next test will be to leave BYE running and restart the camera. But won't that cause some sort of reset in BYE? I'll have to reconnect the camera. I could also leave the camera running and do a Disconnect, Connect maneuver. But again, won't that alter the state of BYE, too? I'm not sure what I could learn from that.

I'm attaching the portion of the log file that shows the capture-stopping camera error at 04:17:25,132 as well as the effort to capture flat frames at 05:27:38,137.

logfile-[20180604-22h02m12s704]-[6384]-2018-06-05 (portion).txt

[admin]

Your second test is irrelevant and actually expected.  It did not work because BYE and the camera entered an unknown state when the first error occurred.  When you closed BYE and started it again it worked because a new connection was established and everything was reset from the get go.

Now, going to the timing issue.  This kinda proves that something is going to sleep (or something) after about 5 to 6 hours of inactivity.  Taking 1000 images in BYE versus taking 10 is all the same... it runs in a round robin loop repeating the same action... each cycle following the same execution path.  So the fact that if bombs 5 to 6 hours into it is caused by an external force.

Try this, run another test.  This time use your computer about 4 hours into the cycle.  Don't stop BYE, let it rip... but use your computer for a minute or 2, then let rip again for at least 6+ hours. 

Regards,

[bcall]

Good plan. I use a little program called Caffe1ne that simulates pushing the Shift key every 59 seconds. But it could be that that's not enough to keep the computer from some sort of sleep mode.

I'll carry out this next test and report what happens. Thanks for your patience in helping me figure this out.

[s3igell]

BCALL, obviously the first order of business is to get the issue with Camera Disconnect / USB Timeout / whatever resolved.

But, in the long run, you will "NEED" to find a workflow that results in "RAW" Image Data - whether as CR2 or DNG or "raw" TIFF/FITS. 

As you probably already know, getting a stack of Image Files is only the very beginning of a multi-step process through which your Exposures must go in order to produce a high quality AP Image.  And that process Really needs to start with RAW data - not something Pre-Processed (Camera does Debayering, Stretching, Contrast, Saturation, Noise Reduction, and then Lossy Compression - all before storing the JPG Image to SD or USB).  So, whether you wish to Capture in "RAW" or "RAW+JPEG" (so that you can easily view the JPEG File), you really should do this for your own future interests. 

It may be that you currently only use CS5 for your post-processing, but once you wish to "Go Advanced" and Stack your Exposures with Flats / Darks or to apply other AP-specific routines from tools such as StarTools or Nebulosity or PixInsight then you will really Need those RAW files.  And, even if you use CS5, the DNG-Converter output is still a better starting point than the Camera JPEG data (even if a few more steps).  After all, as we invest 10's of hours into each AP Image and $1000's into the equipment, it seems wasteful to shortcut the Image Processing...

[bcall]

s3igell, I agree with everything you've said about working only with RAW image data in the processing phase. The truth is I only work with RAW images in processing. I think I haven't explained myself very well. I do not use JPGs for processing in any way. I use Adobe Bridge NOT for processing, but for quickly screening my subs to visually select which ones to discard and delete.

When I upgraded from my T3i to my T6i, I discovered that my CS5 Adobe Bridge doesn't support reading and visually showing my new T6i CR2 files. I wanted to continue using Bridge for screening out obvious bad subs, so I chose to shoot RAW + JPG. This allows me to use Bridge to see the JPGs and quickly select individual bad subs (clicking on both the JPG and the CR2) and delete them cleanly from my hard drive.

I then use DSS to select the remaining CR2 files (not the JPGs) and begin the stacking process, complete with darks, flats, and bias frames. DSS outputs a high-quality, no-compression TIFF that my CS5 Photoshop can read and process. Someday I may spring for PI, but for now Photoshop will do.

I hope this explanation is clear and bolsters your confidence in my understanding of the importance of using RAW data. And I do applaud your enthusiasm for helping people do things the right way. I do not use, and never have used, JPGs for stacking and processing.

[s3igell]

BCALL - OK, I see that we are actually on the same page.  If CS5 Bridge won't give you quick views of the CR2 files, perhaps you should consider one of the Image Viewer programs.  I'll recommend IrfanView (currently v4.5.1) - one of the most capable Freeware Image Viewers.

[bcall]

Thanks, s3igell. I'll check out IfranView.

[bcall]

Admin, here's the latest after my test yesterday. I set up the camera & laptop just as they are when doing AP. This includes not running anything else on my computer and activating Caffe1ne to keep the computer awake. i started a capture plan and walked away for four hours. When I returned I had an error dialog box open: (BYE 750D-T6i) Unhandled exception has occurred in your application. 

I've attached a screen snip. I opened the Details drop-down and copied & pasted the contents in a Word doc (also attached). I don't know when during those first four hours the error dialog box appeared, but I'm sure it's got something to do with my problem. In this case, after 4 hours I saw it, snipped it, and then clicked Continue. But when it happens in the middle of the night and I'm not around, what will it default to?

Regardless of what it defaults to (or doesn't default to), I clicked Continue, did another few things on my laptop (to make sure everything was awake), and walked away for another 2+ hours. When I returned, BYE had discontinued the capture process, just like I've been experiencing. A look at the log tells me it shut down at 20:26:45,119. I started at just before 4 pm and made my first check at 8 pm, so the fatal error happened just after that.

I'll have to break up the log file because of file size restrictions, so the second part will come in my next post. But I do see an error happening at 17:10:59,968, which would be about an hour before I made my first check. Could this be the cause of the error dialog? I don't know enough about programming to know what the error means or how to fix it.

If the problem is still something on the computer going to sleep, I could try the same experiment, but manually wake the computer every hour. If the error dialog doesn't occur, that would narrow it down to a wake-state thing. Thoughts?

BYE Error Details.docx

logfile-[20180605-15h52m08s463]-[7420]-2018-06-05 (part 1).txt

[bcall]

Apparently I can't send the second part of the log file because of size limitations. Let me know if you want to see it.

[admin]

Send the full log file to support@otelescope.com and I'll take a look.

I don't think this recent error is related but we never know.

[astroman133]

You could zip the log file and upload it to Dropbox...It should compress down pretty well.

[bcall]

Sent it, Admin. Thank you.

[admin]

17 hours ago, bcall said:

Sent it, Admin. Thank you.

I never got it

[bcall]

6 hours ago, admin said:

I never got it

Sent it again. Let me know if you don't get it. Looking forward to your thoughts.

[admin]

Did not get anything still.  Put it on dropbox or the likes and send me the link, maybe this will work.

[bcall]

On 6/7/2018 at 4:58 PM, admin said:

Did not get anything still.  Put it on dropbox or the likes and send me the link, maybe this will work.

Here it is, zipped.

logfile-[20180605-15h52m08s463]-[7420]-2018-06-05.zip

[bcall]

On 6/7/2018 at 4:58 PM, admin said:

Did not get anything still.  Put it on dropbox or the likes and send me the link, maybe this will work.

Update: Same problem last night, and the log file shows the same error that (I think) triggered the Unhandled Exception Error dialog box during my test. This time it happened about 2.5 hours into the capture plan.

2018-06-09 00:24:06,926 [TakePictureBulbFramework] ERROR - InvokeRequired (SynchronizationContext) FAILED!
2018-06-09 00:24:06,926 [TakePictureBulbFramework] ERROR - System.Action
2018-06-09 00:24:06,942 [TakePictureBulbFramework] ERROR - Thread was being aborted.
2018-06-09 00:24:06,942 [TakePictureBulbFramework] ERROR -    at System.Threading.WaitHandle.WaitOneNative(SafeHandle waitableSafeHandle, UInt32 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
   at System.Threading.WaitHandle.InternalWaitOne(SafeHandle waitableSafeHandle, Int64 millisecondsTimeout, Boolean hasThreadAffinity, Boolean exitContext)
   at System.Threading.WaitHandle.WaitOne(Int32 millisecondsTimeout, Boolean exitContext)
   at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
   at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
   at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
   at System.Windows.Forms.WindowsFormsSynchronizationContext.Send(SendOrPostCallback d, Object state)
   at BinaryRivers.Controls.ControlHelper.DoInUiThread(Control sender, Action action)

[admin]

Okay, this error is a cross thread error/bug... I would need to know what happens before the InvokeRequired (SynchronizationContext) FAILED! but in all honesty the app is invoking all the right .net commands to update the UI in the UI thread from a background thread.

This is a non-fatal error and non-related error IMO... it just means that some control in the UI could not get updated... most likely the progress wheel in the upper right corner.

At this point I would recommend that you re-install BYE in a separate folder and see if this makes a difference.  I don't think it will but I'm running out of ideas

[bcall]

11 hours ago, admin said:

Okay, this error is a cross thread error/bug... I would need to know what happens before the InvokeRequired (SynchronizationContext) FAILED! but in all honesty the app is invoking all the right .net commands to update the UI in the UI thread from a background thread.

This is a non-fatal error and non-related error IMO... it just means that some control in the UI could not get updated... most likely the progress wheel in the upper right corner.

At this point I would recommend that you re-install BYE in a separate folder and see if this makes a difference.  I don't think it will but I'm running out of ideas

Thanks. I'll try running it in a separate folder.