LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I have a case where a user is supposed to control and run test on a number of connected products (gas analysing probes).

Each product is connected with an RS232 port and also to its own water pump. Before running the tests, the user should assign an RS232 port and a pump ID to each product. When that is done, data like serial number, FW version and status (OK, clogged...) is shown.

A UI good solution would be an array of clusters containing some controls (COM port, pump ID) and indicators (serial number, FW version, status), but this can't be implemented in LabVIEW.

However, each product can preferrably be controlled and monitored with a sub-VI and as all products are identical (except serial numbers and so on), instances of the same VI file can be used (with re-entrant and so on). The front panel of the sub-VI would look something like this:

Now you could show all these front panels as subpanels in the main VI, but the only way to do this in today's LabVIEW seems to be placing as many subpanels you would need on the front panel.

However, this design is really poor as it wouldn't be scalable. The ideal solution would be having an array of subpanels:

Array of subpanels.png

Then you could add and remove subpanels/products as you like, and also easily step through them by using a for loop in the code. The thing is that this can't be implemented in today's LabVIEW.

I really encourage NI to implement this feature as it would give a lot of benefits for both the user and the programmer.

I also encourage all the readers to kodus my suggestion.

When working with Maps and Sets with objects you have to specify the parent object or otherwise, you end up with broken wires - unlike arrays. Arrays will coerce the child objects to the parent, it would be helpful if maps and sets did likewise.

Sets and Maps Objects.png

I have attached the project that you can use as a workbench.

View All (4)

1--Preview Queue Head idea.png

The element that is next-in-line to be dequeued is often called the "head" of the queue.*

The current name of the "Preview Queue Element" function suggests that any element could be previewed, not just the head. However, the function can only preview the head. Therefore, "Preview Queue Head" seems to be a more correct, more intuitive name.

"Preview Queue Element" would be the best name if the function would have an "Index" input that would allow any element to be previewed, not just the head. However, the downsides of the "Index" input are discussed in this idea: Preview Queue Element with Index .

The text in the help file of the function should read "Returns the head (the element at the front of the queue) without removing the element from the queue."

The downside of the new name is that it introduces the concept of "head" of queue. The concept is explained in the help text.

*In chapter 10 "Elementary Data Structures" (p. 234) of "Introduction to Algorithms", 3rd edition, by CLRS, it is mentioned that "The queue has a head and a tail".

View All (5)

When installing recent updates for LabVIEW 2018 an error message came up that said the installer needs access to "My Documents". However this location "file path" is not available. My company has a drive mapping package that has the my documents located on the server as well as my favorites so it is automatically backed up for recovery purposes. The installer keeps getting this error and forums state that the IT admins need to get involved every time to update & set my documents to local temporarily to install, then back to the server for automatic backups. This is very tedious and takes a lot of manpower. My colleague has the same issue with DIAdem 2018 as well. Looking to possibly have a fix where it gives the user a browse option to find the file path it needs for the install.

View All (4)

Using a ring control, it would be really nice if LabVIEW allowed the cases of a case structure to be defined by the ring contents, like an enum does rather than the ring value. It would be easy to force it to have a default case to handle values that aren't defined by strings in the ring. Just make sure you can still right click the case selector and tell it "add case for every value". This would be very helpful when creating code to handle exceptions that return values in a ring and you want to handle each case. It would be much quicker and less error prone than manually adding each numeric case that's defined in the ring.

View All (3)

View All (1)

LabView Linux Installation

We like to keep the OS installation clean/stock. That is, install RHEL and any packages required for the engineering applications and try to keep the installation packages to the minimum that are required. Typically the EDA vendors will have a script that checks that all of the Linux package required the application. If we find any dependencies we install on all machines. The LabView Linux installation script wants to be run as root and install packages. Would rather see a dependency check script so that we can install the dependencies ourselves and know what is being installed.

For the application tool itself we don't want to install in /usr/local on all machines but rather install into a NFS mounted file server so that we only need to install once and not install on each machine individually. The current Linux installation script doesn't take an argument to specify an installation directory other than /usr/local.

View All (2)

Error Locator

good day forum

it would be nice if an error locator can be used together with the current indicators. in medium and large applications, where multiple operations are executed in parallel, it could be a challenge just to locate where the error originated from, especially due to modularity, where the error causing function could be from any of the instance within the block diagram. instead of just reporting the function name that encounters the error, perhaps the option to include the nesting structure's information can be beneficial, especially for post deployment investigations, where debug application cannot be used (unavailable/lost source code, etc) and end user can do some self-checking first

several approaches came to me, which mostly revolve around VI scripting during development, that include:

renaming functions to include nesting structure information (eg. label for structure, sub-diagram, etc), or
including numeric identifiers in function names and building custom error table (identifiers for location)
traverse and filter error wire references, terminal tracing until nesting structure and and probing these wire per update during run-time

can be a nice feature to have, especially for remote support

Hello,

So as it is The VI analyzer has some limitations:

1. You can't fully customize the toolkit as some functionality is still not exposed as an API.

2. You can't build an executable with a VI analyzer.

I was hoping that NI could expose some more API that would allow for programmatic control of the error highlighting feature of the VI analyzer.

This will allow for creation of a more standalone application rather than being piggy-backed into the LabVIEW environment.

Thanks, Sher

View All (2)

I get that the Application.ini file can contain configurations options which might wished to be changed after compile, and I get that the application shouldn't modify its own exe.

But sometimes the ini file is used for things which cannot simply be hard-coded (or at least, I've found no way). For example, I am using unicode (it isn't my fault I have to resort to "experimental" modes in order to gain basic, fundamental functionality which should have been implemented as standard decades ago, but I'm not going to apologize for living in 2019), and in order for an exe to properly render unicode strings in controls etc. it requires the UseUnicode=True flag in the ini. What this means is that, in order to even function correctly at all, the exe is burdened with the constant baggage of an ini file which end users will never interact with, never understand, and frankly have a less-than-zero need to be exposed to in the first place.

I've wanted this functionality on other occasions, but I'd be happy if someone could explain why I'm wrong about the unicode thing.

There is a bit of inconvenience when I work with typedefs on FP. Very often it is much easier to edit appearance of the control on Front panel:

Make enum width the same as other text fields

Set cluster elements spacing the same as other elements.

Font type and size - apply to all selected, not one by one.

But when control is a typedef, I have to do these changes only in typedef, otherwise they are lost when I change typedef type.

Idea is to add "Apply appearance to typedef" to shortcut menu.

Similar ideas on the same topic (appearance issues when using typedefs)

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/do-not-update-non-strict-typedefs/idi-p/1878823

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Bridging-the-gap-between-strict-and-non-strict-typedef/idi-p/3304297

View All (3)

Array to Variant Function

I'm writing a VI for a lab which writes to a database. The number of measurements will vary depending upon which fixture is set up in the lab, and whether the experimenter decides to add extra ones. This results in a varying size array of doubles which gets written into a single database with generic column names c1-c200. The column names are cross-referenced in another table keyed to the lab fixture.

The method I found here is to convert from array->cluster->variant->database insert. The problem with this is that a cluster's size must be available at compile time, making the varying array size more difficult. It also limits the size of the array/database entry to 256 elements in the array->cluster conversion.

I know I could just populate and write a 200 element array into the database, but that increases database activity , is inelegant, and forces me to put zeros in the unused columns, instead of leaving them null.

Attached is a VI which demonstrates what I would like, though it only works for doubles and is still limited by the 256 element limit. It could very easily be changed for integers or strings, but it would be best if it could take any type of array input, with a much larger size limit.

Download All

View All (3)

Complex number plots

View All (2)

LabVIEW 2018 Mac icon editor broken

In the LV 2018 Macintosh icon editor, when a template file is selected, all the text fields are piled up in one line at the bottom, partly off the bottom edge. If the same file is pasted in as a glyph, the text fields are positioned correctly.

Also, having the Small Fonts typeface produce anti-aliased type is not good, it wastes space and the time needed hand-edit it to make it readable.

For me right now, the workaround is to edit icons in a blank LV 2009 VI and then open them in LV 2018.

Download All

A diagram cleanup option for resetting all excluded sections or single-use overrides could be nice to have, as the current cleanup may causes unnecessary dispersion of objects due to some 'out of view' excluded sections that can render the block diagram unreadable.

Master reset for the "Exclude from Diagram Cleanup" resets the entire BD back to be included in cleanup, can be included as a Reset All button in Tools>Options>Block Diagram>Block Diagram Cleanup;

Single-use overrides to include everything for 1 time cleanup only, can be included as a One-Time Include All button in the same options menu.

Last but not least, a list of sections flagged for exclusion, which is navigable across the active BD and highlight upon selection, similar to existing Find and Replace function, perhaps included as Diagram Cleanup Exclusions under Edit menu.

Any improvement would be nice and highly appreciated. Thanks

I have not fully explored LabVIEW NXG, but on the first look I have noticed that LabVIEW NXG uses rounded nodes in block diagrams, and wires use sharp corners where they change direction. Visually, I think wires should be rounded and all other nodes on the block diagrams should be rectangular (or left as an option to the developer). SubVI icons are editable by the developer anyway. Wires are like rivers, except they carry data (at least in our minds). Rivers do not change direction at 90 degree sharp corners. In my opinion, it is more intuitive and perhaps easier to understand the code if data wires use rounded corners and other nodes look like solid objects, with any shape chosen. Just a thought.

View All (3)

Today, a for loop always select the minimum number of iteration between the number wired in "N" input and the size of every auto-indexed array.

It will be great to select between three mode :

- the minimum value, like today, with a "N" terminal.

- a fix value, ie the value send to the terminal, who become a "F" terminal (for example), no mater the size of the auto-indexed array.

- the maximum value, with a "M" terminal for example.

View All (1)

LabVIEW Idea Exchange

Dynamic UI for set of HWs: Array of subpanels

Make sets and maps heterogeneous using just sibling classes

Rename "Preview Queue Element" to "Preview Queue Head"

Stop using removable drives as a temporary location for installation

Ring String controlling a case structure

Easy Individual Temperature Setting

Extend the OPC UA Toolkit with OPC UA PubSub Support

create local variable with option for read or write

LabView Linux Installation

Error Locator

LabVIEW VI Analyzer: Expose Error Highlighting feature of the UI to toolkit API.

Allow storing Application.ini within the exe

Apply appearance to typedef

Array to Variant Function

Complex number plots

LabVIEW 2018 Mac icon editor broken

Option for Diagram Cleanup Exclusion reset/override/tracking

Using rounded vs. rectangular geometry for LabVIEW wires, icons, structures, nodes

Fix the Horrendous Licensing/Activation issues in LabVIEW 2018

Select the for loop max number of iteration