D5100 serial cable loses connection, serial port access denied!

[BigRD]

I'm currently evaluating BYN 2.0.2 with my D5100 and have run into some odd behaviour with the serial cable. 

My serial cable is a FTDI232 FT232RL USB-Serial

The camera connects fine with USB, my serial cable is connected on Com7 to a Win 10 PC.

If I set up an imaging session I receive an error access to com 7 denied. I then go to Frame & Focus and capture a frame then return to Imaging I can then carry out the capture plan. But, sometimes only 1 image is taken sometimes 3. The log states session cancelled even though I haven't touched the PC or camera. I retry and I'm back to access to com7 denied. 

I've tried using DSLR Shutter and everything works fine there on com 7 with every frame taken successfully.

Any tips would be appreciated I've only 13 days left of the trial and I've not managed a single session on my scope due to this......and clouds!

Thanks

Roy

[admin]

I need help on this one.

Can someone please try this tester app with your serial cable.  It works with mine.

https://www.dropbox.com/s/o6ujmv3x77ic1ab/OTelescope.SerialComPortTester.exe?dl=0

 

This is all it does to actuate the shutter and it works every time with my cable.  I need to know if this simple code causes the issue with your cables.

using (var port = new SerialPort(comboBox1.Text))
{
    port.Open();
    port.RtsEnable = true;

    Thread.Sleep(1000);

    port.RtsEnable = false;
    port.Close();
}

 

[astroman133]

Guylain,

What happens if you put that code fragment in a loop, as with taking another exposure?

[admin]

15 minutes ago, astroman133 said:

Guylain,

What happens if you put that code fragment in a loop, as with taking another exposure?

Since the port object gets disposed of after each shutter actuation it is the same as clicking the button twice in the sample test app provided... and it worked with my cable.

Good question.

[astroman133]

I only asked because someone reported that the existing code worked once but failed on subsequent exposures.

[admin]

2 minutes ago, astroman133 said:

I only asked because someone reported that the existing code worked once but failed on subsequent exposures.

 

Yes, I know.  Once this is confirmed to work I'll add a loop inside and then a loop outside.  I'm approaching this incrementally.

 

[admin]

Okay, the test app has been reported to work.

Please try again, I have added 3 buttons now.

https://www.dropbox.com/s/o6ujmv3x77ic1ab/OTelescope.SerialComPortTester.exe?dl=0

 

 

Single

using (var port = new SerialPort(comboBox1.Text))
{
    port.Open();
    port.RtsEnable = true;

    Thread.Sleep(1000);

    port.RtsEnable = false;
    port.Close();
}

 

Loop 1 (Internal)

using (var port = new SerialPort(comboBox1.Text))
{
    for (var x = 1; x <= 2; x++)
    {
        port.Open();
        port.RtsEnable = true;

        Thread.Sleep(1000);

        port.RtsEnable = false;
        port.Close();

        Thread.Sleep(1000);
    }
}

 

Loop 2 (External)

for (var x = 1; x <= 2; x++)
{
    using (var port = new SerialPort(comboBox1.Text))
    {
        port.Open();
        port.RtsEnable = true;

        Thread.Sleep(1000);

        port.RtsEnable = false;
        port.Close();

        Thread.Sleep(1000);
    }
}

 

[soldy]

Hi, I have exactly the same behavior with my Nikon D5100 and my FTDI USB cable. It works fine on  BYN 1.0 and badly on 2.0.2. It also work well when I try my setup with Tera Term, shutter open when I open the good serial port and close when I switch to another one.

[admin]

Can you send me the log file fomr BYN 1.0 where it works.  I asked this of the first user that reported it but I never got it.  I think I can fix it once I get the log file.

 

Thank you

[soldy]

Sorry but where do you find the log file?

[astroman133]

Instructions are in a pinned post in the How-To's forum on this site.

[soldy]

I have attached few of them.

logfile-20170409-10h25m00s840-12524-2017-04-09.txt

logfile-20170409-10h25m06s262-backgroundworker-15500-2017-04-09.txt

logfile-20170409-10h23m27s133-backgroundworker-21376-2017-04-09.txt

logfile-20170409-10h23m21s734-3552-2017-04-09.txt

[skaven]

I didn't realize you were waiting on more logs.  Here's a log from v1.0.5 where I start it up, connect my camera (D90), do a cable test, then shoot five exposures using the serial shutter release: logfile-20170409-09h26m32s497-6608-2017-04-09.txt-2017-04-09.txt]

 

 

And here's a log from v2.0 where I try to do the same thing...the cable test doesn't work, and trying to shoot the pictures aborts immediately: logfile-20170409-09h32m10s339-7040-2017-04-09.txt-2017-04-09.txt]

[admin]

Hi,

 

Thanks for the log files.  I'm at NEAF this weekend and I'll take a look at them when I get back.  This does look a bug I have introduced trying to fix another bug back in or about September 2016.  

 

Thanks again for the log files.

[astroman133]

The D5100 requires 2 cables, in parallel, between the camera and the PC for full functionality.

One cable is the DSUSB shutter control cable. It goes from a USB port on the PC to the remote shutter jack of the camera and is used only for opening and closing the shutter for BULB exposures. A regular USB cable is used from the camera to the PC for all other functions (connecting, setting parameters, control of non-BULB exposures, display of LiveView, downloading images).

Your serial cable does not seem compatible.

You can test the regular USB cable with all BYN's functions except long exposure imaging. For BULB exposure you need to purchase a DSUSB cable from Shoestring Astronomy, as per the link at the top of the BYN Camera Support Grid page on this web site.

You can test all of this during the day. There is no need to wait for a clear night to test this basic functionality.

DSLR Shutter does not use the same software library as BYN and may work differently.

[admin]

Send me the log files and I'll take look. 

 

Regards,

[skaven]

Hope you had a good time at NEAF.  Have you had a chance since you got back to look at this?

[admin]

I had a very good time at NEAF, thank you.

I did not have a chance to look at it yet.  This is my priority for the next few days.

Regards,

[skaven]

Hi, any progress on this issue?  I did another imaging run last weekend and I'm still only able to use the 1.x version due to this bug.

[admin]

I'm locking this thread as duplicate.

Please use this thread to post in the future. 

 

[admin]

I'm trying to fix this and it is a pain.  I can not reproduce it.

I have an FTDI serial cable and it works flawlessly

 

[BigRD]

Hi Guylain, looks like I've had a cable with a faulty serial/usb chip. I now have a KMTronics serial relay which I have been testing tonight indoors. It was working fine but occasionally would cancel the session. I've been trying various USB cable until BYN crashed and now reports a License Validation Error. I can no longer run BYN and it says the key has expired, been deactivated etc. When it ran earlier there was still 6 days until expiry.

 

Can you help?

 

Thanks

[skaven]

What is the schematic of your FTDI shutter release?  Mine looks like this: 

Note that my shutter release is triggered solely on the RTS signal.  Since CTS is never asserted by the adapter, could it be that the serial driver that v2.x uses, gets into a hung state?

[admin]

On 3/22/2017 at 5:57 PM, BigRD said:

Hi Guylain, looks like I've had a cable with a faulty serial/usb chip. I now have a KMTronics serial relay which I have been testing tonight indoors. It was working fine but occasionally would cancel the session. I've been trying various USB cable until BYN crashed and now reports a License Validation Error. I can no longer run BYN and it says the key has expired, been deactivated etc. When it ran earlier there was still 6 days until expiry.

 

Can you help?

 

Thanks

 

I archived your trial key.

Please go ahead and BYN trial again in your cart for a second free 30-day trial key.

Regards,

[admin]

On 3/27/2017 at 1:21 AM, skaven said:

I am having the same problem with my D90 using a USB FTDI serial adapter to control the shutter.  In BYN 1.x it works fine, but BYN 2.x (2.0.2 in my case) I get a COM port "access denied" error in the logs:

 

2017-03-26 21:31:46,414 [CameraTakePictureOnMessageRecieved] INFO  - Imaging session cancelled

2017-03-26 21:31:46,416 [CameraTakePictureOnMessageRecieved] INFO  - Access to the port 'COM4' is denied.

2017-03-26 21:31:46,416 [CameraTakePictureOnMessageRecieved] ERROR - Access to the port 'COM4' is denied.

2017-03-26 21:31:46,416 [CameraTakePictureOnMessageRecieved] ERROR -    at System.IO.Ports.InternalResources.WinIOError(Int32 errorCode, String str)

   at System.IO.Ports.SerialStream..ctor(String portName, Int32 baudRate, Parity parity, Int32 dataBits, StopBits stopBits, Int32 readTimeout, Int32 writeTimeout, Handshake handshake, Boolean dtrEnable, Boolean rtsEnable, Boolean discardNull, Byte parityReplace)

   at System.IO.Ports.SerialPort.Open()

   at BinaryRivers.CableProviders.SerialPortTerminal.Shutter(Boolean open)

   at BinaryRivers.Common.Model.CameraModelBase.DoCableShutter(Single mirrorlockseconds)

   at BinaryRivers.Camera.Nikon.CameraModel.<>c__DisplayClass25_0.<DoTakePictureBulb>b__0()

   at BinaryRivers.Common.ProviderInterfaces.Camera.CameraControllerBase.DoWithCameraLocked(Action action)

   at BinaryRivers.Camera.Nikon.CameraModel.DoTakePictureBulb(Boolean start, Single mirrorlockseconds)

   at BinaryRivers.Common.Model.CameraModelBase.TakePictureBulb(Single durationseconds, Single mirrorlockseconds, String progresstext)

   at BinaryRivers.Common.Model.CameraModelBase.<>c__DisplayClass73_0.<CameraTakePictureOnMessageRecieved>b__0()

 

The problem seems intermittent.  For example, I can start BYN 2.0.2 and take one photo in BULB mode (using the cable) but then the second photo fails due to cable init error.  Similarly, clicking "test cable" will work once, then trying subsequent times triggers the above error in the log.

 

I've tried running BYN as Adminisrator, but this did not solve the problem.  Switching back to BYN 1.0.5 (running as a non-admin user) works just fine.

 

Can you please send me the full log file?

I need to know how the cable was closed and disposed of.

Thank you

 

[admin]

Okay, since I can not reproduce it and the changes I made back in September 2016 to resolve another issue was to implement a serial cable keep alive function I have now made this optional, default is keep alive.

Send me an email to support@otelescope.com and I'll send you a link to try.

You will need to go into advance settings and disable the serial cable keep alive option; therefore keeping the same behavior as before.

Regards,

[skaven]

2 hours ago, admin said:

 

Can you please send me the full log file?

I need to know how the cable was closed and disposed of.

Thank you

 

I provided a full log file at 

 

[skaven]

1 hour ago, admin said:

Okay, since I can not reproduce it and the changes I made back in September 2016 to resolve another issue was to implement a serial cable keep alive function I have now made this optional, default is keep alive.

Send me an email to support@otelescope.com and I'll send you a link to try.

You will need to go into advance settings and disable the serial cable keep alive option; therefore keeping the same behavior as before.

Regards,

Thanks, I'll shoot you an e-mail right now and will be happy to try it out.

[admin]

7 hours ago, skaven said:

I provided a full log file at 

 

Ah, okay... thank you.  I'll look at them.

This is the last bug fix preventing me from releasing 2.0.3 later this week.

Regards,

[skaven]

I've tested using the three-button version and it works fine with both the internal and external loop types, as well as single.  I tried running the app as both Administrator and as a regular user, with the same behavior (working) both times.  I also tried closing and re-opening the app a few times to see if that changed the behavior; it did not.

[BigRD]

Thanks for progressing with this in my absence, apologies for not getting back on with this sooner I've had IT issues of all sorts. Anyway I'm now reconnected to the internet and had a chance to test again. I'm now testing with my licensed copy.

I'm using a  FTDI KMTronics USB Relay on 'Relay Com8' Still intermittent operation but once a session starts it does complete. 

I have the full log files if required - it was too big to upload.

 

Roy

 

History log 02-05-2017.txt