Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

BYE and Canon 6D Stability Problems


JTWaters

Question

Backyard EOS Premium 3.1.8 has a tendency to lockup that requires me to go into Win 7 Task-Manager and kill the app.  Sometimes I also need to cycle power on my 6D to resolve the problem.  BYE Processor Affinity and Virtual Mirror Lock are enabled.  This lockup occurred 3 times Saturday and twice the weekend before.  These problems have never occurred using Canon’s EOS Utility or Lightroom. 

 

My setup is as follows: 

 

I have my 6D connected to a 4 Port USB Hub that’s powered.  This USB 2 cable is about 10" long. I connect this Hub to my Windows 7 Pro Lenovo laptop using a 3 meter USB Repeater Cable.  Windows 7 is up to date and I am running firmware 1.1.7 on the 6D.  My 6D is connected to the 4 Port Hub along with an Orion SSAG and QHY PoleMaster.  PHD Guide 2 release 2.6.2 is 'sometimes' running during image capture and BYE/PHD are dithering.  PoleMaster isn’t running. My 6D is being powered by an external 12VDC to Cannon 6D power converter from Orion Telescope.  I have tried to disconnect the power from the UBS Hub and the problems still occur.

 

Problems usually occur between taking subs.  As I mentioned above, I have never had problems with Canon’s EOS Utility or Lightroom.  I bench-tested both of these during the day and no problems occurred.  I took 50ea 5 minute subs without problems.  Similar problems occur with my T3i.  I know there's a .NET issue with memory allocation problem but these problems are something different. 

 

What are causing these problems?  The log file is too large to attach.  Where can I e-mail them?

Link to comment
Share on other sites

  • Answers 8
  • Created
  • Last Reply

8 answers to this question

Recommended Posts

The Canon SDK is sensitive to communications glitches. A millisecond loss of communication between the SDK and the camera could cause your symptom.

 

I would try connecting your camera to the Lenovo with only the short cable that came with the camera and run an extended capture plan. If that works then I would add a USB extension cable into the mix. If that works then I would go through your hub and the extension cable. Finally if all is still working I would add PHD2 and SSAG to the mix.

 

Basically my suggestion to start with the simplest cabling and establish that it is working then add another piece of hardware and test again, repeating to try to determine which piece of hardware is flaky.

 

Also there is a pinned post in the How-to's Forum that describes how to send a log file to Guylain that was taken when you had a problem. Don't send all your log files, only the one that was in use when you had the problem.

Link to comment
Share on other sites

If the Canon SDK is sensitive to communications glitches why would EOS Utility and Lightroom work without issues using the same cabling setup?  I just ran another series of 45ea 150 second subs with EOS Utility 3.0 without any issues using the cabling setup.

 

Guylain asked me to enable 'Background Worker'.  I will try this Wednesday if I go out.

Link to comment
Share on other sites

Since both BYE and the EOS Utility use the SDK they should show the same behavior. There are 4 possibilities that come to mind about why BYE would have a problem but the EOS Utility would not.

 

1) Cabling was not firmly seated when BYE was used, but was when EOS Utility was used.

.

2) BYE may be using a different version of the SDK from the EOS Utility.

 

3) Perhaps PHD is overloading the USB cable when you use BYE, but was not running when you ran the EOS Utility. So, was PHD running when you ran your recent capture plan with the EOS Utility? I would think that PHD would not have to actually be guiding when you test, just looping to capture and download images.

 

4) Coincidence. It could be coincidental that no issue was detected when using the EOS Utility.

 

I am not trying to tell you what is wrong, just how to isolate and troubleshoot your setup so that you can figure out which component is causing your issue.

Link to comment
Share on other sites

Since both BYE and the EOS Utility use the SDK they should show the same behavior. There are 4 possibilities that come to mind about why BYE would have a problem but the EOS Utility would not.

 

1) Cabling was not firmly seated when BYE was used, but was when EOS Utility was used.

.

2) BYE may be using a different version of the SDK from the EOS Utility.

 

3) Perhaps PHD is overloading the USB cable when you use BYE, but was not running when you ran the EOS Utility. So, was PHD running when you ran your recent capture plan with the EOS Utility? I would think that PHD would not have to actually be guiding when you test, just looping to capture and download images.

 

4) Coincidence. It could be coincidental that no issue was detected when using the EOS Utility.

 

I am not trying to tell you what is wrong, just how to isolate and troubleshoot your setup so that you can figure out which component is causing your issue.

 

Good point.

 

#3 here has been the root cause of many issues in the past.  Your guide camera should not share the same computer usb port via a hub as your imaging camera whenever one has issues.  In fact they should not even share the USB BUS inside your computer.  The best way to ensure that is to connect your guide camera and imaging camera on USB ports from different side of you laptop.  One on the left and the other on the right.
 
Regards.
Link to comment
Share on other sites

I am considering 'shotgunning' this and replacing the Hub and USB Repeater Cable.  The Hub uses a female micro USB 2 socket for its output.  I have never felt comfortable with this connector and many Hubs now have a standard USB 2 output cable - 6 to 8" long. 

 

In relation to PHD Guide 2, I take 1 second subs to guide.  I know that's short but my CGEM mount did have worm issues which Hyper-Tuning recently corrected.   I will increase subs to 4 or 5 seconds now.  Hopefully this will reduce some of the USB traffic.  I still want to run everything through the Hub to reduce cabling issues.

 

Guylain - what did the error logs messages show?

Link to comment
Share on other sites

What are these errors?

 

2017-01-28 19:03:35,282 [TakePictureBulbFramework] ERROR - InvokeRequired (SynchronizationContext) FAILED!
2017-01-28 19:03:35,298 [TakePictureBulbFramework] ERROR - System.Action
2017-01-28 19:03:35,547 [TakePictureBulbFramework] ERROR - Thread was being aborted.
2017-01-28 19:03:35,547 [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)
 
2017-01-28 19:09:17,319 [TakePictureBulbFramework] ERROR - InvokeRequired (SynchronizationContext) FAILED!
2017-01-28 19:09:17,319 [TakePictureBulbFramework] ERROR - System.Action
2017-01-28 19:09:17,319 [TakePictureBulbFramework] ERROR - Thread was being aborted.
2017-01-28 19:09:17,319 [TakePictureBulbFramework] ERROR -    at System.WeakReference.get_IsAlive()
   at System.Windows.Forms.WindowsFormsSynchronizationContext.get_DestinationThread()
   at System.Windows.Forms.WindowsFormsSynchronizationContext.Send(SendOrPostCallback d, Object state)
   at BinaryRivers.Controls.ControlHelper.DoInUiThread(Control sender, Action action)
2017-01-28 19:09:17,319 [TakePictureBulbFramework] WARN  - TakePictureBulbFramework ::: ThreadAbortException
2017-01-28 19:09:17,319 [TakePictureBulbFramework] WARN  - Thread was being aborted.
2017-01-28 19:09:17,319 [TakePictureBulbFramework] WARN  -    at BinaryRivers.Controls.ControlHelper.DoInUiThread(Control sender, Action action)
   at BinaryRivers.Controls.ControlHelper.DoWithDrawingSuspended(Control target, Action action)
   at BinaryRivers.BackyardEOS.Modes.CaptureMode.ProgressChangedOnMessageRecieved(Object sender, MessageBusEventArgs`1 messageBusEventArgs)
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at BinaryRivers.Basics.MessageBus.MessageBus`1.SendMessage(Object sender, T message)
   at BinaryRivers.Common.Model.CameraModelBase.<>c__DisplayClass77_1.<TakePictureBulb>b__0()
 
 
2017-01-28 19:44:42,392 [TakePictureBulbFramework] ERROR - InvokeRequired (SynchronizationContext) FAILED!
2017-01-28 19:44:42,392 [TakePictureBulbFramework] ERROR - System.Action
2017-01-28 19:44:42,392 [TakePictureBulbFramework] ERROR - Thread was being aborted.
2017-01-28 19:44:42,392 [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)
 
 
...etc. I killed BYE during one of these.  There are also 'WARN' messages.  See the larger of the two files.
Link to comment
Share on other sites

I know the logfiles inside out... these are not the issue :)

 

EDIT:  The reason a thread exception is of no concern coming form the TakePictureBulbFramework thread is that there are 2 threads monitoring the bulb exposure, one from BYE and another one listening for the camera event handle indicating the bulb exposure is completed.  When the first fires the bulb exposure is ended and the second thread has no where to go but and this exception is log.

 

Regards,

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use