LabVIEW Idea Exchange

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

How is NI-MAX still so bad after all these years? It goes completely unresponsive and crashes at the slightest provocation. This feels like it should be NI's bread-and-butter.

 

Every LabVIEW team ends up recreating so much of the functionality that NI-MAX is supposed to offer out of the box. Maybe with the discontinuation of NXG, some resources should be allocated to making this product usable.

 

TurboPhil_1-1629324790878.png

 

 

KB articles like this and this probably shouldn't need to exist.

The current method override window is not very useful. My idea is to add a display for method ICON, CONNECTOR PANE and description so that I know what I'm overriding.

ice_screenshot_20151218-115416.png

Hey,

 

how about a "Delete all But this" (similar to Notepad ++) for cases in an case structure. This would save the case-structure and the code inside for the selected case.

I know, that I could delete the structure, keep the active case and get a new case structure around that piece of code...but that's not comfortable.

AllBut.png

Regards,

CMW..

While debugging my application I became curious that if an easy way finding the error is available how the things will be. Am not sure somebody has proposed it already, am giving my suggestion. The VI can have the option of pausing it when an error occurs anywhere in that VI.

 

Error Handling.png

 

 

I guess this would help us much better way of debugging an application.

The current typecast function does do a buffer allocation and copy operation even if a inplace typecast would be possible.

 

Please optimize the current function or provide an advanced version of the it.

 

Original discussion: Lava - Inplace Typecast possible?

If you have, for example, an 8-elements array, you can easily increase its dimension to 16 elements by left clicking its bottom line, and dragging it downwards. Then, simply enter a value on the 16th position (and enter all other new values according to your needs).

But if you have to perform the opposite operation, you must right click all the elements to delete one-by-one, and select "data operations -> delete element".

That can be really annoying: I'd like to see implemented the possibility to select multiple elements, and to delete them at once (or at least, to see an option like as "data operations -> delete all elements after/before").

 

It should be nice to add "Docking" and "Anchoring" features in Labview.

 

This could help creating "autosizable", professional applications.

 

For the moment, splitters and "control fitting" is a little poor, comparing to DotNet, Java ...

Many of the property accessor VI creation scripting is currently hard coded, or not easily changeable. There might be some conventions around how to name a property accessor, or about the usage of the error handling case structure inside the accessors. It would be nice, if there was a user settable option for these.

The things that I have to change often:

  • The read VI to Get, the Write VI to Set
  • Front panel controls and indicators to the default style
  • Removal of the error handling case structure
  • Renaming the Error in (no error) to error in (this might be solved by the global ini setting though)
  • Organizing the labels to the left for controls and right for indicators on the block diagram
  • Cleaning up the front panel, with the Ctrl+U shortcut, while there is a scripting code in the quick drop to arrange both the front panel and the block diagram, by default Ctrl+F

To fix most of these, I modified the scripting library, for all the templates and the global defaults containing the name for read and write VIs.

It would also be nice if we could override the scripting class as a whole, in order to customize the end result, without needing to go over trough VI again.

The only nice thing about llb files vs lvlibs is that they contain all the files for the library. But there is no namespacing, access scope, and they can not contain two files with the same name. The latter rules out dynamic dispatch. Packed project libraries solve this but they can be a pain to use and the vis can not be inlined.

 

I propose a new "Bundled Project Library" which is a hybrid of llbs and lvlibs. They contain all the functionality of an lvlib but actually contain the vis. These can be regular libraries or classes. This would resolve a known issue with VIPM when building class hierarchies.

As my VI grows I often need to search for items (e.g. using "Find All Instances" or "Find >> Property Nodes"). When I browse through the search results I then find myself jumping all over the block diagram.

 

Very often however, I want to get back to where I was before the search so I can continue what I was doing. Unfortunately that usually means flicking through a bunch of case structures until I remember where I was! 

 

flow.png

 

 

What I would LOVE is browser-style navigation for the block diagram, allowing me to easily get back to where I was no matter where I end up!

 

 

back.png

 

 

My first thought is that this function should operate within a single VI only. That should make it clean and simple... It would effectively just toggle which cases are visible on the block diagram.

 

It could potentially be extended to navigate across multiple VIs, but that's something I could live without for now... 

 

With LINQ (Language-Integrated Query) becoming increasing prevolant in .Net programming, more and more classes are using <T> Generics.

Unfortunately, LabVIEW does not support Generics, which limits the Methods and Classes available when importing .Net Dll's.

 

Take the following code:

 

namespace GenericsTest

{

   public class GenericList<T>

      {

      void Add(T input) { }

      }

 

   public class NonGenericList

      {

      void AddNoT() { }

      }

 

   class TestGenericList

      {

      private class ExampleClass { }

      static void Main()

            {

         // Declare a list of type int.

         GenericList<int> list1 = new GenericList<int>();

         // Declare a list of type string.

         GenericList<string> list2 = new GenericList<string>();

         // Declare a list of type ExampleClass.

         GenericList<ExampleClass> list3 = new GenericList<ExampleClass>();

            }

      }

}

 

When importing this to LabVIEW

 

GenClass.PNG

 

Notice that I can only see the "NonGenericList" Class as LabVIEW fails to destruct the "GenericList" Class.

One solution to this problem may to treat generics as Method/Constructor inputs, allowing the developed to choose the Generic Type.

I think the rearrange cases option would be a little bit more user friendly if the size were a bit bigger.  I don't see why it needs to be so small.

 

 

rearrangeCases.PNG 

Hello,

 

I started programming at age 9 - over 29 years ago. I enjoy programming in Labview for about 12 years now.
Recently I notice my kids look for games on the internet, but they don't learn programming as I did in their age and I am not happy about it. This drove me to think of an interesting idea.
It's an educational game I call The Labview Challenge, intended to run for free via internet. Kids play and learn how to program.
The game is similar to "The Incredible Machine" where you have basic building blocks and a goal.

In this game the user screen has inputs and outputs. The building blocks are Labview parts. The user places parts and wires them to build a program that solves a puzzle. It starts with easy tasks. A few examples of easy tasks:
Find the sum two numbers
Concatenate two strings (first name and last name with a space in between)
Find if a number is odd or even
With each task a few more parts are introduced.

The levels become gradually harder, and the score is made up of the number of nodes you used, or running speed.
In advanced levels finding the correct solutions is harder. You also can have really tough general programming tasks where you can use all Labview parts, and the solution that has the least parts or works fastest gets the first place. The hall of fame would have users who solved these and got the best scores. An example for a tough exercise is "find the n-th prime number" where a simple loop may be too slow. You can have annual tournaments.
The bottom line is that I would like to see my kid play a game and learn how to program.
An added value for NI would be that thousands of kids will have their first programming experience in Labview. It would be their choice for programming something for school, for college and for work.

 

Should be implemented by NI and placed on their servers.

 

Neat-sun

When you’re making a By Reference LabVIEW Object using a Data Value References (DVRs) the user of your class would need to embed each Dynamic Dispatching VI inside an In Place Element Structure (IPE). Or you have to create wrapper VI for each method but this undermines the advantages of LVOOP Inheritance.
 
The idea is that a DVR containing a LabVIEW Object wired to a Dynamic Dispatching Terminal is equal to calling the Method VI inside the IPE structure like illustrated below.

DVR DynamicDispatch.PNG

Message Edited by Support on 01-15-2010 04:39 PM

The current implementation for remote debugging needs two ports to be opened on a stand-alone firewall in between.

  • Port 3580 to connect to the NI service locator on the target machine
  • A random port for the application on the target to connect to
    This port is dynamically assigned to the application by asking the OS for a free one

 

This dynamic port cannot be pre-configured on the stand-alone firewall except by opening up the whole port rang above 1024.

The latter is something no IT person with any sense of security will do !

 

So we need to be able to pre-configure a certain port for the target application, so that we can open a dedicated port for this connection on the firewall as well.

Otherwise this whole remote debugging feature is useless to many companies.

 

There have been multiple cases in the last few years where customers (huge ones) have come across this issue. 

There is one thing I am missing in the Replace menu. It seems logical to have an option there to replace the VI (or missing VI) with a NEW VI.

 

Every now and then I come across code that is missing a subVI and the VI is nowhere to be found so I end up opening the VI with a question mark in the place of the missing SubVI. Now, I can see that LabVIEW knows what the connector pane of the missing subVI was (the used part of it anyway), and I just want to replace the question mark with a VI with the same connector pane. However, no "Replace with New VI" option exists.

 

There are two ways around this already, but none of them are as smart as they could be. The most obvious is to just creae a new subVI and use the replace function, but then I will have to recreate the connector pane manually. The second option (which did not occur to me until I began thinking about this idea) is that you can just click on the question mark and select "Create SubVI" from the Edit menu. LabVIEW will then do what I want - namely to create a new VI with the same connectors as was used for the missing subVI - job done. However, it will also place the question mark inside the new subVI and nag about it being missing. I can cancel the missing VI dialogs, delete the reference to the old VI inside the new one, and I am ready to rebuild the missing VI, but why not just have a replace with new option? 

 

The missing subVI is an infrequent case, so why bother? Well, this is not just handy for missing VIs. It will simplify things any time you want to replace an existing VI by creating a new one. Sure, you can save the existing VI with a new name, replace the old one with it, and then start changing the new one..But with this option it could all be done in one go.

 

 

ReplaceWithNew.png

 

 

 

 

 

I like system controls. 

 

In fact, if the system control set could be augmented to include cluster/array frames, graphs and some decent boolean indicators, then I would probably create an idea to ditch the modern controls entirely! Smiley Wink But I digress...

 

One very odd thing that happens when you set the system control set as your default is that every time you create a boolean control/indicator from the BD, you get a radio button! That's never what I want!! Are there any use cases where it makes sense to create a single radio button from an existing BD terminal or wire?? I'm guessing that the radio button is replaced with another control in 99% of cases.

 

I propose that the default boolean be changed to a checkbox.

 

This is obviously not going to satisfy all use cases but a checkbox makes much more sense than a radio button:

  • It makes sense as a "single entity"... the radio button does not.
  • It is just as compact. (Good for placing inside clusters, etc)
  • It may not be very intuitive as an indicator, but neither are any of the other system booleans!

 

This is a small but significant improvement that could surely be made very easily.

 

 

This has been mentioned before as an example within this idea, but I think it deserves to be evaluated on its own.

I've been trying to follow google's material design guidelines.

 

There are many things I struggle with when building a UI in LabVIEW... I think following a set of guidelines designed by google is a good starting point.

 

LabVIEW UI capabilities should evolve to help us implement material design UIs

 

I'd like to see a Tri-State Boolean Control / Indicator on the Modern Controls palette, which would work with an enum (similar to the System Mixed Checkbox on the System Palette). Thanks!

 

Message Edited by Broken Arrow on 06-01-2010 05:11 PM

File dialogs that have been set to only browse for folders should only have 2 buttons, one to cancel and one to select the current directory:

 

folder select.gif