LabVIEW Idea Exchange

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

In the project explorer, dragging an item into a folder opens that folder AFTER the drop. This is annoying. But I digress...

In fact, what would be useful is to have the behavior of the two file explorers I am familiar with (Windows and Mac OS), that is:

 

- if an object is drop onto a folder icon, the folder does not open (see link above)

- if the object is held for a while over the folder icon, the folder opens

 

This is particularly helpful if the project explorer has a hierarchical structure of Virtual Folders:

 

Screen Shot 2015-06-05 at 10.44.15.png

If I drag Untitled 1.vi over the Action folder and hold it here for ever, nothing happens, and in particular, I can't access any of the the subfolders.

After dropping it, I get this:

 

Screen Shot 2015-06-05 at 10.44.40.png

 

Now the top folder is open, but the VI is nowhere where I want it to be and I need to repeat the drag & drop action.

 

This example doesn't do justice to the real issue which is that for large lists of VIs and folders in a project, this becomes a real problem, as VI and target folders (after everything is opened to provide a clear path from original to target destination) may end up separated by large amount of space in the project explorer and you now have to use the temperamental "Drag the object over the 1-pixel wide location at the top of the project explorer to trigger scrolling" feature in order to slowly bring the object to its remote destination.

Hi there,

 

I want to suggest a function for case structure tunnels:

 

Create constant in every case

 

If you have big case structures, and want to add a tunnel with constants inside, you have to add a lot of constants. This

could be avoided if you could add a constant for every case and then only adapt the value.

HI This idea may be addition to THIS.

Untitled.jpg

PBP 

I'm very often in this situation:

Screenshot from 2015-05-25 11:18:57.png Screenshot from 2015-05-25 11:18:49.png

 

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.

 

Screenshot from 2015-05-25 11:22:22.png

 

Well, if I could just right click and choose "Adapt Indicator to wire"....

 

My current best general workaround is the following:

 

  1. Go to the wire source (may be far away on the BD) and right-click "Create Indicator"
  2. Select the newly created indicator and double click it to select it on the FP
  3. Ctrl-X cuts the new FP indicator
  4. Select the old indicator on the FP (or go back to BD, double click...)
  5. Ctrl-V replaces the old with the new indicator but leaves it on connector
  6. Go back to the BD and rewire to the proper source/ remove broken wires

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...

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

 

Temporary File Path.png

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.

 

File Extensions

 

File Extension.png

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

 

Build Strip Path.png

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.

When the Grid is on it is difficult to see Boolean wired due to their 'dotted' appearance.

 

Change the Boolean wire from a dotted green line to a solid green line to improve visibility

 

LabVIEW wires.JPG

Ken

 

 

 

 

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.

 

UTF_Report_Export.png

A BD control/indicator/constant can be changed to either other type by contextual menu. For individual objects, Constant as well as Show/Hide are a choice; but for multiple selections, not -- why?

Screenshot from 2015-05-14 00:24:24.png  Screenshot from 2015-05-14 00:25:03.png

 

Note that this is not exactly a duplicate of Every GUI Programmer's Dream... (completed in Labview 2012), rather a part of the implied request which has been left out.

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:

 

How are the timing functions configured?

 

I propose a simple indicator or different icon to easily see the difference. Something like this, only maybe better looking:

Proposed solution

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.

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.

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.

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.

 

Improve Clear Errors Filter.png

Although I expect that it will take a while before this is implemented I would like to add the request so NI can start thinking about it.

 

As you might have noticed that Microsoft announced a few things on Microsoft build 2015.

 

Aside from the hololens and windows 10 for the raspberry pi they both share 1 common factor. They both run "Universal apps" (see http://www.engadget.com/2015/01/21/windows-10-makes-microsofts-dream-of-universal-apps-come-true ).

 

So it would be great if we can run LabVIEW programs as a "universal app" and run our code on all windows 10 devices..

I hope the picture speaks for itself.

/Y

 

BundleSuggestion.png

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.

 

Current procedure:

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.

-or-

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 😄

Ther are 10 pages of suggestions coming up when typing "probe location on wire".

AFAIK, none of them addresses this irritating behavior of probes:

 

Screen Shot 2015-04-24 at 18.07.18.png

 

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).

 Getting a value change event on a shared variables seems to me like something that ought to be expected "out of the box" in LabVIEW.  Polling shared variables for changes is taxing on resources, and such an architecture is generally frowned upon by NI and the LabVIEW community for things like front panel interactions and the like.  Why, then, should we expect to pay extra to deploy applications which such an architecture for interacting with shared variables?

 

I completely understand the extra license for the DSC run-time, as there are numerous other terrific tools included.  It just seems to me that the SV value change events are one thing that should be freely available for deployment to everyone already paying for the application builder.

 

Thanks!

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?

 

Best regards,

Sebastian

 

When wiring a VI, a cardinal sin is to put nontrivial wiring behind the VI icon. I see no use cases for this invisible wiring, and it directly causes many errors. In particular, accidentally wiring up the output of a bundle operation to the 'cluster in' box, so the bundle operation is completely ignored, yet the code looks perfectly OK.

 

This would be very easy to prevent. Help us not do things like that by letting us enforce the constraint:

 

When wiring or moving VIs or other structures, enforce the constraint: wires cannot cross the line separating two terminals.

 

By 'lines separating two terminals' I mean any of the interior lines on the wiring diagram that have at least one side being a valid terminal. For instance, I've marked in red the places wires should not go (using the terminal diagram, even though you never see the terminal diagram on VIs on the block diagram)

 

 

Capture2.PNGCapture3.PNG

 

If you do something that would cause such a wiring abomination:

 

Check to see if the wire simply crosses the border and then crosses back (a common case). If so, cut off the part that transgressed and connect the two  severed ends inside the terminal.

 

Otherwise, push the offending wire out the side of the VI. If this movement causes it to cross a boundary in some other VI, introduce a wire bend halfway between and solve the halves independently. If no solution can be found - VI's are on top of each other, say, complain bitterly (red X on wire).

 

Only enforce this constraint when editing (such that you're creating the problem), not when reading the code. That way, noncompliant code is not broken.