LabVIEW Idea Exchange

There is no way to get to the GObject property of "Position" in the dialog box. Its only available via property nodes, but if you want to statically set the control position, this is a pain.

I run into this when I have multiple, similar VIs that i insert and remove into a subpanel. in order to set the controls to be in the same position across the VIs, i have to use the property node for a 1 time use. 

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.

Hello,

In many of my applications i had to run dynamic assynchronous VIs using a VI path.

When the VI you want to launch has some problems (VI broken, missing ressources, ... ) you get the generic error 1003. (The VI you want to launch may be broken ... ? )

This error can be easily solved when you are using LabVIEW IDE. 

But sometimes, this error can occured in an executable you have deployed to your final user computer.

And then, the error 1003 (The VI you try to call may be broken ... ) is a little bit poor in order to analyse the problem.

This error occurs, for example, when the dynamic VI tryes to access missing DLL's.

It would be nice, if the error 1003 message, could be filled out with and additionnal "error description", giving more informations about the error source.

For example, an error list, like the error list in the LabVIEW IDE. (Broken arrow error list !)

Thanks a lot.

Manu.

It would be great to have the option to get decimated (and/or interpolated) data from Citadel, up to a specified maximum # points over a time interval, with these conditions:

1)  Buffer only the decimated/interpolated data, instead of reading all the raw data and then decimating. The goal is to retrieve data from a large time period without filling up memory!!  (That's why this is best done down in the Citadel code, not up in LabVIEW.)

2)  Use the same kind of smart decimation that the LV graph uses (maybe borrow that code). For example, if you display 100,000 values on an XY graph, and they are all =10 except ONE single value=100, the graph will show that spike no matter how small the graph is, i.e. no matter how much it has to decimate the data to fit it into relatively few pixels. It would be important to keep min, max, and NaN (break) values.

The menu "tools...profile...find parallelizable loops" is a great tool to indentify loops that can be parallelized and it gives detailed advice and warnings in questionable cases.

There is however an important scenarios that is ignored in the analysis:

The case is if the parallelizable loop is contained inside a larger loop that is already parallelized. As a general rule, it is typically most efficient to parallelize the outermost loop only. A parallel loop inside a parallel loop only creates more overhead and will not gain much if the outer loop already causes 100% use of all CPU cores. It is possible that the LabVIEW compiler sorts things out automatically, but I think the "find parallelizable loops" tool should consider if an outer, already parallelized loop exists and should tone down the recommendation to a question mark instead of a check mark in this case.

Here is a typical analysis (yes, the subVI is very simple and inlined, so the outer loop parallelization is sound ;))

The description could read "This loop can be safely parallelized, but it is already contained inside a parallel loop and thus parallelization would not give any significant advantage" or similar.

Idea summary: The result window of "find parallelizable loops" should warn if a parallelizable loop is contained inside a parallel loop.