LabVIEW Idea Exchange

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

We can specify custom markers for axes, but even if we do so, there will be two additional markers that cannot be hidden: the Min and Max!

 

 

 

I would prefer an option to get rid of these two extra markers. Often they are distracting and not desirable for a clean look. For example we might want the x-axis to start at zero, but we want some padding to the left so data points (e.g. small circles) are not cut off by the other axis. Here we might want the x-axis min to be e.g. -0.02, but we still want the first maker to be at zero with no markers to the left of it.

 

If I specify custom markers, these are the ones I want, nothing else. 😉

Message Edited by altenbach on 06-10-2009 04:22 PM

This is something that would be a great addition for those of us working on different platforms (i.e. Windows and RT).

 

When a VI is compiled for a particular platform, add a seperate area to the actual VI file to keep the platform dependent compiled code. This way a vi that has been compiled for use on windows and for RT would have two sectons that keep a seperate copy of the actual machine code for each OS.

 

Where this issue becomes a problem is when you have common code called from a project that has both Windows and RT components. This creates an endless recompile operation as code is built

 

As an example:

 

Code is compiled for Windows.....windows machine code is generated and saved in the vi

Code is opened under RT.....changes pending because the compiled code does not match the platform

Recompile vi for RT....RT machine code is generated and saved in the vi.

 

When the code is reopened under Windows, it requires another recompile due to the existing RT machine code.

 

Obviously any changes to the FP or BD would cause all of the machine code areas to require a recompile. 

 

This would add more size to each individual VI, however disk space is relatively cheap with respect to LabVIEW development systems.

In the spirit of using as little memory as possible I think the default representation for Enums should be U8. Currently when you create a new Enum its representation is set to U16. Since I assume most people rarely have Enums with more than 256 items I would really appreciate it if the default representation were U8 so I don't have to always change it from U16 to U8.

In the option dialog it could be nice to be able to define the default connector pane. In our company we use 5x3x3x5 from the first day and I imagine other company as there own standard. It's realy annoing to have to change the connector pane all the time on new VI's and on the Class VI Template from 4x2x2x4 to 5x3x3x5.

 

DefaultConnectorPane.png

On my large monitor, the window size for the front panel and block diagram of a new, blank VI is much larger than those for most VIs that I would ever create.  So the first thing I do after creating a new VI is shrink down the FP and BD to something more manegeable.  Could we have an option for specifying the size of new VIs?

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.

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

Anyone that refactors code from another programmer has probably received some code that has too many sequence structures.  Often I convert these to a simple state machine.  With scripting this could be easily converted to a state machine for loop.  A default enum type def could be created to do a state machine sequence 1 -> 2 -> 3 -> 4 ->5 -> ...last sequence in structure.  All sequence locals could be replaced with either a local or a shift register (that will bypass all other cases where it is not used). 

 

Why would I want this?

 

Sequences are over used and it is well documented that state machine architecture can provide many benefits over the static and simple sequence.  Many programmers are un aware of these benefits and don't understand data flow so use sequences  to force execution order.  Sometimes sequences are convenient early in the prototyping only to find the known shortfalls of this programming paradigm.  When this happend dont worry, just right click on the sequence structure and click convert to state machine.  This could make refactoring code easier, at least in my mind (but is late on friday and I am ready for the weekend which could cloud my thought process).

 

 

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.

One ugly way i usually have to code is  

 

Example_VI_BD-1.png

 

A better way would be to be able to wire, a wire to every function.

This wire will carry data, but it will not pass them in the middle function. It will be a bump input-output, just to determine which function to be executed first. There should be an indicator, when this dump input-output is activated. It can be activated with right clicking on the icon.

Example_VI_BD.png

 This wire should be able to be, a dump wire without any data so you can impliment this

Example_VI_BD.png

The images way not be so nice, but that's the idea..

 

 

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)

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

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

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.

 

Change the VI Properties Dialog to be able to reach the desired option with a single click, Instead of using the drop down menu.

 

It will be more clear and fast to access properties. 

 

VI Properties.png

 

OK, this may be a bit of a way-out-there suggestion but here goes.....

 

There are times when I would really like to be able to create some kind of "overlay" for an entire FP.  I'd actually like for an overlay for the entire available screen, but let's not get TOO far ahead of ourselves.

 

Uses may include user direction (highlighting in RED) or some menu-like interaction or whatever....

 

I know this can be simulated using a picture control but then all user interaction goes to the picture display which must be on top for it to work....

 

Or how about something like the Wafeform graph with Back Middle and top pictures available.....

 

Shane.