LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
Provide Merge and Diff Tool for Projects(.lvproj) and libraries (.lvlib,.lvclass,.xctl) to be able to identify all missing file from other revision and merge or Diff Build specification.

How did a program made for engineers and scientists make it 20+ years and not allow for subscripts and superscripts to be displayed. 

E=MC2 is really not all that powerful.

Are there no chemistry math or physics applications developed.

 

One nice method for implementing this is to add an additional mode to string display called markup bhere simple tags could be added around characters to alter their appearance much like is done in HTML.

  

For as long as I can remember (I have used LabView since 4.0) the decorations and contropls pallette have remained unchanges for the most part.  End users want an application more like the iPhone than windows98.  We need a new decorations capability to be able to customize controls  to a high level.  The square circle and triangle of 2 colors and flat or 3d/rounded nolonger cuts it.  I would like to see a new type of decoration.

 

- Decoration made of vector graphics so it is scalable, user can add or remove verticies and move them around to make new shapes.

- Labview native color pallet linked to item colors (default can be 2 color option of FG, BG but scale this to an array of colors to make more complex decorations)

- Colors add transparancy and alpha channel

- Grouping allows building of a single new decoration from several  primitive shapes.

- Decoration possible support gradients (color blending)

*** Decorations should have optional labels so that they can be addressed programatically

-Decorations added to customized controls that have lables associated with them become part of the control and can be accessed via a property (ie can be set to not visible through a property node)

 

I know this is asking quite alot, but I have found that when I make my applications not look like LabView (and it is easy to spot a LabView application) it is not a well recieved as when I present a highly customized application that does not look like a labview example.  Allowing the community to easily create very professional looking new controls and indicators will do wonders for our GUIs.

 

 

I cannot tell you how much time I spend changing the appearance, properties, connector pane, etc, etc. every time I "create a SubVI".  I try to always use the same connector pattern, error in and error out, error case structure on BD, and even a common icon appearance within a project.  It would save hours over the course of a project if I could set up a template that would be used BY DEFAULT for "create SubVI".  Also, allow me to set that template as the default for "New VI".  Save me the step of File - New - From Template - choose it.  If I go File - New VI, I want to see my default template.  Anyone who has used AutoCAD (2D) in the past will be familiar with this.  One could create a blank drawing and save it as 'acad.dwg' in the AutoCAD program directory and AutoCAD used this as the default drawing template.

In View VI Hierarchy we can right click and ‘Find all Instances’ to get a dialog box similar to the Error dialog box.  From there we can right click different instances of the VI to be taken to them on the BD.  Why then does Project Explorer only allow us to Find – Callers or SubVIs?  Add Find – All Instances to that menu as well.

 

SearchResults.png

Message Edited by Support on 06-03-2009 04:35 PM

Get a quick and more clear view of the event handled by an event case

 

Intead of this:

EventCaseViewProblem.png

 

Get this by a click on the event case number:

EventCaseViewMoreClear.png

 

 

Download All

The LabVIEW forum has shown the constant need of a colorbox indicator that looks like an LED (round or square). Of course we can make our own, but maybe it would be easier if these would ship with LabVIEW.

 

 

Here are some example links. It comes up all the time! 😄

4 Color LED

Dimmer

labtris

Tunnels for FOR loops are autoindexing by default. Sometimes this is not the correct option for very obvious reasons and we get a broken wire.

 

The diagram editor should be smart enough to try the "other" option (e.g. no autoidexing) if a broken wire results. If the other option succeeds without a broken wire, it should be used automatically. Maybe the tunnel could "glow" for a few seconds with a small option box (similar to e.g. when pasting into word: keep formatting, text only, etc) that would disappear after a while where we can click and overwrite the automatic handling.

 

The image shows two wires that would be a candidates for autocorrection of the indexing option. In both cases, LabVIEW should disable indexing automatically to avoid broken wires.

 

If both options result in a broken wire, nothing should happen, as before.

 

(Similarly for while loops. e.g. if I wire a scalar across the boundary to an array indicator, it should autoindex.)

 

Add italic and underline to the supported text formats (only bold at this time) for the VI description (--> context help of VI).

 

Integrate the VI description in the long awaited icon editor (see this post), so we can edit the icon and the description in one step. Doing so, spare us to type characters like "<B>" and "</B>" by providing formatting buttons !

So many times, Darren's history probes have been a great help while debugging my code ! This concept may be enhanced. But at least, these probes should ship with the LabVIEW installer.

In VI properties you have the option to set the run-time position of the VI. Why not put hidden as a run-time position (or maybe call it state and position from now on)?

 

If you do not want your VI to have - or at least start with - a GUI you do not have the option to set the top VI to run with its window hidden from the start. Instead the closest solution you have today is to set the run-time position to minimized and then run an invoke node that sets the window to be hidden.  Two of the most recents cases where I would have liked this is in a launcher app that just takes care of file associations (runs the main app and transfers the list of opened files to it...), and in a client app where some users want to disable the splash screen - which means that the splash screen should not be the top-VI but rather be called by a top-level VI that starts with its window hidden...

Application Builder properties dialog >> Source File Settings >> Customize VI Properties...

 

It would save me a lot of time if it were possible to select/deselect all properties at a time.

 

VI Properties.jpg

To reduce the amount of time to have shift to Front Panel when in need of changing a array control/indicators dimension. I suggest that to add two right rows in the right click menu is added; "Add dimension" and "Remove dimension" on these terminals on the diagram.

 

Writing this I realize that these two new menu options could be available on single element indicators too for easier transforming single element into arrays.

Right clicking a FOR/While loop index would allow the user to select the array dimension.  This could then be displayed on the VI as shown. 

 

indexing - old.jpg

indexing - new2.jpg

 

 

I recently did some work that required a lot of simple equations. The formula node works fine, but the diagram would have been easier to read if I could have entered equations like this:

 

 Equation Node.PNG

 

Equation Node : Mathcad ::  Mathscript Node : MATLAB

As mentioned here, "Event Sources can be time consuming in finding when you have lots of FP objects."  I'd like a FP node Right Click menu option on terminal (or on the node itself) to Find Event Case if it is applicable. (Event Structure must exist)".

Writing to a signaling property of a control fires an associated value change event, even if the actual value does not change.

 

That's a good feature!

 

I often have a situation where I want to fire an event without actually changing the value (Yes, I have good reasons!), so I end up reading a local and wiring to a signaling property of same. This seem silly!

 

I would prefer if we were allowed to leave the signaling property unwired, in which case it would fire associated events using the existing value of the object. Of course this should now work equally well for value change events of latched booleans where actual writing to locals and value properties are not allowed.

 

Leaving it unwired will simply fire the event, but not touch the value.

 

If this seems too convoluted, how about making a new method or property that does not have an input and is e.g. labeled "fire value change event".

Sometimes I know I want an initiaized shift register, but I am not sure about the data type, because it might change during program development. Sometimes I have a cluster holding a few variables, but later I need to add a few more elements.

 

If I initialize the shift register with a diagram constant, things break whenever I change the cluster inside the loop and I need to redo the diagram constant by "delete the constant, right-click the SR,  create constant".

 

I would prefer a mode where the initialization is generic and simply adapts to whatever type is wired from the inside. This simply ensures that no data is retained between calls, just between iterations of the loop as often needed.

 

In summary, we should have an option to generically initialize a SR (or feedback node) and it would look different to indicate that fact. For example it could have a small cap as in the attached image.

 

I think there should be some way to select data out of an array on the front panel.

Whe I mean by this, is that you can not click and highlight N x M number of cells, then copy and paste (into notepad, excel, etc).

It doesnt even work if you right click the array, then press 'data operations >> copy data', unless you stay in LabVIEW.

Like it or loathe it, Microsoft Excel is heavily used for storing, recording and analysing lots of data and many LabVIEW programmers must find they need to get data into or out of Excel. However LabVIEW lacks the ability to read and write Excel files directly. It is possible to exchange data with Excel via ActiveX automation, but this:

 

  • requires Excel to be installed on the same computer as the LabVIEW application
  • is not cross platform
  • is complicated to do
  • does not appear to work reliably across different versions of Excel

 

The Report Generation Toolkit allows creation of Excel files but this costs extra and is not cross platform. 

 

Many software packages can read data directly from Excel .xls files (e.g. Umetrics SIMCA-P) and presumably it is therefore also straightforward to write data out in Excel .xls format. Native LabVIEW functions for reading and writing .xls files - for example, into string arrays - would be very useful. It would not be necessary to support formatting, charts etc - although some kind of basic formatting support might be useful.

 

Of course it is possible to exchange data with Excel via delimited files (comma- or tab-separated values) but the .csv format requires characters such as quote marks, commas and carriage returns in a string to be escaped so that they are not incorrectly interpreted as part of the file structure. Tab-separated files suffer less from this problem but on Windows at least, files with a .tsv extension are not automatically associated with Excel whereas .csv files are. It would be helpful if LabVIEW also had native functions for reading and writing .csv files with correct escaping for Excel.