LabVIEW Idea Exchange

I rarely use boolean operators to solve logical problems. Instead, as I would suppose the majority of users, I use them to respond to a set of conditions and perform actions in response to different cases.

The current set of operators:

is, to say the least, quite difficult to use. For instance, for the third operator, the help window provides the following explanation:

Now if you invert one of the inputs, good luck to figure out at first glance, when you revisit your diagram, what the outcome of the comparison will be.

In fact, what we need is some kind of matrix operator for which we type in the output of the comparison of A (input 1) and B (input 2) for the different cases:

Here I have supposed the inputs are "modified-booleans" with an "undefined" case, and the output of the comparison is an integer value, just to illustrate that operators for non-booleans could be treated the same way.

In the strict boolean operator case, there would be no "U: case and the output would be T or F. It would be a simple matter (I guess) to let the boolean operator icon show the outcome of the comparison in a way similar to something like that:

In general I find useful to have non-boolean outputs (as in the matrix above where integers were used) to be able to handle complex situations. Of course the icon would have to reflect the values selected by the user...

Which brings the issue of the configuration of this operator. Considering that the interface for this operator would be quite sophisticated, it would make sense to provide it as one of the Express VIs (such as the "Formula" or "Comparison" functions).

I'm developing some software for a colleague, to run on (one of) his machines.  I do my best to follow Good LabVIEW Practices, including using Version Control (SVN) to maintain my code.  Hence my Project "jumps" from computer to computer.

I recently noticed an old problem re-appear, namely occasional Front Panel and Block Diagram labels appearing in a different Font Size (18) than I've set as the default on my Office Desktop and home Laptop (15).  This was really irritating (especially having to find those wayward labels and "fix" them), forcing me to re-examine the Where and How of setting Default Fonts in LabVIEW.

This still appears to be a Dark Art, one (perhaps) involving LabVIEW.ini (and some undocumented keys, not present in the "vanilla" configuration file).  There appear to be several such INI files, with LabVIEW.ini attuned for development, and an INI file in the Data folder of a built Executable for that Executable.  But still, the values are bereft of documentation (i.e. documentation is conspicuous by its absence) and not everything is explained (like why some values are in quotes, what they mean, and how one sets a specific Font, e.g. Arial).

One thing that I, in particular, would like to see would be the ability to set the Font Defaults on a Project basis.  For myself, I "own" the Project, and would want it to have a consistent Font (size) on all my VIs (unless I specifically decide to Emphasize something), no matter on what machine I develop them and when.  If I have to set the Font Default on a machine-wide basis, then every time I develop on my colleague's PC, I'd have to (a) note his settings, (b) change them to mine, and (c) remember to set them back when I finish.  As such sessions are often an hour here, an hour there, this "machine-centric" setting becomes a nuisance fast.

I recently had the opportunity to discuss this with an NI Applications Engineer, who assisted me in finding (some of) the obscure references to Font Setting Tricks.  I noted that a lot of what the Community knows seems to come from "Reverse-Engineering" NI's settings, and that some Documentation and Standardization (let's get away from designating Fonts as "1", "2", or "3", which have no intrinsic meaning, please) would be a good idea.  Hence this LabVIEW Idea.

Bob Schor

If you have multiple projects open, the "Error list" window lists all errors across all opened projects. Oftentimes, I'd only like to see the errors in one particular project. It'd be nice if it'd be possible to filter the "Error list" window by project:

It would be very nice if we could tell the installer script to synchronize its version number with the version number of a specific executable.

Additionally, it would be very nice to have this version information (once they are synchronized) displayed on the installer wizard (for instance in the title window or on the wizard first page).

PJM

The variant data type parsing palette is great when you have to deal with passing variants around. However, there is one call that would be super useful. If I have two variants, I'd like to know if they are of the exact same type. The type information only tells you so much. For example, if you have an array in the variant, it will only tell you it's an array, not a double float array, or a waveform array.

I've wrote a version of this that does it, but I'm not sure I cover all the edge cases. NI would be much better suited to ensure it covers all the potential typing possible and can likely make it more efficient than I could. But, I think this implementation solves this issue for most common data types and even some more exotic things that could be in a variant. I would love to see this included in the variant data type parsing palette.

In this example, I'm using it to check an array of variants to filter out ones of type I32.

Searched the exchange and found a similar idea but it didn't contain pictures so maybe that's why it didn't receive very many kudos. So here is another attempt at what I think would be a very useful addition to the LabVIEW IDE.

Occassionally, I would like to find where a specific enum value is used throughout a project. If I use the right-click Find | Callers popup menu, I obtain a list of VIs that use the enum but no indication of how many times it's used or what values are associated with an instance.

Very simple example:

The project subVI front panel and block diagrams:

Find caller results:

It would be nice to have some way of knowing what enum values are being used and have the ability to jump directly to the instance. Maybe a Find Callers that displays enum values: