LabVIEW Idea Exchange

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

String controls, such as the Text control of the Configure Build Text VI, should ignore keyboard shortcuts which they don't support instead of interpreting these as the alphabet character key pressed.

 

For example, currently CTRL+A isn't supported to select all. Instead the character 'a' is added to the string at the current position.

 

It would be better if combinations of key presses that are not supported are disregarded. For example, I have a habit of hitting CTRL+S to save whatever it is I'm working on frequently. If I inadvertently do this within a string control on a dialog then I will find I've just added 's' to the string.

This is in addition to New LabVIEW Installation Retains Options

 

During LabVIEW installation if it detects a previous version of LabVIEW has been installed it should present the user with the option (or have a flag when running the installation to allow this to be done silently) to import all VIs which are not installed by default that are present in the following folders:

  • vi.lib (VI Package Manager installs packages to this location by default)
  • instr.lib
  • user.lib

Upon importing the VIs to the new LabVIEW installation it should also mass compile them to the new LabVIEW version so the user is not faced with having to save loads of VI dependencies each time the user opens a VI which uses them.

 

This would make the getting started with the new version of LabVIEW a lot more seamless when just upgrading from a previous version.

I find myself constantly switching between Quick Drop and palette surfing for the functions I need. Sometimes I close the palettes just because they are in the way of where I want to drop a function. But I immediately need to reopen them to find my next function.

 

Can there be a setting in the palette options to hide or minimize the palete once I've selected a function from the control/function palette and once I've placed the item on my front panel/block diagram it will reopen to the same palette and spot?

if a control definition is missing we can replace the new control by coping the new control to clip board and pasting on top of the control. This preserves the wiring of the control on the connecter pane.

 

Similarly we can have the option to replace the missing VIs (?) by coping the new VIs in the clipboard and pasting it or

add an option on in the replace menu like replace from clipboard, and it will preserves the connections.  

When you change a global's variable name, all instances are not been updated, causing a broken arrow.

It must be done manually and it costs a lot of time.

There is an option "Find ALL instances" so i guess it is very easy to update all names automatically

For example, if I had a case structure with 50 cases and one variable in each case, I would like to be able to copy the case structure and have a new identical case structure with 50 matching local variables.  Currently it makes 50 new variables, so having the option to choose between generating new ones and generating locals of the existing would be extremely useful.  

Idea

The idea is to implement an option to choose for which RunTime-Version you want to compile your executable.

With this you could always use the newest LabVIEW development version but do not need to update all systems with a RunTime-Version.

NI-RunTime-Version.png

 

Background

When changing from LabVIEW 2019 to LabVIEW 2020, you need to update every RunTime-System also to version 2020.

This is difficult, if you have many worldwide runtime systems with different projects, where you can not easily update a RunTime-Version because of technical restrictions in production or access to the system.

 

This results in parallel use of different LabVIEW development versions for all of your projects.

Means a mess because once open a project in the wrong/newer LV-Version you have to store all changes "for older LV-Version" to continue work in right version.

Or, to avoid this, not upgrading to a newer LabVIEW development version and still working for example with LV16 in all projects.

 

Conclusion

Best way would be if you can update all projects to LV20 development system, but still be able to directly built executables for older runtimes.

An RT program can be ran either from a host PC (what I call the "interpreter mode"), or as an exe in the startup directory on the RT controller. When running from the host PC (for debugging purposes), it allows front panel "property nodes" to execute properly as you would expect. After building, and transferring to the RT app to the startup directory on the RT controller, the program errors out on the first occurance of a front panel property node. The reason is obvious; a front panel is non-existent in an RT application, hence the front panel property nodes are rejected. Of note, no errors or warnings are generated during the RT app build operation.

 

Recommend that the build application simply ignore the front panel property nodes as it ignores the front panel in general. This would allow the programmer to retain the same version of the source code for either mode of operation.

 

Thanks,

Bob

I have several LabVIEW applications that I work on, and each of them has a Perforce workspace associated. Every time I switch to a project that is in a new workspace, I have to dig through the SCC configuration menu to switch workspaces, which takes a while.

 

It would be really sweet if LabVIEW recognized that a project file was in source control, and associated the workspace with the project file. (Especially because I could have two application projects open, each in its own workspace.)

When you drop a numeric constant on the BD, you get an I32. When you drop a Numeric Control on the FP, you get a DBL. I suggest consistency between the two, or even better, have an environment setting that allows a user-defined default data representation.

 

NumericConstantControlInconsistency.png

Removing the selected Ctrl-Key Shortcuts by pressing one button would be much easier and comfortable then the current solution.

 

QDSK_Suggestion.png

 

Right now, you have to delete the appropriate VIs from the directory National Instruments\LabVIEW xxx\resource\dialog\QuickDrop\plugins. Additionally, you have to delete the shortcut entry in the LabVIEW ini file within the key name QuickDropKeyboardShortcutMappings. Otherwise the shortcut is blocked for further use (see picture below).

 

QDSK_Current.png

 

With the Remove button you have the possibility to delete everything (Shortcut and all corresponding VIs) or just the Shortcut without the VIs remaining in the LabVIEW directory (Therefore, the Shortcut has to be deleted from the VI description).

Using inline subVIs allowed a very time critical waveform generating VI to be much more readable with subVIs yet without unacceptable performance loss Smiley Happy.  It's a shame NI has not figured out a way to still allow a probe to be used in an opened inlined subVI during execution of the calling VI.  To me it seems there must be some way to do this, since an inlined subVI just becomes essentially a portion of the calling VI code during execution.   

Hello,

 

LabVIEW known which object is beneath the mouse even if it is not selected!

I want to know it also. For example, you could create a constant to this Terminal of Property Node via shortcut.

 

Measures of Mean.vi only takes double precision float as input. When I use single precision to save space, and where A/D resolution is the limiting factor anyhow, it is pretty annoying to have to promote a whole array of data to double just to get the median (or another of the functions in Measures of Mean). Can't this thing be recompiled to be able to do both double and single?

The listbox control is great for those cases where the user wants to see all of the choices available.  But the combo box has advantages, too.  The value is a string.  If the programmer initializes the combo box using the "Strings and Values" property, the value of the selected item can be just about anything. I'd like to have the datatype and functionality of a Combo Box with the GUI of a listbox.

This would allow you to drop complex bits of code right on the block diagram just like you would a sub-vi.

I'd like to be able to switch the project explorer view to show actual VI/CTL icons instead of generic icons, very much like the function palette displays available methods.

The icon view should be possible to set for all items and/or only a subset of the project tree.

 

This would be very nice, since LabVIEW allows us to draw pictures that represents the code hidden in a VI, and a picture tells more than a thousand words...

 

/Jonas

Message Edited by Mellroth on 08-12-2009 12:59 PM

If a user has installed more than one LabView (2009, 2010 and 2011) the last used folder

is in all version the same. E.g. if i open a VI in 2009 and close labview afterwards, the

same starting folder is used in another Labview version like 2010 or 2011.

 

This is caused by the MRU List from windows, not from LabView itself. To prevent this

it would be nice to rename the EXE and INI files like:

 

labview_2009.exe

labview_2009.ini

 

labview_2010.exe

labview_2010.ini

 

labview_2011.exe

labview_2011.ini

 

labview_2012.exe

labview_2012.ini

 

Now the MRU from windows distinguish between different EXE Names and each LabView version has it own last used folder.

 

(see also: Forum - Last Used Folder (MRU)

 

 

Programming cRIO, sbRIO or myRIO is tricky for new users because of the 3 targets that you can develop VIs for: My Computer, Real-Time processor and FPGA.

 

Of course, it’s not hard to find out which target the current VI will execute on, by looking at the text below, or at the Project Explorer.

 

Current 1.JPG

 

Current 2.JPG

 

However, I think it will be useful to emphasize the target. I am not sure what the best implementation for this is - maybe you find a better one.

 

My suggestion would be more noticeable text, such as below:

 

My Computer - better.JPG

 

Real-Time - better.JPG

FPGA - better.JPG

For the most part coersions can be broken down into two classes: lossy (e.g. 64L to I8) and safe (e.g. U8 to U16). Why is there only one color option for coersion dots?  Could the vi analizer have seperate settings for max allowable safe and unsafe  coersions?