LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

It would be nice to improve documentation created by Tools->Import->Web Service... wizard.

Especially, I suggest to automatically create Description in created .lvlib Documentation so that it would be immediately clear which WSDL URL is handled by that library. Currently, WSDL URL is only placed as a String constant in Open Web Service.vi which is not really convenient.
Thanks for understanding and support.

As far as I can tell the SMTP Email VIs on the SMTP Email pallet do not support any sort of authentification.  Unless I am missing something this makes them close to useless.  It definately makes them usless to me.

 

I think there should be a login (and logout) VI where the login session is passed into the other VIs via a reference object.

The current implementation for remote debugging needs two ports to be opened on a stand-alone firewall in between.

  • Port 3580 to connect to the NI service locator on the target machine
  • A random port for the application on the target to connect to
    This port is dynamically assigned to the application by asking the OS for a free one

 

This dynamic port cannot be pre-configured on the stand-alone firewall except by opening up the whole port rang above 1024.

The latter is something no IT person with any sense of security will do !

 

So we need to be able to pre-configure a certain port for the target application, so that we can open a dedicated port for this connection on the firewall as well.

Otherwise this whole remote debugging feature is useless to us.

It would be nice to be able to declare the port number of a web service in the service locator, so clients could be a little more port-agnostic. Extra points if we could bootstrap it such that the URL required to hit the web service didn't require a port number at all, and the port could be resolved via the Service Locator. But I would settle for a way to do a manual two-step process to request the port number by name and then use that number when building the URL.

 

Standard IEC 61850 Allows INT64 this is not support by NI-Industrial Communications for IEC 61850.

Add support for INT64.

Hello,

 

when you use the URL property node for network streams you allways get localhost url only. 

NS URL.png

 

The Idea is simple. Just to change the information provided by this URL not for localhost but for the other endpoint of the connection. This would simplify managing multiple stream connections.

 

Currently, the NI real time devices use FTP for programming and configuration. Services such as telent and FTP are not encrypted and can pose a potential security risk, and are not approved by some IT departments.

 

I suggest a feature for the real-time operating system to have an administrator selectable option to use SSH/sFTP for programming and configuration instead of FTP.

Give LabVIEW full parity with the CVI 'Network Variables' API.

CVI has many useful API functions such as adding a NSV to a existing deployed process

or registering for SV change events that are impossible in LabVIEW.

When you use "Labview Web server", you cannot access your Labview front panels using IE from a PC with no Labview Runtime.

 

To make it work you have to install a Labview runtime, or deploy manually some dll's ...

 

So, it would be nice to create a "light Labview Web client installer" in order to only install the minimum required.

 

Manu.

It could be useful to simulate problems between the devices and the OPC Server (NIOPC Servers for instance).

Adding new optional parameters to DataSocket Write, as such as, Quality, Substatus and Limit Status (Extract from: http://www.visavisoftware.com/Html/OpcServerQualityFlags.htm), we could create different situations to test our applications.

 

This is a possibility:

idea.JPG

Thanks

When deploying a CAN db, an alias needs to be created to access the database. The writeup is deeply buried in 4-538 of the manual (1200 pages).

 

An example with a simple switch between the dev & exe should be added to help save time and trouble. Or simply add the functionality to an existing example.

 

Thank you!

 

 

If you've ever tried to use the LV Web Service > Session VIs for sessios, authentication, user management, etc., then you'll quickly notice that they're lacking an important feature:  the ability to detect when a user session times out (expires).

 

I can think of two important use cases as of why you'd care:

(1) The user/client is viewing sensitive information (served to him by a LV web service), and then decided to walk away from his computer as we do sometimes.  Any Joe walking by might then get a glimpse of something he shouldn't.  

(2) For logging purposes.  It might just be nice to know when the user logged in and when the user logged out for your IT records.

 

With a securely built web service, you could detect the user isn't there anymore, and direct the web client (Chrome, FF, IE, etc.) to redirect the page and destroy the session.

 

 

There's a sister idea that goes along with this, but I don't think I'll post in a separate thread unless needed.  So, another way to detect session timeout events would be to get the session ID cookie (from Create Session VI), store each cookie in memory somewhere, and essentially poll them in a background loop for session information (ie session still exists?).

 

Ho hum, maybe I'm the only one building web applications of this type, but it sure would be a helpful feature in my opinion.

In the data dashboard I continously call a webservice (poll webservice) whose return values can be linked to indicatorson the dashboard.<br>Even in case the selected webservice supports parameters too, it would be nice to link these to controls on the dashboard.

I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.

 

When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.

 

Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?

Module to further customize the remote panels generated by the tool "Web Publishing Tool". That is, because right now we can only customize a title, header and footer.

 

remote panel2.PNG

 

 

Would be very nice if we we could customize things further. This I thought, because many do not have the knowledge related to web design, but if you constantly use remote panels and would like to see the most pleasant pages. (For example, see a image, or a different color, so on). Something similar to what was done with the "Model Builder Robot simulation" of the "LabVIEW Robotics" that now allows create our own worlds and robots. But would focus on web design.  

a simple idea would be: 

panel2.PNG

Currently the Labview Database Tool Kit doesn't support returning or working with temp tables in a stored procedure.  This makes a SQL/Labview developer have to make complete hacks (such as returning tables in comma delimited form) to return results that take multiple table manipulations to generate.

 

See this thread for an example:

 

http://forums.ni.com/t5/LabVIEW/SQL-Query-Works-in-MS-SQL-Server-2008-but-not-when-using/m-p/2151492

 

The import Web Service tool is very interesting and practical. However, many companies are using web services with authentication in xml script. This import tool doesn't work with the WSE3 protocol, from Microsoft, one of the authentication tools for soap services. I expect to see this implementation in the next version of LabVIEW.

Hello,

 

I have a current need to be able to SSH to a "black box" Labview doesnt seem to have any support or any precanned vi's to be able to do this in a reasonably simple fashion. Maybe create a open, read, write, close for those of us who need to ssh. Thanks for your help and time.

My idea is to enable access logging for the Application Web Server.

 

In this way access to a web service can be analyzed which is also useful in debugging timing or performance problems of your application. To facilitate easy analysis, industry standards like the "common log format" or "combined log format" (link) should be used, then analyzer tools like AWStats can be used. The Appweb Embedded Web Server, which is the core of the Application web server, does already support logging so getting this running should be easy.

Currently, the Deploy Library Invoke Node and DSC Deploy Libraries vi will only work with bound libraries that have a PSP based URL. (\\192.168.0.2\process\variable)  But there are some use cases where you need to have logical URL's (\\cRIO1\process\variable) that will adapt to changes in the .alias file which maps target names to IP addresses.  If this is your use case then it is tedious to do the same thing programmatically since you will have to create your bound libraries with an initial default PSP URL and then programatically modify all URL's based on a 'designated' target IP.  Since the project can do this I assume that it should be relatively easy to provide this functionality.