Can not recover from loss of serial communication

[cirrusio]

Hello all,

I currently have a very frustrating situation in an application I am developing.  Since it is in development, everything is kind of in flux, so if something crashes and LV has to rebooted, this is not a problem (just a little annoying).  However, what is happening is that when I go to perform an operation on a serial port, my system crashes mid-connection - LabVIEW and all.  When I attempt to restart LV and the application, the ports are found and valid but I get the error that VISA is not able to access them.  This is the same error that is thrown when another system (or application) has control of the port.  In this case, ALL programs have been shut down prior to restart so I am not sure what could be hanging on to the port.  Here are some more observations:

• If I close LV completely and attempt to open a connection to the port in MAX, I get the same error. 
• If I power off the device that is connect via USB232 and disconnect it from the computer and then turn it back on and reconnect the device, same result. 
• Oddly, this device is reported as still present in MAX even when the device has been disconnected or powered off and I can not unistall the resource via Windows Device manager (image attached). Ultimately, the attempt to uninstall the device hangs and the system will have to be rebooted.
• Looking in Process Explorer (not the Windows Task Manager), I can see a running process LabVIEW.exe with the child nimxsoffline.exe running (image attached) even though there is no obvious instance of LabVIEW running on the machine.  the process appears to be an unkillable zombie... the deadliest.

Currently, my only recourse is to reboot the computer.  While rebooting works, this is an incredibly frustrating way of attempting to debug a program.  I am running NI-Serial 4.1 which I uninstalled and reinstalled yesterday.  ANY ideas will be much appreciated.

Cheers, Matt

[cirrusio]

Whoops, forgot to add the images and I am not smart enough to figure out how to edit the post above in a reasonable amount of time.  Here they are:

[mikeporter]

Before getting into what to do after the crash, let's look for a moment as to why you are crashing in the first place. What is causing the crash? What version of LV? What OS? How long ago did this crash start happening? Did this ever work? Do you have any unusual hardware and/or drivers installed?

Mike...

[cirrusio]

Thanks, Mike.  What is causing the crash is a reference to a control via a property node.  The version of LV is 2013 SP1.  Windows 7.  And as I said before, the crash started happening when the reference to the control was placed.  I am currently in the process of removing the reference and using another method to access the control.  I think this may be beside the point though as the inability to recover goes beyond the crash.  Simply put, I lose the ability to connect to the port if I just remove the USB which connects the port from the computer.  I have never seen this happen before, and now I realize that I have not really described the topology of the system, which may be more relevant to the issue that I am seeing.

What I have here is a set of ports that is connected to a USB hub powered via 24 V, 1.3 A power supply.  The power supply also provides power to a high voltage power supply and to a bank of mass flow controllers. The high voltage power supply gets input and output from a USB-6211 that communicates with the Windows machine through the USB hub.  A bank of mass flow controllers communicates with the Windows machine through a NI USB232 cable via the hub also.  This is the port that I seem to be losing communication to - I still have access to the 6211 it seems.

Hopefully that answers some questions that might arise.

Cheers, Matt

[JÞB]

Somewhat off topic but thats just fun to read

Did you catch that?  

Spoiler

I would look into the supply regulation.  24 V for USB hub power does not seam right  and, sharing the 24V supply with a high voltage PS seams unwise.

Did you disable power management on the USB port connected to the external hub? What driver version of NI-Serial  are you using?

[cirrusio]

Ha!  That is awesome! 

Sharing 24 V seems unwise only if the power supply can provide the output required for all of the devices.  I am going to look into this, but I am fairly (80%) certain that we have run this system elsewhere before without this issue.  When I take a look at the specs, I will get back.  This could be creating problems.

[mikeporter]

You could also be having some sort of strange ground loop going on. I once had a computer that wouldn't turn on if one of NI's USB to GPIB interfaces was plugged in to it. It messed up the soft powerswitch somehow...

What type of control, are you accessing with the property node and what properties are you setting?

Mike...

[cirrusio]

Thanks for keeping with me Mike.  So, as Jeff said above, power is suspect.  The power supply is able to provide 1.3 A and write now we have, excluding the USB hub, devices that can pull up to 1.1 A so we are skirting the limit of what the power supply can handle.  That being said, it is not clear to me why the software is not behaving properly (i.e. why I can not close the connection regardless of the state).  If I were to guess, something is happening within the serial driver that is unexpected and is therefore not handled properly.

I am going to do a couple of tests Monday to attempt to elimnate the soruce of the problem being something outside of the hub in combonation with the USB232.  I will let you all know what happens.

Cheers, Matt

[cirrusio]

Sorry that I haven't gotten back on this but I have been sidetracked on one of many projects.  I have bypassed the hub and seemed to have the same problem.  I am currently in the process of reinstalling some of the drivers and seeing how things go.  I will let you all know what is happening with this as soon as I can get back to this.  Thanks for all of your help. m

[cirrusio]

Soooo, the reason I was getting issues with the serial communication had to do with not properly closing the reference to the serial session (as I was testing I was essentially not closing and then opening up a new session on the port over and over again until something eventually just died).  Handling shutdown properly fixed this, but what I can't figure out is why LabVIEW wouldn't let go of the port eventually.