LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

SQL Command Query for Database Toolkit

I would like to see a tool in which you can actively see outgoing SQL queries as they are generated by the program.

While attempting to troubleshoot one of my programs in which I was pulling and updating data from a database, I had no way to confirm that the queries I was sending out had the correct syntax. The error message I was receiving indicated there was a syntax error, but it was a little difficult to confirm where the issue was, or if really was a syntax issue at all. Being able to see a string of the actual query would help a lot for troubleshooting programs that generate queries dynamically.

View All (8)

Almost all LabVIEW data types can currently be sent through a shared variable without any hassle. The notable exceptions are native LabVIEW classes, which cannot be selected as the data type for a shared variable. This causes a problem for anyone who wishes to send objects across a network. They are forced to rethink their use of LabVIEW classes, use a communication method other than shared variables, or flatten and unflatten the object on either side of the shared variable communication. The use of classes is growing more common with every version of LabVIEW, so I think it is time for these two prominent LabVIEW features to work together seamlessly.

View All (2)

If you are using TCP to communicate to a different code environment, you may want to set some of the socket options. For example, for responsive control, you will want to disable Nagle's algorithm. There is currently no obvious or easy way to do this. TCP Get Raw Net Object.vi in <vi.lib>\utility\tcp.llb will provide the raw socket ID, but you then need to call setsockopt() on your particular platform using the call library node. You can do this with the code provide here. A much better way would be adding a property node to the TCP reference that allowed you to set and query the options directly.

View All (3)

The current low level implementation of TCP functions only accesses a data stream, but not the raw data of the tcp telegram. It would be nice to have a low level TCP "Read/Write Telegram" function to get additional information from header or footer, like time stamps. Maybe as a buffered stream, like the current functions.

The resulting cluster could look something like this:

http://www.cisco.com/c/dam/en_us/about/ac123/ac147/downloads/customer/internetprotocoljournal/ipj_3-2/images/figure01.gif

I would like to be able to obtain the IP Address of an application instance.

Here is one scenario:

Plug in architecture.

Host machine loads plugin VIs that monitor several targets via VI Server.

The main VI opens the connection to one of the targets' application and sends the application reference to the plugin so this VI knows what target is communicating with.

It would be nice to be able to obtain the IP address from the Application Reference via a VI or a property node.

Now, I know I could be sending the IP Address instead of the application reference, but if I know I am going to be calling several VIs in the same target, why do I need to open an application reference for each VI, when all could share the same application reference.

Another scnerario for this was posted here: http://lavag.org/topic/6861-address-of-an-application-instance/

View All (6)

This idea started when I realized the WebDAV API provided by NI does not have the ability to read the File Creation information on a remote file.

"That's okay" I thought, I'm a programmer and will add it myself. Looking at the source it looks like NI just leveraged someone else's protocol, and wrapped it into some Call Library Function Nodes. NI could have written the WebDAV API wrapping their own HTTP API functions, using G instead, allowing for customization but they didn't.

"That's okay" I thought, I'm a programmer, and I'll look into recreating the WebDAV API, by calling the NI HTTP API. Looking at the source sounds like NI didn't implement all of the HTTP functions available, only the most basic ones. And since WebDAV requires more than just the PUT, GET, and POST, that means also having to update the HTTP API to have those functions, so that I can rewrite the WebDAV API. Oh but look at that, NI also just (seemingly) wrapped someone else's implementation again into Call Library Function Nodes, this time calling the ni_httpClient.dll. NI could have written the HTTP API wrapping their own TCP primitive API functions using G instead, allowing for customization but they didn't.

So this idea is for one or more of the following things, from the easiest, to the most difficult.

Add the File Creation Date, as returned information from the Get File Info of the WebDAV API.
Implement the WebDAV API in G, and eat your own dog food.
Implement the HTTP API in G, and eat your own dog food.

View All (2)

I would like to see new Read and Write VIs for TCP and UDP connections that worked the same way the Read From Binary File and Write To Binary File work. These file VIs are polymorphic and allow you to specify the format of the data being written or read. With only the current Read and Write VIs available for the TCP and UDP connections we must always include typecasts or other data parsing. LabVIEW obviously has the means to do this since it exists for files. Extend that capability to the newtrok connections as well.

View All (3)

Idea Exchange for NXG!

NXG needs an Idea Exchange. The feedback button is a lame excuse for a replacement. Why?

I can't tell if my idea has been suggested before. (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
Many ideas start out as unfocused concepts that are honed razor sharp by the community.
This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

View All (2)

OPC UA API as a stand-alone add-on

We were thrilled to see that NI developed an OPC UA API. We develop software for both VxWorks and Windows, so having OPC UA available on RT is great. But having to shell out for the entire DSC suite, run-time licenses and all, just to be able to use the same API on Windows is unreasonably costly and forces us to use a different API on Windows. If we could buy the API as an isolated component at a more reasonable price (and with easier licensing) we would jump for it immediately.

A generalized version of the idea:

The DSC can still function as a nice bundle, where the price for the bundle is lower than the total for each individual item, but when NI makes such packages please make it possible to pick-and choose amongst those components as well, so that in cases where you actually have a need for just one of them, you can get it at a price that is reasonable for that individual component.

LabVIEW crashes randomly when network functions are used on Linux. This problem appears especially when many connections or files are open.

R&D has identified the issue but is evaluating wheter or not the issue will be resolved in future releases.

All the details are here :

https://forums.ni.com/t5/LabVIEW/TCP-Allow-files-descriptors-gt-1024/m-p/4297433#M1255356

An example is attached.

Download All

View All (5)

Encryption of VI Server traffic

By default, VI Server uses TCP to communicate between applications. This stream of data is not encrypted and open to hacking and snooping.

My suggestion is allow VI Server traffic to be encrypted, perhaps using SSL/TLS or an AES algorithm.

The reasons are obvious. There is an increasing number of cyber attacks in industrial control systems. Many cyber attacks are perpetrated internally, so a firewall or air gap is only so helpful. And in certain environments (ie military, medical) you can't even consider transmitting data without encryption. This means VI Server is not an option for many users.

I see that LV2020 now supports SSL/TLS in its TCP functions (see here), so the logical next step would be to make use of this in VI Server also.

View All (1)

I know this is another Raspberry Pi idea, but hopefully the answer is simpler than some of the past requests (maybe as simple as "no"). I am wondering if it would be possible to run a simple labVIEW executable on a Raspberry Pi with the sole purpose of viewing network published shared variables. This could provide a low cost UI terminal for distributed hardware. My hope is that the required drivers are minimal in that only a network connection is required and no hardware drivers for the NI products would be required. Basically, it would be similar to the data dash board app but would allow much more customization by the developer for software based analysis and display.

Webservice for Mac/OS, Linux

Hi everybody!

We are using the Webservices of Labview very extensively and are pretty happy with this new functionallity, although recently we had a client who requested

to access some services via http on a mac based environment. I was surprised when i found out that OS X is not supported for webservices (the same with linux). We had to hack around and found some solutions which were acceptabled but not really elegant, so what i think is that it would be great to have webservices besides windows at least on linux and OS X available. This feature will be used a lot in the future and it would be a pitty if you have only half of the labview capabilities on some systems.

Thanks a lot Andy

We have cloud computing, virtual Machines, CPU virtualization etc. - There are numerous ways of achieving parallel and distributed computing, available at different architectural levels. The inherent parallel nature of the LabVIEW graphical programming means we can often achieve parallel computing without thinking.

-But in cases where the programmer actually needs to make a decision we now have the Loop Iteration Parallelism option.
If an action is to repeated multiple times and the execution of each run takes longer than the overhead of communicating the input data, execution code and/or output data across to multiple targets, parallelization can reduce the total execution time, and/or reduce the load on each target. Now, in some cases the execution time can justify parallelization even across slow communication channels.

What if we expanded the user-friendly loop iteration parallelization mechanism to also support remote processors?

On the targets we want to offer as execution hosts we will need to install a host service. This service might offer us the choice of offering all, or just a subset of the available cores. Perhaps even decide this based on the current load on the target, or time of day(!). The targets can be of different platforms as long as the code is possible to recompile for it.

So how would this look like to the programmer? Well, we simply extend the for loop parallelization function dialog to something like this:

The loops should also allow this setup to be changed at run-time. You could have a general VI to define the default targets and establish a link to them, and each for loop could have input terminals to specify the parallelism options to be used at the time of execution.
Another fun consequence of this functionality would be that you can really distribute *any* part of you code across multiple targets simply by wrapping it in a 1-iteration only loop.

With this functionality in place getting 10 machines to work on a heavy problem instead of just one would really be as simple as drawing a for loop...

Extend on the concept of the termchar to include a multicharacter termination string for VISA reads.

Ideally, the termination string could be defined as a regex.

When I establish a connection with a linux based Device Under Test using a terminal server or TCP socket, the device ready prompt is the typical username@hostname:#

I currently read the VISA session in a tight loop a byte at a time and buffer the characters to compare to a regex of \n%s@.+?:[~|(/(\w)+)]+?#

The time required depends on the length of the response from the device under test, so I have to keep track of the total time myself; I can't use the VISA timeout.

If NI-VISA supported a regex based multicharacter termination string, I could set my VISA session to look and wait for the prompt.

In the old days when VISA was first designed, I'm guessing that this sort of functionality would have been taxing on the memory and CPU. With today's 64 bit GHz multicore processors, abundant RAM and common regex libs, I don't hink this would affect timing.

View All (3)

Hello,

I'd like to humbly and respectfully suggest that "Internecine Avoider.vi" be rewritten or at the very least, refactored extensively. (again)

This VI is found in "TCP Listen.vi", which is on the TCP palette. It maintains a registry of existing listener connections and attempts to reuse them.

What's the big deal, you ask? Well, when I'm having problems with listeners and need to figure out what's going on, sometimes I need to look into this VI. Like a lot of NI code that I generally trust, I would ordinarily skip over this and disregard it as a possible source of problems. The trouble is, every time I look at it I can't easily decipher the nuances of what it does, given its messiness. Thus, though it may be perfectly functional, I don't trust it.

I realize the code could be a whole lot worse. I also realize that someone has been in there since LabVIEW 2011 was released and has made some improvements. Kudos to that individual for all the new free label comments.

Nonetheless, here are some factors that obfuscate this VI:

There is no documentation under "VI Properties". What does it do, at a glance? (I know the answer because I've stared at it over a few versions of LabVIEW)
"TCP Listen Internal List.vi" also has no documentation under "VI Properties"
Without nitpicking, there are some sloppy practices employed in here that don't make a lot of functional sense.
Deprecated "Retrieve Element" case in the internal list VI. "Item Requested" is no longer a requested item, but the result of a search on elements.
"net address" is confusing and ambiguous Couldn't this be named, "Address of Listening NIC?" (Yes, I know it's documented under LabVIEW help for the TCP listener VI)
"Conflict" is ambiguous. This should be renamed to something more intuitive like, "Conflict: Multiple NICs Using Port" or something similar.
Un-typedef'ed clusters in the internal list VI, with deceptive ordering of elements, combined with unnamed unbundler functions.

... etc.

I got to thinking... I know it works, or at least I think it does, but couldn't this be done more simply and elegantly?

I know, I know, "If it ain't broke, don't fix it." ... but I think it could still use some work to make it more intelligible.

Respectfully,

Mr. Jim

View All (1)

Working in the telecoms industry at several different companies and for many products I need to be able to provide a test station with DHCP functionalitly in order to be able to communicate with units under test. I have seen a posts on LAVA and the NI forurms that say I am not alone in this.

Currently I achieve this using third part products, typically with command line call using the system_exe. I mainly use tftpd, but it would be nice to have such functionality build into LabVIEW.

cheers

Dannyt

View All (1)

The Labview Web Services should support digest access authentication (RFC 2617) in stead of NI's own inventions NI Auth and NI API Key (the latter is broken in 10.0f2). Digest access authentication is becoming a standard and is intended to replace basic access authentication since it doesn't send passwords in plain text over the web. It is very useful for cases where HTTPS cannot be used, for example for performance or legal reasons.

Digest access authentication does not require Silverlight at the client side like NI Auth does - it requires only a recent browser. In this way the choice of HTTP clients is much less restricted and for example a cell phone can be used too.

It shouldn't be that difficult for NI to get this done, the webserver behind it already supports it. Of course the Labview HTTP Client should also support digest authentication.

LabVIEW Idea Exchange

SQL Command Query for Database Toolkit

Shared Variables should support LVOOP as a data type

Property Node to Set Socket Options for TCP

TCP/IP Low Level Functions: Read/Write Datagram

Obtain the IP address from the Application Reference

WebDAV Creation Date, HTTP and WebDAV APIs

VPN functionality included in LV (Virtual Private Network)

New Read/Write VIs for TCP and UDP connections

Idea Exchange for NXG!

OPC UA API as a stand-alone add-on

LabVIEW crashes when calling network functions under Linux

Encryption of VI Server traffic

Develop software to allow porting of LabVIEW executables to Raspberry Pi to enable reading and graphical display of Network Published Shared Variables

Resolve XNET 52 bit signal length limit

Webservice for Mac/OS, Linux

For loop parallelism across multiple remote targets

Add regex based termination string option to NI-VISA

Refactor or Rewrite the TCP Listener Internecine Avoider

I would love to have a Native LabVIEW DHCP server

Digest access authentication support in Application Web Server and HTTP Client