From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

To my surprise there's no type specifier on the In Place Get/Replace Variant Attribute.

 

I post it as an idea even if I'm sure there's a good explanation about it. I would find it convenient if the Get Attribute type would match the one Set.

 

Is it because the new value could be of any other type? At least on the left side, if we could just specify the type as the regular Get Attribute it would be nice.

 

JICR_1-1583872024126.png

JICR_2-1583873251354.png

 

 

 

If I create a zip file for my build distribution in a LabVIEW project, I can choose "Zip entire project" for Source Files.  In this case, the lvproj file is included.  However, if I don't check that box and instead pick specific files to include, the lvproj file is not included.  

 

Sometimes, there may be installers and other drivers included in the project that I don't always want to include for size reasons during development. 

 

I'd like to be able to choose whether or not to include the lvproj file when making a zip.

I want to suggest Case Structure Selector comparison to dynamically changeable values.

Now Case Structure Selector compared to constant Boolean/eNum/Numeric/String values.

I suggest to compare the Selector input to External Inputs, for Example:

If String control wired to selector equal to C control then do the C tab content.

vladgu_0-1576400089344.png

 

I have experienced similar problems many times when I need to compare the selector to a dynamically changeable variable.

Of course, there are other solutions but I think my solution may be useful.

alternative flavor to the current text type control/indicator...

 

analog clock.png

 

 

Provide  Stop option if camera not found in IMAQdx open Camera. In loop condition not able to stop vi

cameranotfound.PNG

 

 

I know this idea has been coined already in A new head-controlled while loop, though it was closed becasue it didn't receive more then 4 kudos. That was 3 years ago and I didn't get any vote because I wasn't aware this post was out there. I'd like to re-open the discussion. Or for how long do we close suggested topics because at the time, there was not enough interest? It is not al that difficult and yet we are 2019 and NI still didn't solve this (as well as taking the square of a united input doesn't square the unit).

 

I have been programming a lot in LabVIEW and generally love it, but I also find it quite frustrating that you can not do the classic "check condition first, then run". I alos find the classic arguments not valid.

 

Some argue that it is easily solved using a case structure and while loop, which is not equivalent. One solution is to put the while loop inside the conditional loop, which forces you duplicate the conditional code and good programmers don't like duplicate code. (You could create subVI though, but that is also creating a lot of overhead for both the programmer as the program at run-time). Another solution, as some suggested here, is to put the case structure in the while loop, but then if you are indexing the output, you output a array with one element, whereas you probably wanted to output an empty array. In this case you can work with conditional terminals but that is also a lot of overhead and there is even a bug in LabVIEW when you output multidimensional arrays in this way that are empty and later on try to iterate over it, a for loop will execute the inside of the for loop, although the array is "empty".

 

I also find the argument that it is a rare case not compelling, I myself experienced this often while programming and the whole sense of a while (or conditional for) loop is that you don't know beforehand how many times you will have to iterate it. So it might be as well that you don't even have to iterate it a single time. That sounds reasonable, no? Otherwise you would use for loop. It is actually the other way round: the classic "do while" is a rare case (that's why textbooks first learn the while loop).

 

I also don't agree with the fact that the way LabVIEW works, it is not possible. I understand that you need a value for non-indexing terminals, but that would simply be not supported in this type of loop. A "check first then run" kind of loop would only work with iterating terminals (which can be empty) and shift registers (which can take up the value it was initialized to).

A seperate part of the loop's body must be reserved for the conditional code (for instance a rectangle that is fixed at the left underside of the while loop rectangle), just like in most languages where you have to write your conditional statement in brackets as part of the loop statement...

 

This type of loop would also solve the problem that you often have to delete the last element of your indexed array because the condition for which you probably wanted it, was no longer true (but the loop has excuted first after deciding that).

 

Lastly, it would give new LabVIEW programmers that come from any other language more familiarity with what they know. As this is reasonably a rather big flaw in LabVIEW (see argumentation above) that is some common and basic in other languages and you are likely to stumble on quite soon when you start experimenting in LabVIEW, it might just make you turn around right away, as it was almost the case when I first started programming in LabVIEW and didn't know how the rest of the language and environment is very beautifull and well designed.

Molte applicazioni VI sono utilizzate per testare oggetti simili, ma con i valori dei controlli (panel controls) diversi, adattati per ogni tipo di oggetto da testare.

L'idea è di sviluppare due funzioni, la prima che salvi in un file, ad esempio .INI, tutti i valori dei controls utilizzati nell'applicazione, in un file a cui è possibile assegnare un nome  diverso per ogni tipo di oggetto da testare.

La seconda permette all'occorrenza di richiamare il file specifico per il tipo di oggetto da testare e caricare nei controls i valori salvati nel file.

Tali funzioni dovrebbero essere molto simile a "Make Current Values As Default" e "Reinitialize Values to Default", solo che al posto di salvare i valori nell'applicativo li salva in un file.

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.

 

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+dragSubpanel 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

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

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)

 

Capture.PNG

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