LabVIEW Idea Exchange

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

Using the application builder is problematic if the destination folder is monitored by syncing tools such as Google Drive (Backup&Sync), Onedrive, etc.

 

During building, there are tons of file operations in rapid sequence, potentially crashing the sync tools or causing false file conflicts (recent example).

 

To avoid these issues, I wonder if the building steps could be forced to take place in the temporary folder, followed by a final clean move to the destination. My guess this would make building more stable and compatible with external folder syncing tools.

 

I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".  


I know there are others out there like me, I HATE upgrading Labview.  All the time required to update your custom configuration takes weeks.  Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.

 

Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software.  For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.

 

My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV.  Making the upgrade process easier with a single tool.


Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade.  If it was more seamless to upgrade, I'd probably upgrade every release!  

 

Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.

 

Perhaps NI should accumulate all of these requests to Upgrade and total them as one.  Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.

 

Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.

 

This idea is to improve the QuickDrop search window, to return functions that might be betters suited, based on the datatype of the selected function or wire.  Lets say I have a 1D array of numerics selected and I want to reverse it.  I will select the wire, then invoke QD and type "reverse".  But the first item in the list is actually "Reverse String".  With a context aware QD hopefully the search window will see I have an array of numerics, and prioritize the Reverse 1D Array function, and still include the reverse string but maybe push it farther down the list.  

 

This idea can be applied to the basic data types pretty easily (numerics, boolean, array, string, cluster).  But we could also use this on class wires that are selected.  A class library can have an associated mnu file, which is why some functions you can right click and the corresponding subpalette menu comes up.  So this idea could also prioritize functions that are found in the mnu associated with the class.

Strict typedefs and non-strict typedefs differ significantly.  There's too much of a gap for me.  Sometimes I'd love a control to be somewhere in between.

 

There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.

 

It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked.  That way we could shoose to long only boolean text, width or colour but leave the other properties free.  VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.

 

So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.

99% of the time when I use a Diagram Disable Structure, I am disabling code with an error cluster wired through. I don't want to lose the errors coming in, just the single operation, so I manually wire the error cluster through the empty case each time.

 

I've talked to others in the past about this and it would be nice for LabVIEW to be all-knowing and wire all datatypes through that match, but that would definitely lead to conflicts and mistakes. Error clusters, on the other hand, are simple are nearly always a single wire in and out.

Simply auto-wiring the error cluster input to the output would make the debugging process much easier.

 

Code with disabled operation:

Disable.PNG

Imagine the following:

 

When you hover (take your mouse) over the SubVI node in the callers diagram, the subVI code is brought up as an image in a small rectangle size. And that disappears when the mouse is taken away from the subVI node.

 

Demonstration (snapshot):

 

When mouse is hovered over 'SubVI Two.vi',

 

Caller Code.png

 

How does it help ?

 

1. Understanding a prototype code, where there is less emphasis on creating VI Icon and naming SubVI properly, quick glances of the subVI code can speed up the understanding/edit time.

2. Even otherwise, shipping code, could be sometime hard to understand and require often switches to subVIs block diagram.

3. Huge subVIs code, definitely, the image may not make much sense (as it is contained in a small rectangle), but could be useful to get some basic idea or to clear ambiguities between subVIs expected behavior.

4. This feature must be an opt-in. Not every time, this behavior would be desirable, hence this must be Tools->Options opt-in.

5. Does not open up the block diagram, which means that you have lesser VIs to deal with it in taskbar.

6. Drawback: This could hurt the edit time performance a little but, as LV would have to do some extra work to bring up the image..

Pretty simple idea.  When you are creating installers, you are allowed to install files in many different locations.  Including lots of system locations.

 

But for some reason, Public Documents is not one of these destinations.  It should be.

 

Because its not in the list, I need to go through some annoying workarounds which I don't totally trust.

 

 Untitled.png

I've encountered a programming situation where I may need to call 'Match Regular Expression' where the regex is selected at runtime, and where that regex may potentially have a variable number of submatches to return.  Unfortunately, right now, the submatch count is a compile-time decision based on how far out I grow the node.  I can grow the node to some maximum number of submatches ever expected, and thankfully the node doesn't throw a runtime error if there are fewer, or greater, submatch expressions in the regex.  I'm building the individual returns into a string array for further processing, but it would be much more versatile if the node could return the submatches with a properly-sized string array.

Hi,

I want to start discussion about how to enhance Loop Conditional Terminals in LabVIEW. Generally my idea is to have an easy way how to monitor Conditional Terminal of user-defined "primary" loop. Under the hood there can be for instance notification triggered from the "primary" loop and one or more "slave" loop(s) equipped with "Wait for notification" (with timeout = 0) with predefined logical operation on the terminal input.
So this allows you to have one STOP source loop and one or more listeners.

 

sopping loops.png


Anyone wants to expand this idea?

Currently, you are unable to highlight and copy text from the context help.  It would be nice to allow this functionality for LabVIEW users to be able to copy certain terms from the context help.

Hi,

 

wouldn't it be nice to set the access scope for multiple VIs in the project tree? Currently you have the possibility for using virtual folders. When I right-click on multiple VIs i can analyze them, run unit test, etc. Currently we're building the hierarchy of virtual folders according to functionality and not by access scope.

 

I searched the ideas but didn't found such an idea. If so, please don't shoot me for a double post.

 

Right Click on Multiple VIs

When you run the LabVIEW Platform DVD, the default setting is that LabVIEW gets installed and nothing else. You can then go pick and choose what modules and toolkits to install. I like this default because I usually only want to install LabVIEW and a few other modules and toolkits. It is faster for me to select the few modules that I want to install rather than unchecking all of the modules I don't want to install.

 

When you run the Device Drivers DVD, it tries to guess what drivers you want installed based on the software you already have installed. However, it usually wants to install more drivers than I want it to install. It is a hassle to go through the driver list and unclick the drivers I don't want to install because most of them have dependencies that you have to unclick first. 

 

Idea: Their should be a button on the Device Drivers installation screen to unselect all of the drivers (see image below). I don't think the Device Drivers DVD default should be the same as the Platform DVD; a lot of new users won't know what drivers they need and installing all of the recommended drivers is a safe bet. However, many users do know what drivers they want and it saves time and hard drive space to only install the necessary drivers. Adding an "uncheck all" button would make this process faster and less frustrating.

 

device drivers.png

Add an "Uncheck All" button!

It would be far more useful if, instead of returning the string VI Name of each item on the call chain, it returned a VI Reference to each item on the call chain.

 

You can obtain the VI Name from the VI Reference; but not the reverse. The VI Reference indicates which instance of the SubVI on the block diagram of it's caller was the one in the call chain.

 

If a SubVI appears in multiple places on the block diagram, the call chain as currently implemented doesn't give you enough informatiion to figure out which instance actually was the caller...

 

 

Rounding operations (round to nearest, round towards -inf, round towards +inf, round towards zero) always result in a whole number, so it would only be natural that the resulting output could be configured to be an integer data type, because that is often what we actually need down the wire. (See also here).

 

I suggest to add an output configuration page to the properties of these functions. Thanks!

 

(There are similar holes elsewhere, but these are different ideas (idea 1, idea 2, ...) :D)

I would like to have an XY Chart that has the same functionality as the Waveform Chart, but with x and y inputs instead of just the y.  The XY Graph is not efficient to be used inside of a loop, mainly because it redraws the plots each iteration, and I've had a hard time trying to make a buffer that is as efficient as the waveform chart.  The Waveform Chart does not allow you to define the x-axis as anything that is not an interval.  For example, I might want to plot pressure vs. flow rate.  Many customers also request the ability to change the sampling rate during an experiment.  this would be much easier to handle with an XY Chart.

It would also be nice to have the buffer size included in a property node.

It would also be nice to have the ability to change the size of the graph palette.

It would also be nice to have the nearest plot coordinates (x and y values), or interpolated values, to mouse movements over the plot area as a "visible item" in the shortcut menu (this should show a dot over the plot's trace)...  I've done this with an X Control, but I'd like the ability built into the new XY Chart on a lower level to improve effiecency.

 

A .NET assembly can mark some of its items as deprecated to alert users of those items to not use them for future applications. This is part of the .NET standard. It looks like this:

[Obsolete("This is the message you get!")]

 

In other development environments the developer will see this message when using a deprecated item.

 

This is an example of what it looks like in the Visual Studio editor. The item is underlined and when you hover over, the message is shown:

vseditor.png

 

This is an example from Visual Studio builds:

vs builds.png

 

However LabVIEW does not. If you're developing a LabVIEW application using .NET interfaces... You might use deprecated functionality by accident. To avoid this... LabVIEW users like myself generally have to have intimate knowledge of the assembly or the documentation up on another screen just to make sure they are not using deprecated items.

 

I propose we mark items in a special color to indicate they are deprecated. I chose pink here for no reason. Any color is fine:

lv nodes.png

 

Also, we should indicate the item is deprecated in the class browser in some manner. Again, I just drew some stuff, doesn't have to be exactly this:

lv browse.png

 

When you create a constant on the diagram from an object with a name, often the new constant's label runs into the enveloping structure's border, causing the structure to resize.  This process is quite dumb, as even if there is lots of room around the constant, LabVIEW insists on forcing a resize due to the collision.  Since the space is there, surely the routine could recognize that and only force a resize if there is not enough space.

in the example, the control was against the LHS of the loop; after creating the constant, I moved it down for vertical clearance, then made the label visible.  The label forced the loop resize to the left, ignoring the space to the right.

 

structure resize image.png

Quite often, I want to indicate a problem status on a front panel. It would be nice to have a red LED indicator available on the controls palette rather than having to modify the existing green ones (round and square)

Whenever I install a new version of LabVIEW, I have to wade through the LabVIEW options to change all of the UI settings to what I like. To make the upgrade process easier, I would like to see a dialog that:

 

  • appears on the first launch of the new LabVIEW version
  • can be easily skipped by users who would rather configure things manually
  • allows users to choose common settings (aimed at users without another version of LabVIEW on the machine)

    1.png

  • provides a user friendly way to import settings from an older LabVIEW version (aimed at users who are upgrading LabVIEW)

    2.png

This would make the process of upgrading much easier, especially for users who have very particular preferences. Some options that could be addressed in the wizard are:

 

  • control style (icon or not)
  • visible palletes
  • showing text for VIs on pallete
  • broken wire Xs
  • etc...

 

I would like the VI icon to be the icon which shows up in the file browser instead of the default LabVIEW VI or control icon.  There should probably be a switch to turn this on and off, since I can see the utility of having a specific icon for VIs, controls, etc., but in normal use, the VI icon would work much better.

 

ExempleWindowsExplorer.png