LabVIEW Idea Exchange

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

Currently, if I have a constant array in a VI and the VI is running, I can't scroll through the array to see what some of the hidden values are.There haev been tons of times where I would like to see what the other values in the array are while the VI is running. I don't need to edit them. I just want to see them.

 

I have attached an example. Try seeing what is in element 1 or 2 of the array while the VI is running. 

Hi,

I had this idea for a while and did not find anyone else suggesting it, so heres the Idea:

 

Usually I have many VIs open at the same time and its annoying to switch between them, because they all have the same symbol in the Taskbar, and all are named "Frontpanel of ..." (rest is cut off)

Why can't Labview show the VIs icon instead? Maybe even with a little label on the icon for frontpanel / block diagramm.

Or is there already a solution for that?

Hope you like the Idea.

 

 

So I've recently discovered Darren's original post regarding the App Builder API (http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-02-15-2010/td-p/1072575) and used it to fully automate my build process.  I can't tell you how much time this saves me!  I work primarily on a good sized app that depends on an ever shifting array of plugins and 3rd party installers, and having the ability to programmatically add or remove them from a build is a lifesaver.  But because the API doesn't extend to the installer, I still have to do that last part by hand.  I'd really like to see an installer API that would allow me to add build specs to an installer on the fly.  It would be especially handy to have the ability to add other files, specify their location, and (if they are executables) set them to run them following the install. 

 

Thanks,

JasonP

Currently when I build a dll in Labview, the parameter list defaults to generating len, len2, len3 for the length of each string or array output I have in my function. Not only this but these array length are all dumped at the end of the parameter list and it is difficult to see which parameter matches which length. Please can developers consider having each length parameter after the array that they represent the length off, and name them with the name of the array parameter with Len at the end?

e.g. Currently default behavious produces:

functionName(double temperatureArray[], double voltageArray[], char errorString[], int len, int len2,int len3);

Can this be changed to:

functionName(double temperatureArray[], int temperatureArrayLen, double voltageArray[], int voltageArrayLen, char errorString[], errorStringLen);

It would be nice if mousing over a comment caused the text of the comment to appear in the Context Help window.

 

When looking at older code it is very common to see comments that are unreadable because part of the comment is being clipped off.  Although the text used to fit in the comment box once upon a time, through the various LabVIEW upgrades, OS upgrades, or default font changes, only part of the comment is now readable.  This isn't terrible when reading the code offline because you can grow the comment, but if you're trying to debug code that is running and the diagram is locked, it's pretty dang frustrating to know that explanatory text exists but is just out of visible reach.

I typically load LabVIEW by double clicking the project file in windows explorer. If I do this after a LabVIEW crash, when LabVIEW has files it wants to auto-recover, LabVIEW will go through the entire load of my project and then prompt me to recover my files. If I cancel this I then have to wait for my project to load all over again. 

 

I propose that the auto-recovery happens BEFORE the project is loaded. I know I could just run LabVIEW and then load my project through the start screen, but with any program it is a lot easier to just double click the file and let the program load.

CVI allows for color modification of the sweep line in a sweep chart (ATTR_SWEEP_LINE_COLOR), but LabVIEW does not allow any modification of the sweep line.

 

It would be nice if the developer could change sweep line width and color to make the sweep chart fit better visually in a customer-facing UI.

When you edit a VI, you may likely move the origin of the pane and not know it. Next time you run it, your controls are not centered. There are several ways to work around this:

 

  • Remember to move the panel origin back to where it was then save.
  • Use a VI that centers the GUI for you (such as one of the VI's in OpenG).
  • Use a property node in your initialize routine to set the origin.

 

How about an option which sets the panel origin to 0,0 every time we save?

 

1.jpg.... i.e., an Option which does this for us. 

 

This was issue number 7737579.

I wanted to be able to export and fill in the fields of a PDF Form.

There is already the ability to work with Word, Excel, and various other data bases, but a PDF Form is not supported.

I know there are other ways to skin this cat, but in my case, we have many PDF Forms already made that are test reports.

To have Labview run the test and insert values into the named fields of an existing PDF Form seemed like a no-brainer to me.

 

Anyway, that is my suggestion for you guys to chew on.

Thank you,

Michael

Currently, when opening a command window with the System Exec function, the "wait until completion?" option performs two operations.  It causes the VI to wait until the command is completed, and it suppresses the output in the command window.  The output becomes available on the standard output terminal after the command has completed.  This causes problems if you need to see what is happening in the command window, and you need the VI to wait until the command has completed. 

 

It would add more functionality if these options were separate.  One option, "suppress output?", would suppress the output in the command window and put the output on the standard output terminal.  The second option, "wait until completion?", would make the VI wait until the command has completed.

Many advanced funtions in the optimization and fitting palettes allow the use of a "VI model" given as a strictly typed VI reference to be defined by the user. A great feature!

 

LabVIEW provides various templates containing the correct connector pattern. Here is a list of the templates I found:

 

in labview\vi.lib\gmath\NumericalOptimization:

  • ucno_objective function template.vit

  • cno_objective function template.vit

  • LM model function and gradient.vit

in labview\vi.lib\gmath

  • Zero Finder f(x) 1D.vit

  • Zero Finder f(x) nD.vit

  • 1D Evolutionary PDE Func Template.vit

  • 2D Evolutionary PDE Func Template.vit

  • 2D Stationary PDE Func Template.vit

  • ODE rhs.vit

  • Global Optimization_Objective Function.vit

  • DAE Radau 5th Order Func Template.vit

  • function_and_derivative_template.vit

  • function_template.vit

As you can see, the naming is quite inconsistent:

  • all files are templates as is immediately obvious from the file extension! (*.vit )
  • some containing the word "_template" (undescore/lowercase t)
  • some containing the word " template" (space/lowercase t)
  • some contain the word " Template") (space/uppercase T)
  • some don't contain the word template in any form (good! :D)

 Since the extension fully defines them as templates, maybe the word "template" could be scrubbed from all the filenames, making things more uniform and consistent.

 

Idea Summary: remove the word "template" from all model template names that contain it.

I'd like to re-hash an old idea with a slightly new context:

 

Here's the original idea:

Replace Object with Quick Drop

 

This idea is currently marked as completed, even though it was completed with another Keyboard shortcut, instead of as a Right-click menu option as described.

 

 

I think that Quick Drop should be an option that shows up along with "Specific Pallete" and "All Palletes" anytime that they appear in the Right-click menu.

 

In general, I would like the ability (in any context) to select a VI from the palettes using the keyboard. 

For simple dropping of a node, this is perfectly achieved in Quick Drop (awesome.)

For Inserting or Replacing, I can use Quick Drop too, but the logic is out of order in my mind. 

I would prefer to select the action that I want (Insert, Replace, etc) from the Right-click menu, then use Quick Drop to locate the node I want. 

 

In the current implementation, if I choose Insert from the Right-click menu, I am forced to navigate the palletes.  If I go to Quick drop, I have to invoke Quick Drop, type/select the node I want, and then remember what I was trying to do ("Oh, yeah, Insert")

and then remember what the Shortcut is for that ("um...Ctrl-I? Do I hold Shift too?").

 

As a side note, this could potentially get around the limitation in Quick Drop of inserting a node onto a branched wire (see discussion here).

 

 

 

 

 

 

 

 

 

 

 

For non-integer increments, the data entry currently accumulates binary errrors due to the limits if the DBL representation, so e.g. sometimes the upper limit cannot  be reached using the increment button several times, but only when entering the upper limit directly.

 

This comes up at regular intervals, e.g. here. In one fo these discussions, I long ago suggested to make it into an idea. It seems this has not happened, so here it is! 🙂

 

This limitation needs to be handled with some internal code, e.g. to coerce the value to the nearest decimal fraction based on the least significant digit of the increment value whenever the up/down buttons are used. ... or something similar. 😉

Hello all!

Either all or some of these have surely been wished/requested before, but were unheard, since LV lacks them since 20 years.

  • Zoomable front panel and block diagram (Ctrl key modifier)
  • Reset front panel position to origin (the dot/cross) by one click
  • Lock front panel background from movement when designing UIs

I have a base typedef (e.g., a lvclass) that is used to create many different user events (see Create User Event). If many registrations (see Register for Events) are done where the base typedef is the same, the only way to tell which event is which in an Event Structure is by the order of the inputs to Register for Events and/or the anonymous bundling of multiple Register for Events.

 

I would like to dymically 'name' events when they are created with Create User Event and then to call them out specifically in the Event Structure.

 

Dynamically Named User Event.png

When Creating a LabVIEW Development Tool and Integrating into the LabVIEW Menus, placing items in the LabVIEW\wizard folder causes them to appear in the File>> menu of LabVIEW. However, there's a known issue that custom menu items in the wizard directory will be displayed in the "File" menu for VIs, but not for projects or in the Getting Started window.  IMO, this is a bug. However, I'm guessing that to get this fixed, we should call it an "idea" that needs implementing 🙂  Either way, it would improve the ability of add-on developers to extend LabVIEW.

 

My "idea":

 

Item's placed in LabVIEW\wizard folder should show in File>> menu of LabVIEW Project Explorer and Getting Started windows (just like it does for VIs).

There should be a text entry option in the LabVIEW options Window to enter the default Documentation for VIs that are created. It helps in keeping the Standards in VI documentation and forms a template for the Developer to enter the common content once and specific contents in seperate section after the VI is developed.

When replacing a bundle by name function with an Unbundle by name function or vice versa, the element names should be maintained.  Currently when you replace this function with the other, LabVIEW does not maintain the same element names. 

I would like to see an option added to the Project Library Properties: Protection to propagate the protection setting (and password) to all vi's owned by the library.

 

Currently if you lock a lvlib it only prevents adding or removing vi's from the library.  To lock the vi's from editing you would need to open and change the properties of each vi.

Many people don't know, but there is a great VI in vi.lib called Open a Document on Disk.vi which does exactly as it explains.  If you feed it the location of any document (Word, Excel, HTML, PDF, ANYTHING!) it will open it with its default program on the computer.  Unfortunately this VI is hidden from the palette deep inside the vi.lib somewhere.  I think this should be placed on the palette as it can be very helpful in application development.

 

The VI is located at C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Platform\browser.llb\Open a Document on Disk.vi (default LabVIEW installation directory may be different)