COM port inactive after computer is unlocked

[LazerBoi64]

Greetings:

I am running into an issue where a COM port from a USB-to-RS232 hub stops working in LabView 2014.  There are four COM ports in this USB hub.  I am currently connected to two of them through a terminal program (Tera Term, 2 simultaneous instances) and one through LV.  The computers on our network are locked after 30 minutes of inactivity.  The VI I'm testing works fine when initially run as do the two non-LV COM instances.  If I let everything sit with no communications and allow the computer to lock, when I come back, unlock the computer and try my COM ports, I find that the two Tera Term instances work as expected, but the VI will not pull data from the COM port.  I open the port with no errors and then use the Bytes At Port property to see how much data is in the buffer.  The other end of this COM port is connected to a circuit board that spits out a "1\r" or "0\r" every 2 seconds depending on whether the photodiode connected to it sees light.  After unlocking, there are always zero bytes @ the port unless I close the VI and then close LV.  When I re-open LV and the VI things work correctly again.

I think this may be tied to port activity, because I use the fourth COM port to communicate with an environmental chamber which I query every 5 seconds.  My photodiode port is supposed to be queried every couple of hours, at specific points during the environmental chamber's temperature profile.

I've already done the usual.  I made sure the computer (Win10) does not disable any USB ports for power savings.

Does anyone have an idea what could be going on and what I can do to fix it?  I'm currently testing the port activity hypothesis and if that is the issue, I can throw a dummy port query into my main loop.  However, that feels kludgey to me.

Thanks in advance!

[RTSLVU]

A couple of things to suggest...

1. Have a long talk with you IT department about changing the policies for "test" computers. We have a seperate "class" of computers for test that do not have the corporate security policies pushed on them, all have the same user login/password, and they are unable to access any corporate network resources (sensitive data).
2. There are a bunch of power settings for USB ports, most need Administrator rights to change so you my need your IS department again
3. You did not say what OS but in Windows 7 look at these settings in the Device Manager
   1. Make sure ALL USB devices have "Allow the computer to turn off this device to save power" UNchecked

  4.  Power Options---->Advanced Settings---->USB Settings 

        1.  Make sure USB Selective Suspend is DISABLED

[LazerBoi64]

Thanks for the reply.  This computer is Win10 and I do have Admin rights, as do most users of lab computers here.  The USB power settings were the first thing I set and it didn't make a difference.  I can't get to my original post without losing this update so I'll reiterate...it appears to be a LabView issue because I had 3 different COM ports on this USB converter open at the same time.  Two were through a terminal program talking to a power supply and environmental chamber and the third through LabView.  After unlocking the computer the two COM ports talked to their respective instruments without hiccup.  The one through LabView stopped receiving. 

This device is very rudimentary and just respond to queries.  You just have to read data from the COM port.  I typically use the "Bytes at Port" property to find out if anything is there and if the comm link is broken, the property returns zero bytes which throws an error in my main routine.  I then have to get out of LabView completely and restart it to get comms working again.  I did not see anything in the terminal program regarding any "keep alive" setting, but maybe it's setting the DTR/DSR? line high and that is keeping those ports working.  I'm not using anything like that in LabView (or know if it's even possible), so???

I did run a test overnight where I kept the VI in question running and when I checked this morning it was still chugging away.  I also ran a test today where the VI was paused and allowed the computer to lock.  The COM port stayed active.  I'm re-running this test to verify.

I just might have to throw a dummy query at the port ever few seconds in my main loop to get around this issue.  It's difficult not getting distracted by other people/things when the event happens for a few seconds every couple of hours over an 8 hour span.