LabVIEW Idea Exchange

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

Hello, 

 

Lately I used Visual Studio Code to edit Mark down files and other text files. One feature that I use is the GIT integration to VS Code. For text files the diff is integrated to VS Code and it's very useful to take decision on which files to commit or not.

 

It could be nice to have the same type of plugin into VS Code to diff LabVIEW VIs. 

 

Thank you

 

Dany

The default formating for numerics is automatic with 6 significant digits and hide trailing zeros. I'm sure someone thinks this is a great format, however I would like the option to specify default numeric formatting through the ini file. It would be great if this could be applied to the default font for the numeric also.

For LabVIEW users,

How many of them need "Delete Option" on Right Click Context Menu?

Delete option in Context Menu.png

I feel providing an delete option in right clicking context menu for any Indicator or Control deleting will make developers easy and fast assessable and avoid too-much use of keyboard.

We use our left hand for control and Shift more offen but for pressing delete button which is at right top corner in keyboard, all of a sudden we will remove our right hand from mouse and press Del which is uncomfortable.

 

So, Developers share your point of view for the same and request to add Delete Option in upcoming version.

Later we will ask even Cut Copy Past...:smileyhappy: He! He! He!

This is a simple suggestion regarding returning all variant attributes from a variant in the correct data type if the name is left unwired but the default value is wired.

 

As you probably know, if you leave the name and value terminals unwired the "get variant attribute function" will return an array of names and variants for all of the variant attributes. If you wire the name or the default value then the node will adapt and return only a single value with the 'found?' output.

 

Here is a diagram to show you what I'm talking about:

2015-02-18_11-55-39.png

 

Currently, if you leave the name unwired but wire the default value this results in a broken block diagram.

 

The reasons for this suggestion are as follows:

  • Cleaner block diagrams - if you know all of the variant attributes are the same data type then you save the extra constant/variant to data node
  • Possible performance improvements - maybe NI does (or can do) something to improve the performance/memory allocations if the data type is known and can be done within the SubVI
  • I can't see a case where it would break compatibility other than perhaps a broken block diagram would no longer be broken if the default value was wired but not the name but the runtime functionality would remain the same
  • As variant attributes are a very efficient and recommended way of doing key/value lookup tables I think this minor change will tidy things up nicely and if there are performance gains to be had under the hood by doing this then all the more reason to do it!

Thanks for reading and hope you'll +1 my idea!

 

 

Many versions ago, we got the "static VI reference", and it made our life easier. I am suggestion a similar "static control reference" that can be tied to e.g. a strict type definition *.ctl file so we can read certain properties.

 

I have several type definitions that are exclusively used as diagram constants. Since there is no control in sight, I cannot use a direct property node. It would be a shame to have to place a hidden instance on the front panel just to get to the properties.

 

Well, we can use a static VI reference to point to the *.ctl file and start peeling until I get to the actual control (top image). However, it would be nicer if the static control reference would directly give us access to the properties of the control, such as the strings of a strictly typed enum in my case here.

 

With my suggestion implemented, the same code could be done as shown (bottom image)

 

The current way to get a static reference to a *.ctl file via a static VI reference (as described above) should be retained, because sometimes we need access to other properties.

 

I am suggesting a new dedicated "static control reference" that would give direct access to the properties of the actual control in the *.ctl file.

 

(of course some properties (e.g. value) would not make a lot of sense if used this way. Maybe there is a much eaier way, but I haven't found it).

 

 

There have been plenty of times where I'll be doing something inside a LabVIEW editor dialog (like the Properties dialog for a control), but want to quickly look at another block diagram or probe window.  I can't, however, because the dialog I'm in is modal, meaning that it won't allow window focus to go anywhere else.  So then I have to close the window, go find whatever it was I was looking for, and then re-open the window.  Not a huge deal, but it bugs me everytime I do it.

 

Usually, this happens to me when I'm in a Properties dialog and need to look at a probe from the Probe Watch Window.  I'd like to be able to switch to the probe I need without having to close the Properties dialog. 

 

Therefore, I would like dialog windows (including the Icon Editor, which is also modal for some strange reason) to be non-modal.  So that we don't forget about them, the windows could still be top-level so that they are always above all of our other windows.

The updated to IEEE 754 adds a half-float and a platform independent quad float. We have a project where a data source will be giving us values in half floats (16-bit). It would also be nice to support quad floats (128-bit) since the current EXT datatype is platform dependent.

I am sure many do this:

tab with enum.png

  • Use an enum and hide the tabs
  • Programmatically change page when enum changes

This works great, but during development the page obviously does not change when changing the enum. Either you right-click the border of the tab control and "Go To Page" or you display the Page Labels Display (and programmatically hide it) or something along these lines.

 

But why not make the tab control's Page Labels Display an enum in the first place? Being able to customize it would be great, but just making it an enum would be really helpful.

 

So basically:

page labels display.png

  • We get the look we want
  • We avoid having the extra event to change page during runtime
  • Page also changes during development
  • Everyone is happy

 

 

 

This one has irritated me for a long time.  When I create installers, I like to utilize the welcome dialog so the user knows exactly what they are installing.

 

But the application builder limits this to 7 lines of text.  Look all the unused space!

 

Welcome dialog for installer.JPG

 

My suggestion:  Make use of the unused space and let us specify more than 7 lines of text.

TestStand provides the extremely useful Label step type.

 

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It would be extremely useful if the LabVIEW Project Explorer provided a similar Note project item. The Note would serve as a documentation and annotation tool inside the project. Project notes would serve to explain the purpose of a group of lvlibs or lvclasses, or to provide short descriptions inside an lvlib, lvclass, or virtual folder.

 

As a workaround I currently use virtual folders to add notes to the project. By convention I name these virtual folders starting with "_Note:". The underscore helps the Note appear first (near the top) when the items are arranged by Name or by Type. By convention I never add any item inside the _Note virtual folders.

 

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The implementation of a Note item could be quite simple. A Note item would essentially be just like a virtual folder with the following modifications:

  • Different icon. An icon that resembles a document would make sense.
  • The Note item would not be able to contain any other items.

Currently the only way to set/modify Tcp socket options is by directly calling some system library, as done for example in this post.

 

This not only causes code difficult to understand ("what does that library call do again?") but also poses problems when you want to use your code on different operating systems: Currently the only way to do this is using "conditional disable structures", and then Labview still tries to load the code used for a different operating system...

 

Labview should have a standard way to set socket options within Labview code, at least for the most important options (Nagle algorithm leaps to mind...). This could either be done as additional inputs to the "Tcp open connection"-VI, or (much better) using property nodes for Tcp connections.

 

It's a common convention that the space bar is used to pause/un-pause videos that are playing. It would make sense to me that pressing the space key would toggle the pause button (Pause / Continue).

 

1) Pressing Space Bar key would be the same as pressing "Pause" on the VI toolbar.

 

2018-03-15_10-07-07.png

 

2) Pressing Space Bar key again would "Continue" (un-pause).

 

2018-03-15_10-08-31.png

It would be nice to have the F2-function in LabVIEW (mark element and press F2 to edit text).

So you don't have to step through the Tools-Palette.

 

I'd like to see this rolled into LabVIEW core: http://lavag.org/topic/13748-discuss-variant-probe/

I have an application with multiple Waveform Charts, each with a visible Plot Legend, Scale Legend, and Graph Palette.  I'd like to give each Chart a distinct color (a sea of gray is boring).  There is a Frame Color property that does the Frame, and I figured out how to color "underneath" the X Scale numbers, but I can't programmatically color the Plot Legend, Scale Legend, or Graph Palette.  To do so, I have to break out the Tools Palette and wield the Paint Brush (boring and tedious, especially when compared to wiring a single Color Box to a set of Properties).  Can we get the "missing Color properties" made available?

 

The Figure shows the original Grey Chart, the result after wiring Yellow into the Frame Color property (note that there's still a lot of Grey, including underneath the X Scale values -- this is fixable), and the third shows what I'd like to be able to accomplish with additional Property nodes made available.  It is frustrating to able to color Frame, but not the "Extras".

 

Plot Coloring Idea.png

Bob Schor

Right now, this doesn't work:

 

1-26-2011 2-45-25 PM.png

 

I have to add a Convert Units function to make it work:

 

1-26-2011 2-51-21 PM.png

 

It would be cool if the Wait (ms) function were polymorphic, accepting floating point inputs with "units" of time, and performed the unit conversion behind the scenes (and without any coercion dot).

 

Of course, this might require renaming the function to simply "Wait" (w/o "(ms)" qualifier).

The new Wire Labels in LabVIEW 2010 are fantastic. However, there is one "feature" of the new wire labels which may be irksome in certain circumstances. When you create a SubVI from a selection (Edit > Create SubVI), the terminals in the new SubVI will take on the names of the wire labels, and not the names of the terminals on the root diagram from which the SubVI was named. Here's the scenario, and the option I'd like to see...

 

 

wlsv1.jpg

 

 

 

 

wlsv2.jpg

 

 

 

 

wlsv3.jpg

 

 

This option would give us a choice... Smiley Happy

 

 

wlsv4.jpg

There are examples of generic ASCII spreadsheet formats that used fixed-width fields and no delimiter. (see for example the XMAP section of XPLOR files for crystallographic electron density, blue part below).

 

 


ZYX
XMAP: section #   0 average density=-0.336     sigma= 0.907   
       0
-0.97086E+00-0.49927E+00-0.82774E+00-0.13491E+01-0.57034E+00-0.71253E-01
-0.19491E+00 0.61017E+00 0.10064E+01-0.22888E+01-0.94020E+00 0.77451E+00
 0.57539E+00-0.31211E-01-0.27430E+00-0.36526E+00 0.34772E+00 0.81884E+00

-0.19954E+01-0.10117E+01 0.18038E+01 0.19008E+01 0.11886E+00-0.41646E+00
 0.47560E-01 0.48855E+00 0.57606E+00-0.22320E+00-0.12787E+01 0.47590E+00

...


 

LabVIEW could easily deal  with these sections (i.e. read and write!) using "%12.5e" as format string and an empty string as delimiter. For some reason, an empty string as delimiter does not work for "spreadsheet string to array" and "array to spreadsheet string". If I explicitly wire an empty string to the delimiter input, LabVIEW will silently substutite a tab instead. This is somewhat unexpected, a tab should only be substituted if the input is unwired.

 

IDEA: An explicit emtpy delimiter string input should be accepted verbatim. 

 

Of course things can go horribly wrong if the field code is variable width, but we need to trust the programmer to be aware and deal with it.

 

(On a related note, there is still no format code to allow padding the exponent to two digits with zeroes as in the blue parts shown above, however, fortunately the files seem compatible even if I don't edit the exponent to match that pattern)

Message Edited by altenbach on 07-21-2009 12:02 PM

 

 

                                                            Find and Replace

 

                                Type in the world(s) to search for   >>  recent words

 

 

 

toto.png