NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas (http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas/tab/most-kudoed) 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.
When programming with large applications, often times you'll have clusters carrying a lot of information. If you hover over the cluster wire and observe Context Help, you might see something like this:
This Context Help window above is rather large and doesn't necessarily make it any easier to see the structure or contents of the cluster. My proposed idea calls for the ability to expand or collapse the cluster contents within the Context Help window, such as this:
I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).
But many VIs written by NI have been programmed very sloppy.
Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:
Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.
Probes are so useful for debugging, but monitoring them within the Probe Watch window can be a headache. I constantly find myself focusing back and fourth between Probe Watch and the code to translate a probe number to a position in the code. A solution would be to have the probe's value float just above the probe itself. LabVIEW already has a similar feature. When you use Highligh Execution wire paths display their current vaules, but using Highlight Execution is too slow and no practical for every debug situation.
A graphical programming language deserves to have great graphical tools representing the design of big applications.
It is possible to use scripting to understand if a method of a class has another class as input or output terminal and to know if a class composes another class in private data. The only thing I cannot do right now myself is to show this information in Class Hierarchy window. Representing the usage and composition relationships only requires parsing through the project once, and then every time it changes.
I am right now using a script to parse through all project classes to understand which have what relationships, which are actors and which are messages and I draw a Plant UML diagram from that. The intermediate step is to generate Plant UML text, but this should be integrated into LV.
Please improve the readability of object oriented project with additional tools for LabVIEW. This is especially critical for NXG, where the currently the ability to understand an OO project is even more limited than LV19.
In Enthought's python integration toolkit (PITL), the "Open python session" VI accepted as an input the path to the python.exe file to use for the python kernel. In LV2019 the "Open python session" accepts a string "2.7" or "3.6", and then labview searches the system path to find the python installation. The LV2019 method is vastly inferior to the PITL method. Due to the way the LV python node requires one to manipulate the system path in order to find the desired python installation, I realized that this is a complete non-starter for sending compiled applications to end users, because the end user may have multiple python installations on their computer, and I can’t expect them to bend over backwards just to be able to use my compiled LV app.
I do not know how NXG currently handles this, but I hope that they emulate the PITL method. Furthermore, it would be great if NXG could handle arbitrary python distribution, such as Anaconda, rather than just the bare bones installation from python.org. It would also be great if there was more documentation about the python node in general--there is very little to be found currently. The Labview python node is shrouded in mystery (e.g. what the heck is NIPythonInterface.exe) whereas the PITL was very self-explanatory. It is a shame that NI displaced such a useful product and replaced it with an inferior one.
In 2014 the Clear errors VI now accepts a single error which can be cleared. This is nice but when I heard NI was implementing their own filter errors, I assumed they would do it in a similar way to the OpenG Filter Errors VI, which accepts a scalar, or an array of error codes to filter.
In addition to this I think it would be helpful if this Clear Errors also accepts the error data type for errors to filter, or an array of errors to filter. That way the Error Ring can be used to help readability of the block diagram showing the error that is being cleared.
I really hate having to dig through a long hierarchy of menus when I know what I want:
Visual Studio (and other MS and non-MS products) have a feature called Intellisense, which is meant to make this easier. Basically, as you type, it pops up a list of matching objects, based on context, so you can quickly select what you want:
It would be nice if LV had a similar feature - click on a property in the property node using the text tool (or Ctrl+click if using the auto-tool) and now you can type in the property name and you will get an Intellisense-like pop-up, which will have all the relevant properties.
Specific features it could have:
It should know all the relevant names - full names with the hierarchy (Boolean Text.Font.Color), long names (Mechanical Action) and short names (MechAction). This could probably be similar to how Quick Drop handles shortcuts or they could simply appear as separate items.
It should be context sensitive. If the class is Boolean, then there's no need to have Listbox properties in the list.
It should match all the properties which include the search string (so "in" on a boolean would match both "Indicator" and "Strings") and only them.
It should have the ability to use caps for acronyms (e.g. in the above screenshot you could use "BT" instead of "Boolean Text", similar to what appears in this video).
It could probably also work on the invoke node, although there it's less needed.
It could probably also be used to quickly select a class if you have a class specifier using the same basic mechanism.
This example (LV 2009) shows how useful this could be. You don't need anything installed. Just run the VI and start changing properties.
It will only work on the last property in the node.
It doesn't have the proper list of names and it doesn't implement all the features in the idea, as this is just a basic example.
Note - this is similar to this idea, but I think that it's much more usable. Also note that the second idea refers to a QDKS which ships with 2010, but that is far from perfect.
I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds.
With the advent of the IoT and the growing need to synchronize automation applications and other TSN (Time Sensitive Networking) use cases UTC (Coordinated Universal Time) is becoming more and more problematic. Currently, there are 37 seconds not accounted for in the TimeStamp Which is stored in UTC. The current I64 portion of the timestamp datatype that holds number of seconds elapsed since 0:00:00 Dec 31, 1900 GMT is simply ignoring Leap Seconds. This is consistent with most modern programming languages and is not a flaw of LabVIEW per se but isn't quite good enough for where the future is heading In fact, there is a joint IERS/IEEE working group on TSN
Enter TAI or International Atomic Time: TAI has the advantage of being contiguous and is based on the SI second making it ideal for IA applications. Unfortunately, a LabVIEW Timestamp cannot be formated in TAI. Entering a time of 23:59:60 31 Dec 2016, a real second that did ocurr, is not allowed. Currently IERS Bulletin C is published to Give the current UTC-TAI offset but, required extensive code to implement the lookup and well, the text.text just won't display properly in a %<>T or %^<>T (local abs time container and UTC Abs time container) We need a %#<>T TAI time container format specifier. (Or soon will!)
I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.
There are so many good nuggets of Array manipulation code in OpenG. This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays. Lets start with the Index Array, one of the most commonly used functions.
Here we see the native function allows for an N dimensional array to be indexed. The OpenG function only supports 1D and 2D arrays. And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row. Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices. You can pass in an array of indices and pull them all out in the order defined. This can be used as a reorder function that takes an array and scrambles it the way you like. Adding this feature is already on the idea exchange.
Again when it comes to polymorphism the native function beats OpenG. The native delete supports deleting from N dimensions where OpenG is just 1D or 2D. But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns. This would be a nice addition to the native function.
A conditional auto index function doesn't exist natively in LabVIEW. You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful. This idea is on the exchange in multiple places, Link 1, Link 2.
Ever need to remove duplicates from an array? Or remove all zeros or NaNs from an array? These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette. A nice feature of the remove and filter are they output the indices that were removed. Combined with the fact that the delete, and index accept multiple indices make these very useful. Also the items to filter for the filter can be a scalar or array which is nice.
Ever want to sort an array and know how it was sorted? This OpenG function can do that along with specifying what order, ascending or descending to use. The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.
The current implementation of Control References on the Block Diagram could be improved. This Idea was first conceived over a year ago in a discussion on Smaller Static Refs, in the comments here.
Consider the following advantages:
It's generally bad style to have Ctl Refs with hidden labels. New implementation always demonstrates the label to comply with inherent self-documentation of G (just like a Local)
Smaller footprint combined with better visual distinction between Ctl Refs doubly improves information density
In general, the Control Class does not need to be shown at all times on the BD. Rather, it could be shown in Context Help (currently, CH is not useful when hovering over Controls Refs, but this is another topic), or determined by browsing Properties/Methods.
Eliminates the undesirable ability to rename/delete a Control Ref Label such that it no longer matches the Terminal Label.
Creates a better distinction between a Control Ref and a Control Class Constant (NULL Ref). The color of the Static Refs denote a "live link" with a control, while the muted tones of a Class Constant indicate no such link (NULL)
Complements the new LV2010 Local Variable upgrade (see image), yet remains distinct by having a different glyph, different background colors, and no directionality arrow
In summary, a Control Reference revamp could reduce the footprint, increase readability, and prevent obfuscation that decouples the Static Control Ref from the Control.