06-20-2016 10:36 AM
I have a virtual com port that hangs. Occasionally the communication stops. In this state, the virtual com port shows up in device manager as a working device, but I cannot communicate with it with my LV or a terminal program, e.g. TeraTerm. If I go to device manager, I can disable the device, answer the "are you sure you want to do this" dialog, then wait for a few moments and re-enable the device. After this procedure, the communication is re-established.
I would like to write a program to detect the suspension of communications and then programmatically re-establish the commuinication. I found the devcon.exe tool in the Windows Kits available from MS, which I call using the system executable wrapper vi, but the enable, disable, and restart functions, which might be used to achieve the resetting of the communication, fail when my communication is in the hung state.
Any other ideas?
06-20-2016 11:32 AM
You could try using the HardwareHelper library: https://stackoverflow.com/questions/252185/how-do-i-disable-a-system-device
06-20-2016 01:50 PM
I am not sure how to implement it in LV.
06-20-2016 01:51 PM
06-21-2016 04:35 AM
Does it work to use the devcon tool manually from the command line to disable and enable the device when your virtual port hangs?
Is the enable, disable, and restart function written so that it is not blocked by the hung function?
06-21-2016 07:58 AM
It seems to be blocked by the hung function.
If I restart a non-hung port, it works fine.
I can use the Device Manager to disable and then enable the hung port, but the devcon fails.
06-21-2016 09:49 AM - edited 06-21-2016 09:51 AM
It is a long time ago i had a problem like this, with a FTDI device, so i do not remember details about it.
But i found my old program and i only used the devcon "restart" command to reset the device, which worked for me.
06-22-2016 06:40 AM
The device is the "debug" port on a Microchip pic32mx450f256L-PF. It is a preconfigured peripheral on the pic32, and it uses the standard MS virtual com port driver on the PC end of things.
My experience with FTDI chips is that they are very robust. The only problem I have had with them is a dlpDesign device called the dlpTH1 USB temperature and humidity probe, which uses bit-banging, to simulate an I2C interface in order to communicate directly with the Sensiron chip that provides the sensing. Even it works pretty darn good, but it does occasionally hang.
I have had a lot of trouble dealing with the standard windows Virtual Com Port in LV apps. I wish I were working with an FTDI chip instead of the standard virtual com port.