LabVIEW Idea Exchange

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

Hi,

 

in LV2009 a new set of VIs have been published for working with configuration VIs. They are now part of config.lvlib. But some VIs of config.lvlib are marked private, therefore I cannot use these VIs as Sub-VIs, if the calling VI is not part of config.lvlib. This is bad (at least for me), since I have written some tools to load a configuration directly from a string and not from a file. To do this in LV2009, I need these private VIs, which I cannot use without changing config.lvlib.

 

Therefore I suggest to make all VIs of config.lvlib public. In fact, is there a good reason, why these are private in the first place?

 

Regards,

Marc

When developing LabVIEW automation tools, I miss a way to list the controls connected to a VI's connector pane. That would make it possible for the user to better select which controls to set before calling a VI (dynamic VI call).

 

An "IsOnConnector" property on a control reference would be very useful. Or better; a property returning an enum with one of the four values: "NotConnected", "Optional", "Recommended" and "Required".

 

Another solution could be a property like the Controls property on a Panel reference, but only listing the controls on the connector.

 

When browsing data in MAX (Historical Data Viewer) via the cursors function the time shell be added although after an full minute, hour or day. At the moment when incrementing from 19:59:59 by one second the time will be 19:59:00. Shouldn't the expected result be 20:00:00?
Via the Historical Data Viewer it is possible to export the citadel data to text (compare screenshot). In many cases it is necessary to export only the real datapoints without interpolation (like the read trace VI supports) to avoid an incorrect representation of the recorded data.
In the LabVIEW development environment it is possible to separate the shared variables via virtual folders. In cases with more than 100 variables it is very difficult to keep a structure at runtime. Therefore it would be a great improvement for us to implement a new hierarchical level (name of the virtual folder) to ensure a well-arranged structure also in the runtime. This structure should be kept in the Shared Variable Engine and also in the Citadel Database.

I would like to see and option to use our development system that is enabled by a hardware key. That way, you can put it on any machine you want for development without worrying about licensing. A lot of LabVIEW applications are one of a kind systems, complex systems. The programmer does not always have time to add a lot of code for all the errors you can encounter. With the debugging tools in the development system, debugging would be much easier than trying to debug a built application. This would enable the owner of the software to load his system on a target machine and when he is done developing the application, he can build it as normal. It would be desirable to also be able to use you key for connecting to a remote site, using remote desktop, pachyderm, etc. This would greatly help for field support of application. It would also make it easier to support previous versions of LabVIEW, as the project and software would be on the target machine. Changes that could take days could now be done in minutes.

If you use the NI proposed way of creating Sub-VIs for functions (which is good), debugging soon becomes a nightmare with every VI opening two windows, one of which is mostly not needed (the front panel). It would be great if LV gave us an option saying "Do not open front panels when debugging", which would only open the block diagram. Instead of the front panel you could only offer a list of all input/output controls (and maybe their values), and you could put this list in the same window for all open VIs (in some organized way - maybe similar to probe window). That way all front panels would only take up one window instead of many.
I wasn't able to create a multi-line comment.  Is this possible?  If not introduce that structure...

I would like the maximize button removed from the FP & especially the BD.  I typically work with many VIs open at once and I find it very annoying to open a subVI that consumes my entire desktop with a lot of white space. This is true of the FP and the BD.

 

Lets be real - your code is not that important.  The one except might be the main GUI.

At least numeric controls and string controls loose focus after pressing enter. This is especially unpractically when navigating by key. The focus should be held on all controls as it is on boolean controls.

Classes in LabVIEW are a great step over (and finally, with LV 2009 them start to work...) but there are still two 'holes'

 

Abstract methods. 

It would be great to have the possibility to define abstract methods and interfaces. Now I'm forcing an error into the error out indicator to notify the usage of a method not yet defined but it would be better to make the compiler to recognize the usage of abstract methods during the design time. One way to define abstract methods could be the introduction of a new entry in the 'class menu' and allowing to define them just in term of front panel (block diagram not available).

 

Class duplication.

An object is duplicated on each node, so is not easy to work into parralel loops on the same instance. To use the same instance I have used references, but it is not so easy to use (not as the 'normal' wires) and it hasn't the same performance (working with reference is heavier than working with instances). It would be great to introduce a mechanism that implements the convertion from instance to object, something likes a standard 'getReference' and 'getInstance'.

it would be nice if we could copy teh changes from one vi to another while comparing two VI's
Find and Replace should be expanded to sections of code.

Hi,

 

Append True/False String is a function in LV, and it allows you to append one of the two input strings to the initial string based on a boolean input.  I use it to append pass/fail to the initial string. 

 

I think this function should also allow us to select a couple of standard true/false string without needing a true/false string input.  I should be able to right click on the node and select pass/fail, true/false, yes/no, go/no go, etc.  By doing this, we can make our code even cleaner.  When you select these standard true/false string, the appearance of the icon should also change in order to reflect what standard true/false input is selected.

 

Yik

The Block Diagram should look more like a schematic capture tool.  It should have the ability to zoom in and out and pan.  Users should be able to draw their own Vis like ICs in a schematic capture program.  Parts and wires should be drawn on a grid.

Hi all,

 

Sometimes, a cluster constant is used in LV.  Due to the size of the constant, a lot of time, it is sized down, so that only part of the constant is shown.  What if you want to see all the values in the cluster?  You have to size it up. 

 

At the moment, if we do ctrl+h and hoover over the constant, we will get some information about the constant, but not the values are in the constants.  It will be nice if the values are shown in the help window as well. 

 

Yik

My apologies if this has already been suggested ...  I've written many VIs with a While loop that has True wired to the Stop terminal, making it a "Do Once" loop.  This is such a common construct (i.e. a VIG) that it might merit its own "structure", something that "looks like" a While loop but has no Stop terminal, no "i" indicator, and is guaranteed to "Run Once".  I think having a unique "look" for this common special use of the While loop would be a useful addition.  Among other things, it would clearly distinguish "purpose" as different than a While construct.

 

Bob Schor

We need the ability to manage multiple volume licenses from a single VLM instance.  We have several groups from different cost centers that use LV; however, currently all the license administration falls on me.  The only solutions available at this time are:

  1. Merge all the licensing needs from each group into a single license.  This is a nightmare for me.  For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays.  Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file.  If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license.  If a group wants to add products to their license, all requests get funnelled through me.  This might be good for NI, but it's a royal PITA for me.  (License administration is something I do in my "spare" time.)  Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
  2. Maintain separate computers for each VLA.  From an ease-of-use perspective this is almost as bad as option 1.  From a practical perspective this is worse than option 1.  It's silly to have several different computers sitting around doing nothing other than running a license server.  Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.

Neither of these solutions work very well.  I don't mind the license administration part of the job.  Creating installers, changing permissions, and stuff like that doesn't really take that much time.  What is killing me is the account administration part of the job.  The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all.  What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements.  When they get the license file they can send it to me and I'll install it in the VLM.

 

I envision each VLA having it's own root node in the tree diagram.  Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc.  (I have to be able to rename or annotate the root node for each VLA.)  The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.

Currently, mass-compiling runs into problems with subversion files in "_svn" directories (files called X.vi.svn-base).  There should be a setting to exclude these directories.