Remote Control, Monitoring and the Internet

6 files

XML-RPC Server for LabVIEW Version 1.2.0
Mark E. Smith
Sandia National Laboratories
mesmith@sandia.gov
This release fixes error handling when the server does not start and port selection fron the Set Server State.vi.
This release is for the LabVIEW 2009 and LabVIEW 8.5 versions. LabVIEW 8.0 and 7.1 versions remain at release 1.1.0
*************************************************************************
Mark E. Smith
Sandia National Laboratories
--see user file for contact information
This release fixes two primary bugs
1) Single quotes, which are allowable on attribute values according to the XML 1.0 Spec, were not correctly handled. Thanks to Richard Graham for identifying this bug and providing a fix (now incorporated into the project).
2) The server unintentionally blocked on some method calls and became unresponsive while the method call executed. This has been corrected and new methods will be launched asynchronously as fast as the server can process them. If one tries to call a method that is busy, an XML-RPC fault will be returned immediately since this server does not support reentrant method calls. If one needs re-entrancy, build a wrapper method that launches the reentrant instances. Or just catch the fault and try again until the method becomes available.
*******************************************************
XML-RPC Server for LabVIEW Version 1.0.0
Mark E. Smith
Sandia National Laboratories
This LabVIEW Project (8.5.1 and 7.1.1) provides
1) a LabVIEW XML-RPC server - accepts TCP/IP connections and calls XML-RPC Enabled LabVIEW functions
2) XML-RPC Message Builder tools - Allows conversion of supported LabVIEW data types to XML-RPC data types
3) XML-RPC Parser tools - converts XML-RPC data to supported LabVIEW data types
4) Method Template,vit - wraps LV VIs to create XML-RPC callable methods
This project is useful to allow any language that supports XML-RPC (most any, including Java, .NET, Perl, and Python - see http://www.xmlrpc.com/ for details) to call a LabVIEW built function. One example is for a Java application to control and collect data from a remote LabVIEW server. This server could be a real-time LabVIEW server (cRIO, for example) since this server should run on any LabVIEW target (including Linux and RT) and is compatible with LabVIEW 7.X - I say should be because I have not had the opportunity to test on a RT or Linux target but there are no dependencies in the code that aren't available on LVRT or Linux.
Is XML-RPC still useful given LabVIEW 8.6's Web Services capability? I don't know - I do know that XML-RPC is a lightweight implementation supported by many languages so the answer is probably "yes". XML-RPC complements rather than competes with the ReSTful architecture of the new 8.6 Web Services.
Getting Started:
Use the "Set Server State.vi" to start and stop the server. The "Call Generate Sine Wave.vi" demonstrates calling a LabVIEW function (the Sine Wave Generator) as an XML-RPC method. The actual method called is under XML-RPC Methods - open it to see how the XML-RPC protocol is converted to LabVIEW args and the LabVIEW output is converted to XML-RPC and returned to the server. Potentially any LabVIEW side function or VI that you create could be enclosed in this wrapper and called by anything (Java, Python, .NET, etc) that has XML-RPC support.

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
mesmith@sandia.gov
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.