Using VISA and RS232 device, losing the COM port .

[RM77]

Using VISA and R232 devise communicating fine with labview and I can  Read and Write.

however, I want to turn OFF the devise, then turn it ON again (part of the test), and be able to continue .

The COM port is not communicating . unless I turn both the devise off  and Exit  LV then restart again.

How to do that without restarting LV.

thanks

[amitwadje]

hi

it seems you are closing the VISA reference when you are turning off the device.

--Amit

[RavensFan]

Losing, not "loosing"

Have you tried using VISA close on the Com port reference wire before you try to use the device again.

What kind of com port is this?  A real one in the PC?  A USB/RS-232 adapter?  Some USB cable direct to the device that then shows up as some sort of virtual com port in Windows device manager?

[RM77]

Losing, not "loosing"

I tried using VISA close on the Com port reference wire before turn the devise off.

this is a USB connection to the computer connecting the USB device. A real COM port.

Thanks

[billko]

Just a wild idea.  Maybe it takes a while for the device to spin up and the only reason exiting LabVIEW and restarting it works is because it gives the unit time to boot up?

[RavensFan]

---

@RM77 wrote:

this is a USB connection to the computer connecting the USB device. A real COM port.

Thanks

---

That is NOT a real com port.  By real com port, I mean a DB9 connector directly built into the PC.  A USB connection from PC to the device is not a real COM port.  When you plug it in, it probably needs to download drivers.  And those drivers probably install a virtual com port that makes it appear like Com1 or Com 5, or Com 10 in windows device manager.

The problem is that you don't know about the reliability of the driver.  It is the item that has a problem recovering if you turn off the device.  (By the way, it is not "devise")  It is possibly that that the driver is hanging onto the connection and the only way to fix it is when LabVIEW closes and VISA forces it out of memory.

[RM77]

I agree, its not a real port.

The device has a micro-controller " TI MSP430", that is the driver I downloaded and it works very well except this issue. But I don't know about the recovering of that driver.

Not sure if the driver is hanging onto the connection and the only way to fix it is when LabVIEW closes and VISA forces it out of memory.

If I use the VISA Close, from the VISA advanced, is that is not enough to close and release the port (e.g. COM12)?

Is there a better way to make sure its closed and driver is not hanging onto the connection?

If you have a simple Block diagram to make sure its closed that would be great.

[LV_Pro]

Take a look with device manager before and after turning on/off your device under test to see what com port is assigned and whether it changes. I had a case where I would loose connection to a device that  was talking through a USB/Serial adapter and when it came up it would have a new com port address (i.e. COM5 would become COM15)

[_Xilinx_]

" Is there a better way to make sure its closed and driver is not hanging onto the connection? "

you could try a command like " devcon disable usb\vid_0CD5*0003~" and then "devcon enable usb\vid_0CD5*0003~"

( you will need to figure out the ID of your device, my example is for a LabJack U3. )

Get the devcon.exe-utility from microsoft.

but as mentioned before, just watch what happens with device Manager (' run devmgmt.msc')...

to enable/disable a device in a VBS script you can use below example,   (As Administrator!)

Option explicit
Dim oShell
set oShell= Wscript.CreateObject("WScript.Shell")
oShell.Run "RunAs /user:Domain\USER ""cmd"
WScript.Sleep 100
oShell.Sendkeys "USERPASSW"
WScript.Sleep 500
oShell.Sendkeys "devcon disable usb\vid_0CD5*0003~"
WScript.Sleep 1000
WScript.Sleep 100
oShell.Sendkeys "devcon enable usb\vid_0CD5*0003~"
WScript.Sleep 1000
oShell.Sendkeys "exit~"
Wscript.Quit

My reason for doing it this way is that my USB device didn't respond to any of my calls from Labview. Enable/Disable solved the issue...

The thing I particularly hate about above VBS-script is that I need to send the Admin password in plain text...

[Varaprasath]

---

@RM77 wrote:

I agree, its not a real port.

The device has a micro-controller " TI MSP430", that is the driver I downloaded and it works very well except this issue. But I don't know about the recovering of that driver.

Not sure if the driver is hanging onto the connection and the only way to fix it is when LabVIEW closes and VISA forces it out of memory.

If I use the VISA Close, from the VISA advanced, is that is not enough to close and release the port (e.g. COM12)?

Is there a better way to make sure its closed and driver is not hanging onto the connection?

If you have a simple Block diagram to make sure its closed that would be great.

---

Most of the RS232 based devices works in this way.

When the MSP430 is getting power down send the information (example : "POWERDOWN") to LabVIEW, when this message is received the VISA reference should be closed.

I hope their should be some interrupt mechanism in MSP430 to detect the power down.

If VISA is closed before Power down, I think it should work fine.