LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
Instead of saving few versions of the same VI, it would be nice to have "Undo" even after saving the VI.

As I had mentioned/asked here, it will be very much useful to have the above feature in future LV versions. It ll be similar to the one already present in NI's Digital Waveform Editor tool. When we have to navigate/play with more digital signal lines, the graph gets too much cramped to view the digital signals.

 

I wonder why NI has NOT implemented/given this feature till now, for the developers? Smiley Surprised

Unlike the scales of numeric controls, graph scales don't support text labels (wouldn't that be cool! :smileywink: ) *(see footnote)

 

It could be handled very similar to the way text labels are handled for the scales of numeric controls, so most of the code is already there.

 

This would come in very handy for e.g. histograms or bar graphs, where each bar needs a text label, or for cases where we have arbitrary units.

 

Examples for integer scales: 

  • "January", "February", ...
  • "LabVIEW users", "CVI Users" ...
  • "Europe", "Asia", ...

 

Examples for floating point scales (x, or y):

  • "Too cold", "cold", "warm", "hot", "too hot"...
  • "small", "medium", "large", ...
  • "min", "max"...
  • "high frequrency", "low frequency"...

 

*My quote from this old discussion . See also Ben's example further down.

Today, when you run a VI, LabVIEW uses the hand cursor as the default cursor when you're not over a control. I believe this should be changed to be the arrow cursor, since much of the concept of the cursor relies on it being context sensitive, and the hand cursor hints that you have something you can click.

 

Change cursor.PNG

 

This can be done today by registering the mouse enter and mouse leave events for all controls and changing the cursor accordinglly and can even be moved into a subVI, but it's kind of pointless to do this for every VI and there are times when you don't want it.

It would be nice if NI added "Mouse Scroll" (and its counterpart filter event) to the supported events. Today, you can do this by using the mouse input VIs in a separate loop and polling, but that's not a very nice solution.

Support unicode officially for all FP indicators and controls! Captions and string indicators can be "coaxed" into showing Unicode characters (among other controls/indicators), but trees and listboxes (among most others) cannot show Unicode.

 

Of course, this may have a small audience, but anyone who has developed a UI meant to be distributed to half a dozen language-speakers has probably fought the same Unicode battles and figured out the display "hacks" that we have.

 

Unicode!.png

I currently have a 3D array that I need to remap to some strange looking discret calibration data by linear interpolation (there is no good model function, not even polynomial!)

 

(1) This requires deeply stacked FOR loops (image top).

 

(2) In many cases it would simplify code if we could use a single FOR loop, but specify to loop over all scalar elements in all dimensions. (SUGGESTION: right-click tunnel, select "index over all scalar elements" -> different tunnel look). This would cause the autoindexing output tunnels of scalars to produce a multidimensional array of the same size as the autoindexing input. In all respects it should act the same as if we would stack as many FOR loops as needed to strip the input down to a scalar array element (center image). The index terminal [i] would output an array of all current indices (3 elements in this case). I am not sure what to do about N. If it would accept an array, we need to make sure the size (=# of dimensions) is defined elsewhere if there are no autoindexing inputs for example).

 

Case (2) could be useful in many situations, especially for more complicated code than shown here. It would work for all situations where only the innermost loop contains real code.

 

(3) In this particular case, the "interpolate array" function could of course be made polymorphic to accept multidimensional arrays and produce outputs if the same size as shown at the bottom of the image. Case (3) is a more general suggestion. Many existing functions could be made "more polymorphic" to do the same operation on each element of an array such as shown here. Since all operations are independent, it could even be automatically parallelized internally to take advantage of multiple CPU cores. Good candidates are functions that have scalar inputs and output a single scalar. If I have time, I will go over the palettes and identify more candidates. It might even turn into a seperate idea here in this forum. 😉

 

 

Message Edited by altenbach on 06-05-2009 05:25 PM
Message Edited by altenbach on 06-05-2009 05:25 PM

Right-clicking on a case structure, we still have the option to convert a case structure to a stacked sequence.

 

I would prefer if this option would disappear without a trace forever :D. It has no purpose in life!

 

Nobody should ever use that option! It makes no sense!!! 😄

 

 

(I would probably retain the option to convert a stacked sequence to a case structure)

The argument is similar to what falkpl suggested here. The issue is refactoring old (pre event structure) code.

 

Many times I had the need to convert a multi-case case structure to an event structure where each event case duplicates one of the original cases. This is currently hard to do and involves a lot of copying and wire mending.

 

Of course the conversion cannot do any event assignments so things will be broken, but for me it would be sufficient to create the new event structure as a 1:1 "event-case":"plain-case" conversion of the code contents, without any events assigned. (This must be trivial in terms of code!) Assigning the events later is easy.

 

For symmetry, the reverse operation ("replace event structure with case structure") should also be available.

For no obvious reasons, the "array subset" and "string subset" nodes are currently not resizeable.

 

Many times, I need to get several subsets or substrings at once and resizeable nodes would be a welcome improvement. Thanks!

Message Edited by altenbach on 06-05-2009 03:53 PM
Message Edited by Support on 06-08-2009 09:07 AM
Add functionality/property to allow a cluster to have a scroll bar.  This way, long clusters with many elements can be shrunk down to a manageable front panel size and a scroll bar would navigate through the cluster elements.

LLBs always had the capability of marking a VI as toplevel.

 

I wonder if it would be possible to set a flag inside a VI so a VI is recognized as such from within e.g. windows explorer. (e.g. different default icon). Since this requires OS integrations, I don't know if this is even feasible.

 

Still, It should at least integrate with the LabVIEW project.

 

The default settings could be very simple:

  • A VI without any defined connectors in the connector pane is "toplevel".
  • If there is at least one defined connector, the toplevel designation is lost.
  • There should be a way to overwrite this in VI properties.

 

Many times, people attach a zip full of VIs without telling us the name of the toplevel VI, so this idea would limit the number of candidates to inspect.

I like using Linux whenever I can, particularly when running large software like LabVIEW, since it tends to crawl on my XP systems. I was happy to realize that LabVIEW works on Linux, but soon after I was disappointed by the lack of usefulness of it when interfacing with hardware. I need to use the RealTime module to interface with my RealTime Compact-RIO. I also need Linux support for the FPGA module, as I need to program the FPGA attached to my cRIO. I'm sure I am not the only person who would like the ability to do this.

 

Without support for any of the hardware or LabVIEW modules I need, the Linux version of LabVIEW is entirely useless to me, and XP as an OS simply cannot perform up to par for me.

I, like many others I am sure, have multiple LV versions installed on my computer.

 

I have often wished for a small launcher program (linked into Explorer.exe under Windows) which has a peek to see what version a VI (or ctl or whatever) is BEFORE calling the respective LV version.

 

It could also have an option to show a dialog whenever a VI is double clicked in a version different to a version of LV which is ALREADY open asking if it should be opened in the native version or in the currently opened version.

 

An alternative would be to treat VIs opened from a different version as locked (read-only), forcing either a manual setting of write permissions or saving under a different name.

 

Shane.

Tabbing will work for clusters on the front panel, currently we are using "Ctl+Down arrow key" to focus control in the cluster "Ctl+Up Arrow Key" to come out from the cluster

 

For use Tabbing feature for clusters, I need to use "Ctl+Down arrow key"/"Ctl+Up Arrow Key".

 

While tabbing on the front panel is there any way LabVIEW automatically detects the Clusters and it will directly focus the first element of the cluster and when you click Tab on last element in the cluster it will come out and focus the next availble control outside the Cluster (if next control is again Cluster it will focus the first element of the next cluster)

Title says it all. Have a slider or pull-down that increases or decreases the highlight execute rate.

Provide a way to compile an xcontrol, to have only 1 file to distribute.

Let’s take the Value Changed from OpenG, This polymorphic as 30+ VIs to support all data type and array size up to 2D. But basically it’s the same VI for all data type.

 PolymorphicVI.pngI think it could be a “.vip” and when you define the connector pane you select constraint of the possible data type that can be accepted.

The radio button control acts like a cluster container for booleans with some fancy logic behind it. Refactoring old code, we might have a bunch of customized booleans that we want to stick in a radiobutton control during refactoring.

 

For some unknown reason, we have to first drop at least one of the desired booleans into the control before we can delete the last one of the default controls that were already in there. I think we could get better work flow when doing these edits if we remove this random barrier that forces us to operate in a certain order. It would be nice if we could first empty out the radio button control and then drop all our desired customized controls in it. Of course a VI with an empty radio button control should probably be broken.

 

In summary, an empty radio button control should be allowed at edit time. We should be able to temporarily remove all existing content. Currently, LabVIEW won't let us remove the last remaining element if we try to do so.

 

(Hopefully, this is a trivial change and not something that would require lots of changes to the existing code) 😉

 

 

A few upgrades to  runtime menus would be nice.

 

1.  Allow for visibility on menu items.  Currently there is only the ability to disable or delete a menu option.  Disable is not often what is needed but deleting a menu item requires rebuilding the menu programatically.  Why not just have a show hide property on each menu item.

 

2.  Allow for a glyph/icon to be added to a menu item.  This is similar to list boxes.  The advantage here is that a psuedo-toolbar could easily be created using a menu.  Also modern menue systems are adding this feature so me should have it in our toolbox as well.

 

3.  Allow for detachable menus.  This could be a stretch to ask for since it is more difficult to implement.