NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea
Ljubo

Mixed Signal Graph and Cursor Events

Status: New
by Member Ljubo on ‎10-19-2009 05:01 AM

It seems that Mixed Signal Graph does not know Cursor Events (Grab, Grab?, Move and Release). Is there any particular reason for this? If not please incorporate this idea in the next version of LabView.

Marc Blumentritt

Project Based Environment

Status: New
by Member Marc Blumentritt on ‎10-19-2009 05:07 AM

Hi,

 

there is an idea about making labview.ini and other user configs to the corresponding user folder .

 

I propose to go a step further and make the LabVIEW environment project based, which means that you can define a labview.ini file, VI templates (including standard VI, if you create a new VI), palettes, QuickDrop stuff, etc. inside a project.

 

E.g. templates are saved in a custom location and linked inside the project. If you do this and start the "New..." dialog, than all your templates inside the project are listed first (below project).

 

If you do not use this feature in your project, the default files are used (default meaning the way LabVIEW works now).

 

Regards,

Marc

jj2

array of clusters sort options

Status: Duplicate
by Member jj2 on ‎12-02-2011 02:16 PM

Options on Array Sort VI to better handle array of clusters. What is missing is ability to specify which element of cluster to sort on wasting time with unbundling / bundling code.

 

lv block array of clusters sort.png

 

 

I use disable structures and conditional disable structures more and more as my coding starts to spread over multiple targets (Host, RT and FPGA).

 

I like to include some debugging indicators for my code so that I can (with the proper conditional disable symbols set) debug my code more easily but still remove the bloat for actual release code.

 

What I have noticed is that controls and indocators which are disabled int his way are NOT accurately represented on the FP.  As such I am surrently unable to determine by looking at the FP of a VI that perhaps half or all of the visible indicators are or are not actually being used in the code.

 

Even when the code is running, the controls and indicatory which are actually disabled are still visible (and supposedly still available over VI Server for example).  I think these controls should be actually removed or at least have a visual indication that they are diabled on the BD (distinct to the appearance caused by writing to the "Disabled" property of the control).

 

The LabVIEW help states: "When compiling, LabVIEW does not include any code in the inactive subdiagrams of the Conditional Disable structure" but I question how true this statement really is.

 

disbled controls.PNG

Although these controls are DISABLED (Not present in the source code)........

 

Non-disabled controls.PNG

Here they are.....

 

This raises issues on the FPGA level more urgently than on the PC side, but I feel the sentiment behind the idea is the same.

 

Of course things get more compilcated when the controls are connected to the connector pane, but perhaps simply prohibiting the presence of a connector pane terminal in a conditional disable structure would solve that problem.

 

Shane

j.masse

What is needed to deploy a specific function.

Status: New
by Member j.masse on ‎12-01-2011 12:42 PM

Since LabVIEW 2011 installs many things in a standard install, what I would like to see is what it takes to deploy a specific function either in the Help window or somewhere. Just because it is on the functions palette doesn't mean it is free to deploy and before using something I will have to pay extra for, I would like to know that before I use it. Also, this should help in trying to figure out what is needed to deploy your executable, since there are many different RTEs. Thanks

The asynchronous Call By Reference feature allows you to start multiple asynchronous calls simultaneously using one reference. However, when doing this, it is not always possible for the Wait On Asynchronous Call node to know which call to Start Asynchronous Call it is handling. This is especially common when the Open VI Ref option 0x40 is used to enable simultaneous calls on reentrant VIs using one reference.
 
There are currently two ways to know at a Wait node who started the call:
 
    1. Use a unique VI reference for each asynchronous call -- The problem with this approach opening and managing multiple references is more expensive than making multiple calls on one VI ref. (Note that the VI ref can be reused for another async call after a user has finished handling the Wait.)
    2. Create a unique ID and pass it to and from the target VI. -- The problem with this approach is the target VIs interface needs to be updated to accept a unique ID and return the same unique ID.
 
Neither of these are ideal.
 
I propose the Start Async Call and Wait On Async Call nodes themselves return a unique call ID. This unique ID could be used to programmatically determine which call to Start and Wait match.

When working with reentrant VIs, every time you double click an instance of a reentrant vi on the block diagram, the cloned instance is opened. This is fine during debugging but during development when you want to modify the actual code this requires that you open a clone, then CTRL+M to open the actual master vi. Much more frustrating if you have to dig several VIs deep through a highly reentrant hierarchy.

 

We have CTRL+RT Click to open the block diagram directly, how about something like ALT+RT Click to open the master VI instead of the clone.

 

Under normal development this is not such an issue but if you happen to be working with LV FPGA, just about everything is reentrant.

Well, I think the title says it all...

 

There are many threads on the NI website about this certain topic, but none of them really shows how to deal with this "problem" correctly!

 

It is a very common task to synchronize a AI signal (let's say 0-10 V from a torque sensor) with a Ctr signal (e.g. an angular position of a drive which causes the torque). How do I correctly display the torque over the drive angle in a X-Y graph?

 

It would be great if NI offers a reference example in the LV example finder, how to solve such a task elegantly and efficiently.

 

I'm not sure if this is the appropriate place for this suggestion, but anyway...I would love to see this in the LV example finder!

 

Regards

A:T:R

SteveChandler

Save Option to Include Older Version

Status: New
by Trusted Enthusiast on ‎07-30-2012 09:16 AM

We can save a VI for a previous version. If it is feasable, it would be nice if there was an option to include an older version along with the current version. For example I save my VI in 2013 with the option to include 9.0. This would effectively double the size of the VI. LabVIEW would open the newest version possible. This would be useful for uploading example code or posting it to the forums.

 

If it is not feasable then maybe Ton Plomp could implement this in his code capture tool. :smileywink:

Situation:

You have many VIs saved into one single directory on the hard disk drive. In the project explorer of LabVIEW, the VIs are well-organized within virtual folders.

 

I'd like to have a possibility to "synchronize" the project explorer with the hard disk drive. That means, all virtual folders of the project explorer will be created on the hard disk drive an the structure will be transfered. All VIs within the virtual folders in the LV project will be moved to the new created real directories on the hard disk drive.

 

Before the "synchronization":

 

before.png

 

After the "synchronization":

 

after.png

Thoric

Upgrade LV Project RT targets

Status: New
by Active Participant Thoric on ‎07-30-2012 04:14 AM

I've had a look around and can't see anything in here like this already (which surprises me so I'm suspicious that it's just the search algorithm failing) but I'd like to see options in the LabVIEW Project tree for changing target hardware.

 

For example, I have a development underway using a cRIO-9114 chassis with a 9024 controller, and a 9144 EtherCAT expansion chassis. The primary chassis is about to be upgraded to a 9116, as we need a bigger FPGA, and although the hardware upgrade process is straightforward, upgrading the chassis in the LabVIEW Project is not a possibility. Instread, I need to create a whole new target, and copy and paste every VI, node, FIFO, DMA etc. across. There's quite the possibility that I'll miss something, or the new target won't have all the same settings (Scan Mode period and priority settings for example), leaving me with that niggling feeling that something under the hood will be wrong. It would be much neater if this was an automated migration.

 

Furthermore, as the hardware is not here yet, I need to create the new target and all it's modules manually, which will take me quite some time. An automated migration would save me that trouble.

Make possible that Format into String function accept error cluster as input as the following picture show:

Sans titre.png

elset191

Use consistent increment and decrement

Status: New
by Active Participant elset191 on ‎10-08-2009 11:19 AM

Say I have a numeric control on the front panel whose value is 3.8.   If I put my cursor after the six and increment it (using the inc/dec buttons or the arrows) it goes to 3.9, 4, 5, 6.  It should go 3.9, 4, 4.1.

 

I feel like frustrated when there is a lack of connector in the existing VI and need more:smileyfrustrated:.  Because, when I update it to new pattern as shown below, I need to update the VI's instance in all other VIs in the project.  Since I am updating the pattern from lower number of connectors to the higher number of connectors, it would be better if all the instances in other VIs get updated automatically:smileyhappy:.Auto update VI connector.png

alecjcook

"Recent" Pallet

Status: Duplicate
by Member alecjcook on ‎07-24-2012 08:08 AM

How about a pallet for the block diagram that contains the users most frequently used objects

Status: Duplicate
gsussman

Open VI directly from Quick Drop

Status: New
by Active Participant gsussman on ‎05-11-2013 10:35 AM

Pretty self explanatory subject. I would like the ability to open a VI directly from the QD dialog.

 

There is already a QD plugin that performs this action (Open from QD), however this seems like something that should be native to QD.

The Proposal:

The XY Graph should be able to switch from a Linear scale to a Logarithmic scale and back again without any fuss. While the VI is running.

 

How it should work:

XY Graph Log Scale 2.png

Notice that the linear scale changes back to -2500 -> 2500 when switching from Log to Linear.

 

 

Here's how it currently works:

XY Lin-Log-Lin.png

(A Hobbit's Tale)

2 things to notice:

1. The Log scale did not automatically take the absolute value of the Y values. This should be optional, with both a Properties Dialog option and with a Property Node available to edit.

2. When changing back to the linear scale, the minimum value remains at 3. It should return to the original autofit scale, which LV chose to be -3000 to 3000.

 

Why This Should Be Done:

Currently, the work around takes up quite a bit of BD space, needs an event structure, and can be memory intensive. If you have data that you want to view on both a linear scale and a logarithmic scale arbitrarily, you need to have, at the very least, a case structure (or Select) that takes the ABS if the scale changes to log.

 

Here's the simple, made-in-10-minutes workaround example of what I'd like the XY Graph to be able to do natively:

XY Lin-Log Example VI.png

 

 

I don't think that there should be a need for extra code just to switch between linear and logarithmic scales nicely.

When you want to save a XControl, you have to save 5 items ... the savefiledialog appears 5 times ...

 

The problem is, that when you add an XControl to an autopopulating project, the savefiledialog appears 5 times,

without any memory of the last path used ! You have to browse 5 times save all elements.

 

Here some possible solutions to this problem ...

 

  1. The save file dialog should keep the last saving path in memory
  2. In autopopulating project, the saving path should be automaticaly taken from the project architecture 
  3. A special save file dialog could be build, enabling to rename and save all 5 elements in the same directory ( This solution force to save the file in the same path ... is it good ? for me i think so ! )

 

 

 

Not so much a new idea as a request to maintain current functionality. LV2010 does not support importing of LabWindows/CVI function panel drivers, can we have it back ASAP please!

 

For more info see:

http://lumen.ni.com/nicif/us/gb_infolvinstdriver/content.xhtml

http://zone.ni.com/devzone/cda/tut/p/id/3164

 

 

Kevin Snelling

(CVI Certified, CLAD, Alliance Member)

__KB__

Ability to change a condition or sequence from the bottom in LabVIEW

Status: New
by Member __KB__ on ‎11-19-2011 11:55 AM - last edited on ‎11-23-2011 12:51 PM by Active Participant JordanG

Possibilité de changer une condition ou Séquence Par le bas dans LabView

Pour les diagrammes qui ne tiennent pas toujours sur 1 fenêtre, ça pourrait être interessant de pouvoir modifier ou changer une condition (ou séquence) par le bas.

 

Translated from French:

 

For diagrams that do not always fit on a window, it might be interesting to modify or change a condition (or sequence) from below.


Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
User Kudos Count
84
46
43
40
33
Idea Statuses