LabVIEW Idea Exchange

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

A note from an NI-AE made me think: Why is there no list of LabVIEW ini file keys available, provided by the maker of the software?

 

So I propose the idea(s):

- NI should make a list of ini file keys with their usage. They may hide the "most secret" parts, but should keep the list up-to-date. There also should be given the LabVIEW version the key works on...

- NI could provide an INI file editor for the LabVIEW.ini file, similar to opening the page "about:config" in MozillaFirefox. The could even pop up the warning like FireFox does when opening that page...

The "data" control of a XControl cannot be linked directly to an existing control typedef ... It can only contain it ! (You have to include your existing cluster in the data cluster.)

 

The problem is that when you want to access the value property of the XControl, you always have to bundle or unbundle it ...

 

It would be nice to be able to create a XControl data, as a link to an existing Control typedef.

 

I hope i am clear ?

 

I know a solution of my problem  could be to create my typedef as the data of the XControl ... but in this case i cannot create many different XControls for a unique data type !

And i don't think that linking datatype to dataview is very smart ! ( It is not MVC compliant ! )

I would like to see an invert node option for all the boolean operators  (didn't we used to have this ?) For consistancy with the rest of the boolean operators the select primitave should have this for its select input too (And here I would argue that the tertiary operator is a boolean operator but, I know its in the comparision palette so please don't move it) .   I learned my logic a long long time ago and frequently use And not, Or not and if-then.  the extra not nodes clutter up my BD unless  I use the multiple boolean and frankly the symbol on that function is small enough that I can miss-read the mode.

We do Create Constant/Control/Indicator a lot when working on a block diagram. It could be much easier. How about the following:

  Double-click on output terminal with wiring tool - Create Indicator.
  Double-click on input terminal with wiring tool - Create Control.
  Ctrl-click on input or output terminal with wiring tool - Create Constant.

Front Panel Control/Indicator

  Ctrl-click on node should Create Property Node.
  Ctrl-double click should Create Invoke Node.

The key input of the Map Get / Replace Value node of an In Place Element structure is not a required input. This can lead to bugs, where a developer may have forgotten to wire the key. All other Map primitives require the key input.

map_node_key_input.PNG

The idea is to simply make the key a required input.

 

(The map isn't a required input either, but has a documented default. It should probably be required too though.)

I downloaded LabVIEW from ni.com and installed it.  Here's the process:

 

  1) Download a small downloader using my web browser.
  2) Run the downloader, which then downloads a self-extracter
  3) Run the self-extracter, which extracts the installer
  4) Run the installer

 

I'm thinking that this process can be improved a little.

Ok I'm going to try again.

 

I've already posted ideas on XControls before HERE and HERE but here's another try.

 

My feeling is that XControls COULD be a wonderful addition to the LabVIEW universe.  However....

 

1. XControls are kind of weird.  The implementation is kind of unusual and I finf the help available being not overly helpful.  I HAVE implemented XControls but I find myself having to re-scratch my head every time I take on such a proposal.  I would love a more intuitive way to work with XControls.  Even a state diagram showing what's called when would help.

2. XControls are buggy.  I've reported on these before but NI seems to not take this seriously.  There are two issues which make XControls unusable for me (I'm willing to overlook the complexity).

2a. Synchronicity.  Updating a value to an XControl terminal will return control to the calling code IMMEDIATELY event hough the XControl may require some time to process tha data.  This is completely inconsistent with existing LabVIEW behaviour.

2b. Dynamic events don't work properly with XControls.  If I register for a dynamic event in an XControl, firing the event will not "awaken" the XControl but the events will queue up until a valid event DOES happen at which point all the backlogged events get processed in a hurry.

 

If points 2a and 2sb w2ere addresses, 99% of my problems would go away but at the moment, XControls are just not worth the effort for most applications I could otherwise use them for.

 

Come on NI, you can do better.

 

Shane.

I propose that NI award anyone who posts an idea (especially this one) which is eventually accepted receive a free copy of the LabVIEW Developer Suite as an award for their creativity.

 

Should help find duplicates!

 

This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.

 

NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.

 

Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.

But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example http://www.speedtest.net/ and get download speeds at 50Mbps using American servers.

 

I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.

 

When you create an X-Control the icon that you see is the Library's icon (as the X-Control inherits (indirectly) from Library class)
Usually this is just a banner as your icon is used to "group" and identify Library Member VIs (just like any other Library)
 
However, in the Palettes and Help it shows up like this: 
  
xctrl.png
 
Which is very uninformative (the main issue here is the Palettes) and not pretty.
 
If you were to go back to your X-Control Library and change the icon to a 32x32 image (e.g. something standard to represent the control) then this icon would propagate through your Library and mess-up/hide Member VI's icons!
 
Therefore, my idea is that, through the X-Control's Properties Dialog Box you should be able to associated the X-Control Library file with a custom icon.
Initially I thought linking to an external file (.ico or .png) would be good but now I think the above is nicer - storing it in the X-Control Library would be the best.
X-Controls are a special case because currently they are the only Library file that is can be added to the Palettes. 
 
X-Control Properties Dialog, General Settings Subpanel (Concept):
 
xctrl2.png 
 
Library Icon would then populate all Member VIs and have the same behaviour as any other Library's icon.
Display Icon would be used when viewing the X-Control file visually e.g Help, Palettes etc... 

Capture.PNG

Of course, the two examples would produce identical outputs.  One would take a bunch fewer clicks and BD space though.

While using Highlight Execution for debugging, we end up scrolling the code to know which part of the code is currently executing, and loose context of the code due to scrolling. We could avoid this by letting 'Execution Highlighting' do the scrolling for us. Execution Highlighting with Auto Scrolling can be invoked on demand. The default behavior of the Highlight Execution will not Scroll. We should provide mechanism for users to disable or enable this while executing the code.

 

Also in case of state machine,

  • Current Behavior - If one highlights in the middle of execution and when a sub VI is executing, then the highlight will reach the case only after the control returns to top level VI.
  • This feature should also address the above mentioned behavior by switching to the case(state) in which the sub VI is executing.

vote.jpg

 

This idea came about from a discussion at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Require-LabVIEW-R-amp-D-response-to-any-idea-over-N-kudos/idi-p/2228468

 

The idea is to give LabVIEW users some say in which ideas are implemented. The key components of the idea are:

 

1) Set aside 5% of NI’s R&D staff to work on the “people’s choice” LabVIEW idea. That’s over 100 R&D staff, so a lot can be done.

 

2) Take LabVIEW ideas with kudos of 200 or more (there are 39 unimplemented ideas with 200 or more kudos).

 

3) Put together a poll of these 39 ideas and ask LabVIEW users to vote for their favourite.

 

4) Keep the poll open for 2 weeks and at the end of the period, take the idea with the most votes and implement it.

 

5) Once the idea is in beta, another "people's choice" poll is conducted and the process repeated. (Small ideas get implemented quickly, bigger ideas presumably are worth the wait.)

 

The 5% R&D staff, 200 kudos, etc figures can be played with to get the desired result.

 

I think we'll get more smiles on our faces from the 5% of R&D staff working on the "people's choice" project than we'll get from the 95% working on the "marketing's choice" projects.

Scenario: I have a section of code that has missing subVIs and controls (they're typedefs), and I want to disable it.  I put a diagram disable structure around the code, and it means that the missing VIs are okay, but LabVIEW still requires the typedef'd controls to be loaded <- this causes a broken arrow, even through the only broken code is within the diagram disable structure.

 

Fix: If the only reference to a typedef control is within the disabled case of a diagram disabled structure, then it should be ignored (and therefore should have to be loaded).

LabVIEW will always use the primary NIC if more than one NIC is present. It would be nice if the user could select which NIC to use programmatically and not need to worry about defining routes on the computer.

Now that NXG is going to be discontinued, I guess the NI employees who were working on it will be re-deployed.

There question is to do what??

 

A part of the LabVIEW community thinks the failure of NXG was partly due to the fact that the team working on it didn't have enough love for LabVIEW-CG and/or not enough experience using LabVIEW-CG in real world applications.

 

So my suggestion to help them understand better what makes LabVIEW great and what could make it even better is to encourage/force them to spend a fix percentage of their work-time contributing to LabVIEW related open source projects.

 

What better way to enrich the LabVIEW eco-system and make them feel for LabVIEW at the same time?

It would be preety nice if all the VIs that can be indexed in any way (for example string and array operations) would accept "n" and "n-1" and such as input to denote that the user want the last element/character/etc. or the element before the last and so on.

example.png

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

Usually, unsupported LabVIEW features can be enabled with nothing more than an undocumented INI key. The one exception that I know of is the integrated XNode development feature in the Windows version, which is instead controlled by the license manager. (This feature exists in the Linux and Mac versions as well, but on those versions it's an INI key like everything else.)

 

Despite not being officially supported, community-made XNodes are very much a thing. Even on the Windows version, one can still create them using a third-party editor, or hack their way into the built-in one somehow. And it's clear that NI (rightfully) doesn't put much if any continued effort into preventing third parties from making XNodes, as the same methods that were used over a decade ago still work just as well now.

 

I'm not asking NI to provide official support for XNodes necessarily, but I think it's for the best if they at least remove all unnecessary, artificial roadblocks, and open up the XNode development forum and perhaps some internal documentation to the public, so community-based developers can at least have the best shot at learning how to do it right. You've already done this with Project Providers; why not XNodes as well?