Jump to content

Remote Control, Monitoring and the Internet

6 files

  1. XML-RPC Server for LabVIEW

    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.

    3,288 downloads

    Updated

  2. Ping dotNET

    Ping dotNET v1.0.1
    Copyright © 2009, John Lokanis
    All rights reserved.
    Author: John Lokanis
    LAVA Name: jlokanis
    Contact Info: Contact via PM on www.lavag.org
    LabVIEW Versions:
    Created and tested with LabVIEW 8.6.1
    Dependencies:
    Requires .net 2.0 or higher
    Description:
    This VI performs a ping operation on the requested IP address or host name (requires DNS)
    the timeout for each ping as well as the delay between pings can be specified.
    The results are provided as arrays of each output type and in a text format designed to
    mimic the command line ping output.
    Instructions:
    Enter a valid IP address or host name and execute the VI.
    Known Issues:
    None.
    Acknowledgements:
    MSDN
    Change Log:
    v1.0.0: Initial release of the code.
    v1.0.1: Updates to the readme file and arrangement of the folder structure. (Mark Balla)
    License:
    Distributed under the Creative Commons Attribution 3.0 (http://creativecommo.../about/licenses)
    See link for a full description of the license.
    Support:
    If you have any problems with this code or want to suggest features:
    please go to www.lavag.org and Navigate to
    LAVA > Resources > Code Repository (Certified) and
    search for the "[CR]Ping dotNET" support page.
    Distribution:
    This code was downloaded from the LAVA Code Repository found at www.lavag.org

    1,448 downloads

    Updated

  3. NI Web Service Server

    NI Web Service Server v2.0.0
    Copyright © 2010, John Lokanis
    All rights reserved.
    Author: John Lokanis
    LAVA Name: jlokanis
    Contact Info: Contact via PM on www.lavag.org
    LabVIEW Versions:
    Created and tested with LabVIEW 2009
    Dependencies:
    Requires .net 2.0 or higher, LabVIEW 2009 or higher.
    Description:
    This Project contains a set of VIs and support files designed to build an installer that will place the 'NI Web Service Server' on a target machine.
    The NI Web Service Server is a small LabVIEW EXE that runs as a Windows service in the background, keeping all LabVIEW web services running regardless of what other applications are running on the machine.
    Also included are a few web services that support the following:
    Getting screenshots of the target machine on demand.
    Getting VI Front Panel images from any running LabVIEW EXE on the target machine.
    Getting EXE version information from any running LabVIEW EXE on the target machine.
    Testing the web service with a simple 'echo' command.
    Please refer to the included 'NI Web Service Server.pdf' file for a more detailed explaination.
    Instructions:
    Build the various components and desired installer, then install to target machine. Use any standard web browser to access the web services.
    Known Issues:
    None
    Acknowledgements:
    NI Knowledgebase, MSDN
    Change Log:
    v1.0.0: Initial release of the code.
    v2.0.0: Ported to LabVIEW 2009.
    License:
    Distributed under the Creative Commons Attribution 3.0 (http://creativecommo.../about/licenses)
    See link for a full description of the license.
    Support:
    If you have any problems with this code or want to suggest features:
    please go to www.lavag.org and Navigate to
    LAVA > Resources > Code Repository (Certified) and
    search for the "[CR]NI Web Service Server" support page.
    Distribution:
    This code was downloaded from the LAVA Code Repository found at www.lavag.org

    3,172 downloads

    Updated

  4. Skype SDK

    Copyright © 2008, Antoine Châlons
    All rights reserved.
    Author:
    Antoine Châlons
    -- see readme file for contact information
    Description:
    These VIs embed ActiveX methods and properties to control Skype from LabVIEW.
    List of functions :
    - Launch / shut-down Skype
    - Retrieve contact list
    - Get profile info
    - Set user status
    - Get / set user mood
    - start / stop Skype call
    - Skype chat with contact(s)
    - Send Skype SMS
    Dependencies & Installation:
    To work it requires to have Skype4COM installed (version 1.0.31 or newer), you can get it from https://developer.skype.com/Download.
    To install Skype4Com run the following command : regsvr32 skype4com.dll
    To allow a program to use the ActiveX Skype interface you have to enable it in Skype:
    1. Skype Options
    2. Advanced
    3. Manage others programs' access to Skype
    4. Select your program (LabVIEW.exe) and click change if the text 'Not allowed to use Skype' is shown
    After that you can talk to Skype, otherwise you will get a question inside Skype that asks you to allow or deny your application.
    Support:
    This code was written with LabVIEW 8.6
    Change Log:
    1.0.0: Initial release of the code.
    1.0.1: Additional installation information.

    2,223 downloads

    Submitted

  5. TCP IPv6 Tools for LabVIEW

    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.

    2,769 downloads

    Submitted

  6. ActiveDirectoryTools

    Copyright © 2006, Mark E. Smith
    All rights reserved.
    Author:
    Mark Smith
    --see readme file for contact information.
    This VI uses a .NET 2.0 DLL (DirectoryTools) to search Microsoft Active Directory. The DirectoryTools DLL uses the System.DirectoryServices namespace. The DLL exposes some simple functionality to LabVIEW in a form more user friendly to LabVIEW than direct calls to the System.Directory classes.
    Important Note: This implementation will only retrieve the first property of any record that matches the PropertiesToLoad - additional instances of an identically named property in a record are not returned
    Using this VI - this VI was designed to return all the computers on a given MS Windows network. The default filter (objectClass=computer) along with the default PropertiesToLoad of "cn" (common name) will return the name of all computers registered on the network. Any valid filter string and property may be used.
    Mark Smith
    Change Log:
    1.0.0: Initial release of the code.

    687 downloads

    Submitted




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.