NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.
I suggest that NI start shipping USB keys instead. USB has several advantages:
I'm very often in this situation:
At some point I realize that I have to change somehow my output indicator, say adding an array dimension, changing an element type, adding a cluster element, whatever.
Well, if I could just right click and choose "Adapt Indicator to wire"....
My current best general workaround is the following:
If the indicator I wanted to modify was, additionally, Hidden, there are a couple of steps more of Show/Hide... And if instead I invested in cosmetics of the indicator, I have to redo that again from scratch...
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.
When programming in FPGA, all the timing functions are polymorphic, meaning you have to configure it for either ticks, us or ms. If your not carefull, this can sometimes lead to unwanted error due to simply overlooking a wrong configuration, as in the following example picture:
I propose a simple indicator or different icon to easily see the difference. Something like this, only maybe better looking:
Ther are 10 pages of suggestions coming up when typing "probe location on wire".
AFAIK, none of them addresses this irritating behavior of probes:
The probe icon will snap to some algorithmically determined location which might result in illegible data flow during debugging, or might end up in a region of the diagram far from where the critical action takes place.
I know that what matters should be the VALUE of the probe, but WHEN to check the probe value is also critical, and in a visual development environment, this time is determined by monitoring the data flow (among other methods). This is where this uncontrollable probe location can be annoying at times.
My suggestion: just as for labels, let the user choose the location of a probe anchor point on a wire (especially when it branches off).
This idea is not to take the awesome OpenG functions and make them native. This idea is to take the native functions that exist today, and extend the functionality to mirror the OpenG equivalents. There are several functions to talk about and I realize this may make this idea fragmented, but they all have to deal with File I/O functions, that are native, but lack the features of the OpenG equivalent.
Generate Temporary File Path
Here we see the OpenG Temporary File Name allows for specifying the file name and extension. So for instance my name can be "My Temp File %d.hoo". I can also specify a subfolder to put things in, which makes cleanup easier because I can just delete the whole subfolder when I'm done. This can make a files in "%temp%\Applicatoin Temp\My Temp File %d.hoo", but the native function can only speicfy a extension for the temporary file.
Here we see the OpenG Strip Path Extension accepts a file and returns the root and extension. Here the function is polymorphic and accepts a string, a path, an array of paths, or an array of strings. This can be helpful if you have a file name and want to get the root and extension. OpenG also has a Convert File Extension which can replace a file extension if one exists. If one doesn't exist it adds one. This also is polymorphic and accepts a string or a path again useful for a file name, or a relative and absolute path.
The native function only works on paths, and there is no convert function.
Build Strip Path
Here the OpenG functions are polymorphic. The Build Path accepts a path as the base, or an array of paths. The name or relative path can be a string, or an array of strings, or a path or an array of paths. And the Strip Path accepts a path, or an array of paths to strip. This is 8 polymorphic types between the two functions, but the native functions combined only have 3. The native Build Path accepts a string or path as the name or relative path, and strip path isn't polymorphic at all.
For existing functions I understand NI hasn't changed much but when NI introduced the Get File Extension, and Generate Temporary Path, I was confused why NI wouldn't try to duplicate the standard OpenG functions. Sorta like how when NI made the Clear Errors accept an error to clear why they didn't implement the function similar to OpenG's filter errors which is polymorphic.
My particular use case involves TCP Connection RefNums and Queue Refnums, but this could be applied to ALL refnums, as well.
When passing a RefNum from one VI to another, I realize it's not useful to show the numeric value on the front panel connecting control/indicator.
However, what WOULD be useful is to indicate when it's a Not-A-Refnum.
Perhaps a red dot, or a red background, would indicate that this Refnum is Not-A-Refnum, and absence of the dot, or a plain background would indicate the opposite.
As a new adopter of the Unit Tetst Framework I was keen to export my UTF Results from the Result dialogue for use in an external test report (Word document).
The Save button creates a datalog file only suitable for Loading back into the same dialogue. There's no immediately obvious way to export your results in a readable format.
After scrutiny and assistance I found that you can configure automatic creation of HTML, ATML and ASCII formatted reports by changing your Project settings. Hmm. Not quite what I want.
I want to be able to quickly and immediately export my UTF Results to Clipboard or File in my chosen format from the UTF Results dialogue please.
There are suggestions on the Idea Exchange to annotate subVI nodes with various attributes (this one, for example). I think that's a losing strategy. There just isn't space for all the annotations that might be of interest on a given node, and not all of the annotations make a difference to user's understanding of a given node. As an example, knowing that a subVI is reentrant is very important to understanding how a point-by-point read subVI works but unimportant to understanding how Trim Whitespace works. Also, not all of the annotations that we could imagine are simple "on or off" settings. A subVI that uses a local variable might be using it in an iterative algorithm or might be using it to store state between calls. If it is storing state, that might be something that a caller should know about.
These are the sorts of things that could be scanned for on a VI when LabVIEW launches the Icon Editor. If we had standard glyphs for interesting attributes of a VI, LabVIEW could have a section to recommend glyphs to add to the icon. This would not be an automated "always add this glyph" system that some people have requested because I do not think that we want the glyphs on every node just because it has the attribute. But some nodes it is worth calling out, and putting it in the Icon Editor would make it easy to add such glyphs. We might even have a fast "add recommended and arrange layers" button that spills all the glyphs onto the icon and then moves them around to minimize overlap, taking the existing layers into account.
When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!
You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...
This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.
Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...
Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.
Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.
And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:
By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?
Sometimes I have several parallel array wires and I want to probe one of them with a graph probe. During debugging, I notice that I actually want to probe one of the other wires instead.
Create an new probe on the other wire. If we do that many times, we will have so many probes as to make it difficult to keep track of them all.
Create a new probe on the other wire and delete the old probe. Several steps.
Wouldn't it be nice if we could Control-click on a probe number on the diagram, get the switcheroo cursor, and then click on a different wire of the same type to move the probe over. It would work very similar to how we currently are able to swap terminals on the connector.
Summary: Allow switcheroo on probes
(Inspired by this discussion)
The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).
The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.
Allow BD code and FP objects to be copied to the clipboard from a VI in an older version of LabVIEW and then pasted into a VI in a newer version. If the code is obsolete or contains depricated functions then it should be processed the same way a VI is when loaded into a newer version of LabVIEW.
Wire : Right Click --> Visbile --> Label (Its void Now )
Solution : It can take the control Name as default label of the wire, instead of being Void
Not sure if this idea is already proposed.
According to my understanding and the following discussion:
certain types of Property nodes and Invoke nodes should be inlineable without any great problems.
I would suggest that the LabVIEW compiler get's a bit smarter about this aspect of limiting the ability to inline code. If there's no technical limitation regarding inlining of a property node or Invoke node which is fed with a reference (which does not originate from a local object i.e. a static reference to a FP object) then it should be inlineable.