LabVIEW Idea Exchange

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

In Visual Studio you have XML Schema tools etc. It is a breeze to e.g. populate a drop down menu based on XML from a web service, and my first thought when I see it in action is - why do we not have this at our fingertips in LabVIEW already? LabVIEW could have made it simple to create schemas, generate flexible XML etc. You could have wizards that helped you, and cluster to xml conversion like in EasyXML from JKI - and it should all feel fully integrated (toolkits are OK, but this really needs to have native support).

 

I am currently developing a web service in LabVIEW and the first thing I had to do was to abandon the few in-built XML functions and write my own serialization code (using terminal mode for the web service gave you XML without proper headers, and the in-built flatten to XML outputs XML is impractical in use). Once I have serialized a text table e.g. and published it - using that table feels incredibly easy in Visual Studio (add data source-> input web address etc.) , it would be much more difficult to do the same in LV.

 

I think NI should make a big leap in the use of web technology. The RESTful web service functionality was a great addition, but the doumentation is non-existing, and we should have come much further by now. I know there are some cool experiments going on with web based GUI editors, but LabVIEW 2010 was just released with very little news on this front so forgive me if I rant a bit...Smiley Sad

The NI SMTP library is good at making e-mailing simple. But now and then I will get error 363513 (an error occurred on the network).

There are multiple known causes for this error that one can prevent, but also some unknown. The error does not specify them. I am therefore still struggling to get my e-mailing routines impervious to this error. The library should return more specific errors.

 

There are multiple other known issues with this library, making it quite unreliable for automation purposes. A shame, as there are few alternatives available.

A few suggested VIs for beefing up this library could be:

  • check if server is online
  • set popular SMTP header values (I don't know them, like most of us I assume)
  • check if e-mail was successfully sent to recipients
  • meta data returned: unknown recipient, attachment size exceeds limit of xMB etc

 

Creating and modifying dashboard on the tablet / mobile device is quite painful.

As you can share them via mail or cloud, wouldn't it be nice to create and edit them on a PC and the share/deploy them to the tablet / mobile device?

 

Within LabVIEW or with a seperate standalone application...

Hello,

 

the current functionality doesnt allow to asynchronously call a method that has any dynamically dispatched inputs. This causes a need to create a statically dispatched wrapper around the dynamic method which then can be called.

 

This is a source of frustration for me because it forces you to have code that is less readable, and this doesn't seem to be any reason for having functionality like that. Since you allready need to have a class loaded in the memory to provide it as an input for the asynchronously called VI why not just allow to use dynamic dispatch there (the dynamic method is allready in the memory).

 

How it is right now:

DynamicDispatchAsynchCall0.png

DynamicDispatchAsynchCall1.png

 

Solution: Allow to make asynchronous calls on methods with dynamic dispatch inputs.

I know this was asked three years ago, but TRDP was fairly new back in 2017 and is becoming more in use in the rail industry.

 

As we are going to be moving away from Multifunction Vehicle Bus (MVB) networks over to TRDP, we need a solution to continue lab testing our software using LabView to simulate a vehicle interacting with a control unit using TRDP.

Extend the native LabVIEW queues to support network based queues. We have network streams which are very nice but they are point to point. Queues are extremely useful since they allow a many to one relationship. It would be nice if LabVIEW supported network queues. I have worked with a third party implementation which works reasonably well. However it would be nice if this was native functionality. Network queues are essential if you desire communication between different applications or for sending data from a TestStand environment to a LabVIEW front end GUI. They are quite powerful and would make it much easier for users to implement multi computer applications.

 

NOTE: I need to post an updated version of the Network Queue class. I have improved and extended this implementation.)

LabVIEW will always use the primary NIC if more than one NIC is present. It would be nice if the user could select which NIC to use programmatically and not need to worry about defining routes on the computer.

TCP/IP, UDP/IP, IrDA
LabVIEW doesn’t have any VI or function to retrieve connection information/properties like IP address, local port or service name, remote port, ect.
In order to get connection information, you have to make a functional global vi to manage connection information by connection ID for later to retrieve.

Native function or VI will be great help.

This is more of an object orientation thing rather than actor thing but would have huge implications for actor core VI, or Receive Message VI. Please add pattern matching into OO LV. It could look like a case structure adapting to a class hierarchy on case selector and doing the type casting to the specific class inside the case structure. You could have dynamic, class based behavior without creating dynamic dispatch VIs, and you would still keep everything type safe. https://docs.scala-lang.org/tour/pattern-matching.html

Please include into AF:
Certain templates, standard actors, HALs, MALs should be part of the framework e.g. TDMS Logger Actor, DAQmx Actor. Right now the framework feels naked when you start with it, and substantial effort is required to prepare it for real application development. The fact that standard solutions would not be perfect for everyone should not prevent us from providing them, because still 80% of programmers will benefit.

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

Selecting the browse button of a path control of a VI under a real-time target brings up the file system of the host computer. This is completely useless and misleading. If you select any file or directory with this, it won't work when you run the VI.

 

I propose changing the behavior that selecting browse (on a path control) of a VI under a real-time target to show the file system of the remote target. I've seen X controls to do this before. In fact, Drivven has one. If not, I would at least remove the browse button.

I have been recently asked by NI to answer a poll about what feature I would like to see as far as data management and access and at that time, I didn't really think about mentioning something which is dearly missing in LabVIEW: cloud storage access.

The reason for this request is that increasingly, files used by collaborations cannot always be copied locally (for instance due to their size or because of frequent updates), or managing local copies and updating the central cloud repository is getting prohibitively time consuming and cumbersome.

 

There exist a few attempts in this direction (e.g. GDrive for LabVIEW, a third party skeleton of a toolkit to access Google Drive, or LabVIEW Interface for Amazon S3), but there are some glaring absent ones such as Dropbox, OneDrive, Box or iCloud to name the most popular ones.

As I mentioned before, GDrive is a starting point but is missing some basic features such as folder list, comments, etc.

I cannot comment on Amazon S3, as I don't use it.

Obviously, there is no way to predict which cloud storage solution will disappear in a few years from now or which one will pop-up tomorrow and become popular, but most of the work has been done by those vendors, who provide .NET API for their cloud solutions (maybe not Apple) or at the very least a RESTful API. These APIs could of course be made community projects (like GDrive is to some extent), but their importance would seem to justify a minimal investment from NI.

 

 

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.

There are database out there that define signals with 64 bit length. And avoiding the need to use them as RAW frames would ease up the handling.

Working with XML is fairly common and an addition to the palette to replace a specific node value would be helpful. Besides, there's lots of space there yet.

 

This link saved time. Thank you to juliodia

for posting this.

 

https://forums.ni.com/t5/LabVIEW/XML-Update-Element-Text/td-p/1239026?profile.language=en&lang=en

It would be helpful if we could create raw IP sockets in order to have access to protocols other than TCP and UDP. This would open the door for LabVIEW to be used for general network testing. I would be fine if this extension meant the programmer was responsible for implementing the protocols. Simply having access to a raw IP socket would be a benefit.

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.

Most people know that Network Published Shared variables are pretty slow.  If you write to a SV and then immediately read from it, you probably will not see the new updated value.  One way to get around this is to write the value and then continuously read and compare the SV until the value is updated:

 

19125iABB76509B98916BC

Pretty straightforward to do, but takes time to set up, as well as some Block Diagram real estate.  

 

I think it would be pretty convenient (and easy for NI to implement) if there was an option for a SV to wait until updated.

 

It could either be an option from the right click menu, (that of course would update the icon to signify that it's now a blocking call) or use an input to the variable, or maybe a combination of both:

 

19137i8D45A8D78F9A98A9

Aren't you tired or seeing Labview, or LABview or LabView online?

 

NI Certifications (CLA, CLD, etc) should be stripped off people engage in miss-spelling LabVIEW.

 

And those who aren't certified should handwrite "LabVIEW stands for Laboratory Virtual Instrumentation Engineering Workbench" 10 thousand times!