LabVIEW
VISA (COM) STATUS
Solved!
Your mixing up some things. First, when you disconnect the cable, the COM port is still present in your system. So VISA will still see it and display it.
Second, the icon indicating that the port is open is not always correct. Updating that status is a lot of effort as VISA has to query various things for that, so LabVIEW is not continuously doing that in the background.
Do you encounter any specific problems? Like not being able to open the port in a different application after you explicitly closed it with VISA Close? Or is this more an aesthetic issue you have?
Hi Faizan,
@Faizan_habib wrote:
I am not using USB-RS232 Converter. I disconnect the serial cable not adapter.
When you use an onboard COM port (and only disconnect the serial cable) then this port is ALWAYS available...
Why do you start a new thread for the very same topic? I will merge them...
Hi Faizan,
@Faizan_habib wrote:
Yes , the port is available always but in the screen-shot you can see it also shows in-use sign as well. How we can disconnect it completely? So that my user interface knows its disconnected.
Don't use the VISA control in the GUI, so the user doesn't see the status shown in this control.
Apply the suggestions given in this thread to check the connection status on your own!
@Faizan_habib wrote:
The goal I want to achieve here is that whenever I connect my cable to the port my User interface should know that there is a connection and when the cable is not connected the User interface knows that there isn't any connection available.
That is impossible with an RS-232 port without your own programming. LabVIEW and VISA can NOT detect if you have a device connected to the port. To do that it would need to know how to query the device to get an intelligent response. This is already time consuming enough for one type of device, but doable, but with zillion different devices that all require a zillion different commands to get any intelligent response from, trying to implement that would cause VISA to take a few million years to go through all, and then comes manufacturer XYZ and invents protocol variant zillion-and-one and the whole scheme breaks into parts nevertheless.
Even if you know exactly what device you want to connect with and therefore can do:
- open port
- send query command
- wait for response
- analyze response to see if it is the device you expect
- close port
you do not want to do that continuously in your application on all available ports for some "nice to have" indicator in your GUI that there is indeed a device connected, and then "ohh no it is not connected anymore" but hey wait "it is connected again". This results in an extremely sluggish application as it is all the time busy trying to detect if there is a device connected and doesn't let your program do the actual work very well.
Instead you may want to do a scan for devices at startup (yes you have to program that yourself) and then trust your users to be somewhat intelligent to know themselves that disconnecting the cable is maybe causing a disruption of the current application flow. You can also add a menu point or button to let the user do a scan again.
The scan for resources takes a significant time and can only be done by you, by programming it yourself since only you know what device you expect at that port. Because it is a lengthy process, you do only want to do it at moments where a normal user expects your program to be non-responsive. That is during startup until the GUI is fully displayed and all is well or when he explicitly pushed a button or selected a menu to initiate this procedure.
