About This File
Mark E. Smith
Sandia National Laboratories
--see readme text for contact information
LabVIEW does not support IPv6 protocol (as of version 8.6) using the TCP/IP functions and there is no promised date for inclusion of IPv6 compatibility in an upcoming version. I have a project that requires IPv6 TCP communication so I requested that NI support my efforts which they graciously agreed to do. Christian Loew of NI created a proof-of-concept project using Microsoft Visual C++ to create a DLL that provided LabVIEW access (through a Call Library node) to Winsock 2.x. I have taken that proof-of-concept project and refined it into, as much as practical, a direct drop-in replacement for the TCP/IP functions in LabVIEW.
Features:
- Drop in replacement for native LabVIEW TCP/IP functions
- Supports IPv4 and IPv6
- Compiled and tested for LV version 8.5, 8.0, and 7.1
Limitations:
- Does not support name/service lookups – the user must supply a valid network address in dot-quad (IPv4) or colon-delimited hex (IPv6) – the loop back addresses of 127.0.0.1 and ::1 are acceptable
- Only supports the Standard and Immediate modes for the TCP Read function. The Buffered and CRLF modes could be added (I just have no present need)
- Windows only – uses the Winsock 2.x DLL. However, the only Winsock-specific functions called are WSAStartup (to initialize the DLL) and WSACleanup (to release resources). Everything else should be portable to a sockets implementation on Linux or MacOS (this is speculation only!) if anyone has a need.
License
This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
This package includes:
Microsoft Visual C++ 2008 Express Edition project (lvipv6comm.sln) to create the Winsock wrapper DLL (lvipv6comm.dll)
The Winsock wrapper DLL (lvipv6comm.dll)
Example VIs – Data Client.vi and Data Server.vi are adaptations of the example VIs of the same name that ship with LabVIEW that use the IPv6 Tools instead of the native LabVIEW TCP/IP functions
For LabVIEW 8.0 and 8.5, a LabVIEW project exists (TCPIPv6.lvproj) and the TCP function VIs are in a LabVIEW library (TCPIPv6 Comm.lvlib). For LabVIEW 7.1, the TCP function VIs are in a single folder.
TCP IPv6 Tools for LabVIEW Version 1.1.3
Modified 15 Dec 2008
This version fixes a bug in the previous versions where the Close Connection function, when called on any connection created from a Wait on Listener, would close all connections created by the Wait On Listener. This happens because the Close Connection was executing a WSACleanup command on every call. If one executes a WSACleanup on a connection created from a listener, it closes all connections created in that listener thread. This fix is not an exact drop-in replacement for the LabVIEW native tools. It requires the user to set a flag on the Close Connection VI to prevent calling the cleanup if the connection was created by a listener. An example is included in the Multiple Connections Test VIs folder.
This fix is implemented in all versions (7.1 - 8.5)
************************************************
TCP IPv6 Tools for LabVIEW Version 1.1.2
Modified 10 Dec 2008
This version adds GetType, Get Address, and GetPort functions - these functions take a socket handle and return the type (IPv4 or IPv6), the connected address, and the connected port. These may be used as part of this toolkit or can be used to return the same information from the native LabVIEW TCP/IP toolkit (Windows only). One needs to get the socket handle using the "TCP Get Raw Net Object.vi" found in "vi.lib\Utility\tcp.llb". Pass the Raw Net Object (socket handle) into these VIs.
Note - these VIs are only compiled for the LV 8.5.1 version - they could be saved for previous and used in any version back to 7.0
************************************************
TCP IPv6 Tools for LabVIEW Version 1.1.1
Modified 19 Nov 2008
This version fixes read buffering
The native LabVIEW TCP/IP functions maintain a read buffer across calls for each unique connection ID. If you use a Read function mode that that can buffer data (such as the CRLF or Buffered modes) and you get an error because not enough data is available to satisfy the bytes requested, that data is still on the buffer for subsequent calls to that specific connection using any read mode. For instance, requesting 100 bytes in buffered mode when there are only 80 available at the port will cause a timeout error and no data is returned. A subsequent call to that connection (if it hasn't been closed or gone out of scope) in Immediate mode will return the 80 bytes that were read by the Buffered mode call but not returned. The original version of this toolkit (1.0.0) did not buffer any data since the Standard and Immediate modes always return any data read from the port. The version 1.1.0 did not always handle the buffering correctly.
FWIW, this description of the buffering behavior of the LabVIEW native TCP/IP functions is from observation - I could not find a complete description in any documentation.
Also, be aware that the LabVIEW help documentation for the CRLF mode is incorrect - this is from
http://zone.ni.com/devzone/cda/tut/p/id/7324
***********************************************
Discrepancy in TCP Read help
There is a problem with the documentation about operating a native LabVIEW TCP Read function in CRLF mode. The LabVIEW help says if you request n bytes and there is no CRLF in the n bytes, the function should timeout, return no bytes, and return an error. This is not what happens - if there are at least n bytes available at the port, the function returns the n bytes and no error regardless of whether there is a CRLF in the string. If there is a CRLF in the string, it just returns the string up to and including the CRLF as advertised. If there are less bytes at the port than the bytes requested, it times out and returns an error.
************************************************
I found and reported this problem as I was implementing this toolkit.
The TCPIPv6_ReadCRLFMode.vi in this toolkit includes a switch so that one can select the CRLF mode to operate as documented or as actually implemented in native LabVIEW - the default is to operate as implemented to make the read operation compatible with existing code.
____________________________________________________________________________________
TCP IPv6 Tools for LabVIEW Version 1.1.0
This version adds support for the CRLF and Buffered modes in the TCP Read function
Modified 18 Nov 2008
_____________________________________________________________________________________
TCP IPv6 Tools for LabVIEW Version 1.0.0
Mark E. Smith
Sandia National Laboratories
LabVIEW does not support IPv6 protocol (as of version 8.6) using the TCP/IP functions and there is no promised date for inclusion of IPv6 compatibility in an upcoming version. I have a project that requires IPv6 TCP communication so I requested that NI support my efforts which they graciously agreed to do. Christian Loew of NI created a proof-of-concept project using Microsoft Visual C++ to create a DLL that provided LabVIEW access (through a Call Library node) to Winsock 2.x. I have taken that proof-of-concept project and refined it into, as much as practical, a direct drop-in replacement for the TCP/IP functions in LabVIEW.
Features:
- Drop in replacement for native LabVIEW TCP/IP functions
- Supports IPv4 and IPv6
- Compiled and tested for LV version 8.5, 8.0, and 7.1
Limitations:
- Does not support name/service lookups – the user must supply a valid network address in dot-quad (IPv4) or colon-delimited hex (IPv6) – the loop back addresses of 127.0.0.1 and ::1 are acceptable
- Only supports the Standard and Immediate modes for the TCP Read function. The Buffered and CRLF modes could be added (I just have no present need)
- Windows only – uses the Winsock 2.x DLL. However, the only Winsock-specific functions called are WSAStartup (to initialize the DLL) and WSACleanup (to release resources). Everything else should be portable to a sockets implementation on Linux or MacOS (this is speculation only!) if anyone has a need.
License
This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
This package includes:
Microsoft Visual C++ 2008 Express Edition project (lvipv6comm.sln) to create the Winsock wrapper DLL (lvipv6comm.dll)
The Winsock wrapper DLL (lvipv6comm.dll)
Example VIs – Data Client.vi and Data Server.vi are adaptations of the example VIs of the same name that ship with LabVIEW that use the IPv6 Tools instead of the native LabVIEW TCP/IP functions
For LabVIEW 8.0 and 8.5, a LabVIEW project exists (TCPIPv6.lvproj) and the TCP function VIs are in a LabVIEW library (TCPIPv6 Comm.lvlib). For LabVIEW 7.1, the TCP function VIs are in a single folder.