LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Save / Load VI's program settings

I would like to see an option or VI that save / load the state of a VI and there SubVI's at a certain time (all controls I guess).

Background:

In the development of measurement software it is important, in terms of reproducibility of measurement results, to implement an option that save all scalable objects at a certain time (device settings also program settings) which depending a measurement.

Save program settings:

I know there is a way to do this by calling the VI reference and get the control values with property node and save them. But I don't think that's an accurate way because you have to manually do this with every SubVI's reference if you won’t to save them too.

Btw: in LabVIEW NXG, which I really like, it seems no way to do this because there is no 'Get Control' property node?!

Suggestion:

- two VI's which save/load all scalable program settings to/from file (hopefully in the standard data save VI Palette)

Provide the possibility that auto generated inputs/outputs are named in english.

The language of the dev environment should not matter.

It should be possible to have a dev environment in whatever language, but still be able to consequently name all front panel/block diagram element in english.

Localizing auto generated elements where one wants to manually name all other elements in english leads to the unbearable situation where languages become mixed up.

It should be taken into account that english is the standard programming language language.

label auto-numbering

hello forum

given certain circumstances, the auto-incremental function for labels may lead to entirely different meanings. maybe sticking a non-printable character or a delimiter next to autonumber can solve this?

for instance, delimiter "- " in this case would make it even worse, but a non-printable character maybe...

1st label: number: 0 to 1

2nd label: number: 0 to 1 - 1

3rd label: number: 0 to 1 - 2

and so on

Here is my idea:

When searching for something in quick drop, you should be able to press shift and double click on an item and have it either insert it onto current wire(s) or replace the current node.

QD idea.png

Background: I usually either use a shortcut for the exact thing I'm looking for or else use the arrow keys to navigate down to it and then press ctl+p or ctl+i. But in some cases I am trying to insert or replace a node I don't use often and it might be near the bottom of the list. It's more convenient to use the mouse to click on it rather than a bunch of down arrow presses. But then I have to move my hand back to the keyboard to do ctl+p or ctl+i, which is not convenient. It would be nice if I could just press shift or some other modifier and double click and it would automatically insert or replace (I think it could figure out which to do by context).

Edit: I realized that the shift key already means something because it modifies how the insert works (whether to insert on each wire or onto both wires). Therefore I would propose a different modifier key, like alt+double click inserts or replaces, and shift+alt+double click inserts or replaces with shift modifier.

Subpanel invoknode is not duplicated on block diagram by clicking subpanel on front screen with ctrl+drag

Copy paste of Sub Panel from the front panel by clicking with ctrl+drag is not working as intended. same things happens with ctrl+c & ctrl+v action.
For the two front panel controls(Sub Panel) there should be two function(invoke node) mapped on block diagram. which is not in the case of copy paste of Sub Panel.
We have to manually put Sub Panel from the control pallet, and the name of the Sub Panel is not
auto incremented like other controls like Numeric..Numeric 2, Numeric 3.

Tested on LabVIEW Version 2018.0.0 and 2018.0.1

View All (1)

With increasing support for PPLs it would be great to have them be a valid <foundvi> location.

It becomes most evident when refactoring a .lvlib into a .lvlibp.

In cases where we replace "LibraryX.lvlib" with its compiled version of "LibraryX.lvlibp", we easily end up with some VIs that referenced subVIs from the original LibraryX.lvlib that need now to be updated to refer to the versions in the .lvlibp instead.

However, even after manually locating (and selecting) the first "missing" VI from inside the LibraryX.lvlibp , it does not behave as a "conventional" folder would: listed in the default search paths under the <foundvi> category and saving us the trouble of selecting every other "missing" subVI from LibraryX.

To be fair, the workaround exists in having the original LibraryX.lvlib present and replacing it with the PPL version for all projects that use it, but it strikes me as one that could be avoided.

Please let me know if that made sense and I'll do my best to clarify it,

Thanks all,

Cris

View All (3)

If a probe window has to shorten a string due to window size constraints, it should add a "..." at the end to help ensure users are aware this is not the full string.

For example, the full line of one of the items in the array below should be something like: ni.var.psp://localhost/Untitled Library 1/Variable1.

The probe window should show "ni.var.psp://..." for clarity, rather than just "ni.var.psp://".

This probe shows a reference to a network published shared variable. It is retrieved by uncovering all the variables within a shared variable library. The code yielding that array is as follows: (the screenshot of the block diagram code for clarity)

VI Hierarchy for mind mapping, etc?

Good day forum

The already VI hierarchy is already a very useful tool in tracing dependencies and all, but if we can tweak it in the right way, it may be able to serve other purposes for instance, a organization chart plotter or mind mapper by playing with vi-subvi relations (multi-connection), icons as glyph, floating nodes as control/indicator terminal subVIs, etc.

if only this feature can be developed for LV users, it can serve as an additional value-adding tool, especially for mind mapping. should this be picked up, I would very much like to see a "resize-able" glyph for starters 🙂

or if it is remotely possible with the current versions through VI scripting, maybe the community can collaborate and work something out? and put it into Tools Network.

I think it would be very useful if when selecting a build specification, you could build all the dependencies of that build in a manner similar to the way "make" works.

When building complicated projects, there may be several builds. The simplest example is an application installer that depends on the the application to be built first. Another example is a suite of compiled utilities that all have to be compiled before the installer is made. Another example is an application that uses packed libraries, all of which should be built prior to making the final build and then the installer build.

"Make" is an old tool that does this dependency checking for you. If you select the installer to build, it would check the dependencies of the installer, defined in a "makefile", and then build any project that is out of date. The out of date projects are those where the last modified date of the source code is later then the last modified date of the built file.

In this way you can simply ask that the installer be made, confident that "make" would find all the required dependencies and compile them as well.

This can be baked into LabVIEW. The installer build already knows which build specification it is dependent on.

Below is an idea of where this feature would be implemented.

Make Dependencies.jpg

View All (1)

LabVIEW Idea Exchange

Save / Load VI's program settings

Provide the possibility that auto generated inputs/outputs are named in english

label auto-numbering

Quickdrop Shift Double Click To Insert/Replace

Please Fix This: Subpanel invoke node is not duplicated on block diagram by doing copy with ctrl+drag/ ctrl+c,v on front panel

Allow Packed Project Libraries to serve as a valid <foundvi> path for "missing" subVIs

Add "..." at end of a truncated shared variable indicator in a probe

VI Hierarchy for mind mapping, etc?

Automatically build dependencies that are out of date