LabVIEW Idea Exchange

TCP/IP, UDP/IP, IrDA
LabVIEW doesn’t have any VI or function to retrieve connection information/properties like IP address, local port or service name, remote port, ect.
In order to get connection information, you have to make a functional global vi to manage connection information by connection ID for later to retrieve.

Native function or VI will be great help.

Currently the synchronous and asynchronous modes of writing data have little to no effect when communication over TCP. The write will return immediately after buffering the data to be written. However, the data it self may take considerable time to actually be written to the network. Absent some type of hand shaking at the application level there is no way for an application to wait until all the data has actually been written. The native LabVIEW TCP Write behaves in the same manner as the VISA write. Given this behavior it is impossible to implement a well behaved write queue for queuing up and transmitting data to a device. For example a normal print queue will open a connection and send the data to the printer. It will not attempt to open a second connection for the next print job until the first one has consumed all of the data. If a large amount of data is being written it can take time for all of it to be transmitted. The way the VISA or TCP write VIs behave the print queue would open a connection and write the data. However the call to the write would return immediately because the lower level network stack has accepted the data and buffered it. The print queue then believes the first job is complete and begins processing the second job. This will mean that a second connection will be opened. Some devices will allow multiple connections and some do not. However without the ability to actually wait for the data to be completely written the queue would have to continually try to open connections. This would be unnecessary network traffic and and unnecessary communication with the printer.

 

I would like to see an open on the write VIs to allow for a true blocking write. The write will not return until the data has truly been transmitted. The current behavior is also valid and can be retained.

 

Note: I have not tested the behavior on other types of interfaces so I am not sure if this is a TCP only issue.

The current VISA read and write primatives do not have the ability to abort early. Under many circumstances if the timeout values are short this is not an issue but it can be an issue if a long timeout is required. The current work around is to use a short timeout value and loop continually ignoring the individual timeouts until a threshold has passed and then pass the timeout error out. This apporach requires the extra code to "monitor" the process of the communication. It also requires shift registers and associated logic to maintain the data. It would be desireable to simply set the timeout for the desired value and have a separate VISA property that can be set cause the current operation to abort.