LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (1)

Hi All,

Would it make sense for the "Save All (This Project)" menu option to appear on all VIs that are members of a project? Obviously it's on the Project Explorer window, but it's not on the VI panel or diagram windows.

I noticed that I frequently (subconsciously) select "Save All" from a VI's panel or diagram, only to get warnings that another project I have open is read only due to source control. Sometimes my Project Explorer window is buried under several other windows, and it's nice to be able to quickly save the whole project.

If I've missed something obvious or there's a good reason for this feature not to exist, I'm all ears.

Thanks,

Mr. Jim

View All (4)

I find myself making a lot of VIPM packages for code re-use. As we re-use more code we increasingly want to protect the code so that we can more freely share such packages with e.g. sub-contractors/licensed users without sharing the block diagram. (and the first person to suggest we use VI password protection gets to wear the donkey ears for the rest of the year.)

When you remove the block diagram from a VI, you also remove the ability for that VI to recompile which means that it can only run on the same version of LabVIEW and on the same hardware as it was compiled on/for. This makes it a giant pita if you have code that is used (and works) equvally well on e.g. vxWORKS cRIO and "Windows". Currently VI's consist of 4 parts (Front panel, block diagram, code and data) and without the block diagram, the code section cannot be recompiled.

I wonder, if it would be possible to extend this to either allow the "code" section of the file to be essentially an "array" or at the very least let there be two "code" sections? -It would tremendously increase the usability of the "remove block diagram" feature if we didn't need to maintain a copy for each hardware platform.

I'm not sure how technically possible this would be, but since deployed code (at least to RT) typically gets compiled into (rt)exe's the extra and un-used code section(s) could be stripped during exe build, and the slight performance hit during development/debugging runs that might come from this along with larger VI size seems to me to be a decent trade-off.

So my suggestion is to investigate this and if possible allow some extra choices during the "strip block diagram" from VI process where you get to select an extra "target platform" or two.

A much less savy alternative would be to modify the existing tool to automatically pre-fix and output multiple "versions" of the same code distribution, one for each selected target platform. This would at least speed up the process of maintaining and creating all the variations.

View All (5)

View All (1)

We require to programmatically Add an EPICs IO server to a shared variable library like you can do manually from the project explorer as shown in the picture:

Currently, there is a way to create an EPICS IO server programmatically with the function but this function will not save the EPICS IO server on a Shared variable.

We require to save the EPICS IO server to the library, then save the library(.lvlib file) to disk so we can later deploy the library.

I have run into the problem from time to time that I create a new build specification in my project, hit the Build button in the setup dialog just to have the build hang or crash LabVIEW. To add insult to injury when I opened the project file again (sometimes even after recovery) that new build specification was not there since the project was not saved before building.

I have now trained myself to resist the temptation of hitting that Build button. Instead I will exit the dialog, save the project and then start the build via a right click.

I would really like to see the project file being saved before the build is executed.

I didn't see this in a search, but wouldn't be surprised if it is already here.

I personally hate auto growing structures. I find I spend more time downsizing them after laying out the internals than I do increasing the size when it is turned off. So I have the gloabl setting turned off, so all structures I create do not auto grow.

The problem? This doesn't override the structures auto grow setting. So, if I get code from someone else who had it turned on, then I have auto growing structures.

I see 3 potential solutions:

Change the existing global setting to not drop auto growing structures to also override the setting of existing structures (the structure setting doesn't have to change, hust override it). I am even open to not having the structures have individual settings, either they all do or they all don't. But, I could see the argument for keeping that setting, especially since it is already there. I just would like to see it get overridden by a global setting.
Change the existing global setting to only enable or disable growing. All structures by default are dropped with auto grow enabled.
If the current behavior is still desired, then add a new setting that enables or disables autogrowing structures globally. This way, I could drop auto growing structres, but LabVIEW will ignore the setting if I don't want the behavior.

This would allow programmers with different preferences to both use the same code and not be annoyed by not having the desired behavior. I think #3 is probably the best solution to the problem, as you can maintain existing behavior and simply AND it with the new global setting.

View All (1)

Hello again,

Using control indexes makes for very powerful UI management. I am a huge fan.

I frequently want to update several controls with the same value, but the "Set Control Values by Index" has two polymorphic cases (that I know of):

One index, one value
Multiple indexes, multiple respective values

How about a third case?:

3. Multiple indexes, one value

What I do now:

My proposed polymorphic case:

It's a tiny little change, but it's a case I'd use all the time.

Thanks as always,

Mr. Jim

View All (6)

Allow user-defined Fonts

In Place Structure (Unbundle - Bundle)

Please ... enable also the others!

it would be easier to swap between two inputs (or outputs)

In Place Structure (Unbundle - Bundle) should work like the behavior of the original Bundle-Unbundle,

like this,

Hi all,

In a perfect world,it sould be possible to distribute items on the front panel according to the height//width of the front panel !

Today, when I create a dialog box, I place the controls on the front panel, close an eye move away from my screen, then watch if my buttons are well centered.

Tomorrow, wen I'll create a dialog box, I will place my controls on the front pannel, horizontally distribute them, and click on the new NI button to dispatch them accordingly to the current FP size !

I run into many situations where data is collected and stored in an Excel spread sheet. Moving this data into LabVIEW usually requires writing some code to either process the data after it has been saved into a .csv format or pasting the data as a single string and then parsing it in LabVIEW to get it into a usable format.

Usually, the data is in two or more columns where one column is an X axis and other columns are Y axis data points. My life would be made better if I could select all of the data I want in Excel, copy it, and then paste it into LabVIEW as an XY array cluster.

Good Implementation: I can only select two columns. The first (left most) column is always X axis points and the second Y axis points.

Better Implementation: I can select multiple columns of data and would be asked by LabVIEW which column to use as the X axis and all others are treated as Y axis data points. This would paste into LabVIEW as an array of XY array clusters.

Best Implementation: In addition to the better implementation, I can also include the column title in my selection and LabVIEW will use it to name the data series, just like Excel does when you create a scatter plot.

Consider adding a property node that will return the current error listing of a VI or all VIs. This wuld provide the same information a clickingthe run arrow on a broken VI. This information would be of great benefit when programmatically analyzing the current state of a project or set of VIs to determine the root cause of why something is not executable. Often there is one VI that is actually broken but is called by many other VIs that also appear broken but actually do not need anything fixed directly. By having the error information, the root cause could be determined without a need for opening all of the other VIs.

View All (2)

I wish the Formula VIs supported conditional logic.

More broadly, make the Formula Node and the Formula Parse and Eval VIs have the same syntax and capability.

from LV help:

Differences between the Parser in the Mathematics VIs and the Formula Node
The parser in the Mathematics VIs supports all elements that Formula Nodes support with the following exceptions:

Variables—Only a, a0, ..., a9, ... z, z0, ..., z9, are valid.
Logical, conditional, inequality, equality—?:,, &&, !=, ==, <, >, <=, and >= are not valid.
Functions—atan2, max, min, mod, pow, rem, and sizeOfDim are not valid. You can use these functions in a Formula Node or use their corresponding LabVIEW functions.

View All (3)

LabVIEW Idea Exchange

Allow mutiple fonts in the boolean text field

"Save All (This Project)" From Member VI Menus

"Remove block diagram'ed" VI's contain compiled code for multiple targets

Right Click Option to Show Function in Palette

Formula node forbid to run VI when undefined variable is used

Add an IO Server programmatically to a shared variable library

Datalogging and supervisory control module support for Labview 2018 64-bit

Build button in Application Builder Dialog should save project before build

More control of the Context Help window at runtime

Change the existing behavior or Add a new setting to control structure auto grow behavior

Set Control Values by Index - Multiple Indexes, One Value

Allow user-defined Fonts

Case structure constants for every case

In Place Structure (Unbundle - Bundle)

A more compact form of Index Array for constant index values and single output

Distribute objects according to the size of the FP

Intelligent copy of data from Excel spread sheet to VI

Propert Node To Show Current LabVIEW VI Error Listing

Implement conditional logic in Parse & Eval Formula Node VIs

Remove 'Background priority' from VI Properties/Execution since it is ignored anyway