LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Improving NI Example Finder

My software is used in microscopy, and the screen brightness can be annoying for people looking into the microscope. Nowadays, all microscopy has a range of dark colour schemes, to suit the user, to either work in complete darkness, or just low-light situations.

I want to be able to do the same, i.e. make custom color schemes. The system color schemes don't quite satisfy, so I really want to do this programmatically.

For most controls, i can nicely change all colors using the property nodes. But strangely enough, some controls simply don't give the option, even though you can do it manually. The color options seem to be very inconsistent in this respect...

For example, the numeric Knob or Dial are perfect. You can set the color of the knob, as well as the color of the ticks, the text, etc. Similar for a slider, where every little detail can be set.

But strangely enough, the normal numeric (digital) lacks the option to set the color of increment/decrement button. However, can set those colors manually. The menu ring however, doesn't seem to have any way to change the color.

That doesn't make senso to me.... Why give the option to set all the colors of some controls, and then not have that option available on other controls?

My request is to make sure that ALL controls have the color properties you need to color them programmatically. The Knob and Slider are nice examples where it is done very well.

View All (2)

Need Aliases for project items

I really need the concept of "aliases" or "shortcuts" to project items. Consider this project:

Case 1.PNG

Case 1: maybe the item in blue is where I left off working yesterday,

Case 2: maybe the item in blue is a VI that I have to change when I add a new class somewhere else.

Either way, to get to it, I have to

1... Open the target ('RTAC-Culverson')

2... Open the DAQOBJECT folder

3... Open the DAQOBJECT CAN folder

4... Open the DAQMODULE CAN folder

5... Open the DAQMODULE CAN.lvclass

6... Open the ACCESSORS folder

7... Open the MY OUTPUT CAN TASK folder

8... Open the VI that I want.

I suggest this:

1... I pop up on this item in the project, and choose CREATE ALIAS.

2... An Alias appears in the project. Aliases are ALWAYS at the top of the project, without opening any folders. (maybe limit to 10 aliases)

3... You can't do anything to an alias except OPEN it or REMOVE it.

4... Double clicking (= OPEN) an alias merely opens all folders leading to the targeted item, and highlighting it.

5... You can create an alias to a VI, to a CTL, to a CLASS, to a FOLDER, to a BUILD SPEC, anything in the project.

6... Deleting the original item deletes the alias to it.

This seems simple to do, because you don't need a context menu for the alias (if it's a build spec, allow BUILD in the menu, if it's a VI, allow RUN, or OPEN, etc.) Forget all that. Just OPEN it, or REMOVE it.

It's a ref to an item WITHIN the project, so copying a LVPROJ file should copy all the aliases.

Whaddya think ?

View All (3)

Type Casting Strictly Typed VIs

Allow type casting between Strictly Typed VI References

Why:

The asynchronous methods require strictly typed VIs. Strictly typed VIs depend on the connector pane and terminal wiring type (Required, Recommended, Optional). Depending on your development environment and configuration options (Front Panel > Connector pane terminals default to required), newly connected terminals may be Required -or- Recommended.

Opening a VI reference or calling an async method with the wrong terminal wiring type will result in Error 1057: Type mismatch.

To work around the connector pane variance, we need to type cast check every connector pane terminal variance in order to call the proper async method without getting the Type Mismatch error.

The amount of unnecessary complexity to call and collect a thread is infuriating. There is already enough complexity when it comes to spawning a new threads; between the conditional options (Non-Reentrant, Reentrant, Async Forget, Async Collect), VI type specifier (Generic, Strict), Connector Pane Type (Pattern, Rotation), Terminal Wiring Types (Required, Recommended, Optional), etc. Threading in LabVIEW needs improvement.

Idea:

To better support Asynchronous calls, we need the ability type cast the required strictly typed VIs to:

1. Add an option to Start Asynchronous Call and Wait on Asynchronous Call methods to ignore the VI terminal wiring type flags:

Required (0x21000), Recommended (0x20800), Optional (0x20000)

2. Support type casting VIs To More Generic Type and To More Specific Type to avoid the error 1057 Type Mismatch all together

Regards,

A LabVIEW Enthusiast

View All (3)

.net function box

.net calls can end up being pretty verbose in LabVIEW, having to pipe between property boxes to get to some nested value, when the call is pretty straightforward when written in a more traditional language. In addition, trying to replicate some .dll functionality seen in c++ is frustrated by how different the calls look. Having the ability to drop into a function block to write .net code would make it much easier to port functionality + debug.

Even if there was a penalty performance wise, it would still be a nice middle ground for getting a prototype off the ground before optimising it for LabVIEW.

View All (2)

Two more suggestions

There has also been a need for rising edge and falling edge triggers for boolean values instead of having to manually code this in every time. I know this would take extra memory space but could be turned on or off maybe in the control settings dialog.

I also have to manually code in time delay functions because everything I do is in loops with parallel code. The timers can't execute properly this way and would be nice to be able to use the built-in timing functions instead of hand-coding.

New possible search target

View All (4)

I have a set of Icons that I use, saved in the folder \<User Docs>\LabVIEW Documents\Icon Templates\VI\BS Icons. I've gone through a bit of work to organize this folder, adopting the "Reverse Alphabetic Order" that seems to be the Ordering Principle here (i.e. the Icon "Zebra" is first, "Aardvark" is last). Yet when I open the Icon Editor after starting LabVIEW, "All Templates" is selected (by default), rather than my BS Icons Library.

One way to "fix" this is to empty (or delete) the two "Frameworks" folders, both of which contain a (differing) Icon called "_blank" (so-named, I bet, to "reverse-sort" first in the list).

This is, I realize, a minor "cosmetic" issue, but creating LabVIEW VI Icons is an important part of LabVIEW Style, so why not make it more User-Friendly?

Bob Schor

View All (2)

Since a few days I'm struggling to debug a packaged library. The project library works when called with development system. If called by the corresponding executable I’m only getting error 1498 and there is no way (to my knowledge) to obtain more/usefull information. Even inside the LVInternalReports folder no information is stored. REALLY useful as well would be the bugfix of CARS #684847 which is reported since version 2016, which prevents to show the block diagram of nested PPL if called from the executable…

So please give a more convenient way to debug packed libraries and fix the mentioned CARS.

View All (4)

Enforce proper spelling of "LabVIEW" online

View All (1)

TDMS files generally come in pairs. There is the TDMS file itself which contains all the data and meta data stored in the file. And there is usually a tdms_index file. This is the file with the meta data in it, but not the actual data. The idea being that this index file is created from the original file, but since it doesn't contain all the extra data, it is faster to search through for a particular offset in the file to find something.

If a TDMS file exists in a folder without a tdms_index file, it will generally be created when calling the TDMS Open function. This means when DIAdem indexes it, or when Excel Importer opens it, or when Scout opens it, this index file is created. Often a useful way of looking at a folder of logs is to look at the Date Modified or Date Created and look at the newest. But if we are viewing a folder of TDMS files which don't have the indexes, as soon as we open one to view it, the index file will be created with the modified and creation date being set to right now. This suggestion is to have it be set to the same value as the original TDMS file. As always pictures are useful. Here is a folder of TDMS files sorted by the date modified.

Before Open.png

After double clicking that file the TDMS editor of choice opens it and the directory looks like this:

After Open.png

The index file is created, but since it has a newer mod date it moves to the top of the list. My suggestion is to have the index file have the creation and mod date set to the TDMS file so the directory will look like this after it is created:

Yes I realize you can write code to set this but I can't think of a reason why I would ever want to know what the date and time that the index file was created. I'm only interested in the data, not the index file. If this is implemented on the TDMS API side of things, then all tools that get made from that point forward will have the file modification set automatically.

With LabVIEW classes, I appreciate that:

- I can save and load class data to/from disk.

- Backwards compatibility is automatically taken care of with no coding required (in most cases).

However....this functionality breaks as soon as you rename a class (which includes moving it into a library).

It'd be great if I could rename a class (or add it to a library) and then still load data that was saved with a previous version of that class. I've been burned by this a few times where legacy data files are unrecoverable after code refactoring.... and it's a tradeoff I'd rather not have to make in the future!

(Apologies if this suggestion has already been submitted...but...didn't find it in my search)

We are already familiar with the Ctrl+Scroll to explore the Structures in the Block Diagram.

It is a handy feature to explore the Numerous Pages of a structure.

And on the Front Panel, we have a similar Primitive which has the ability to have as much pages as required - The Tab Control.

In different scenarios, we may end up with numerous pages on our Tab Control and even we may not have the Tabs/Page Labels Display visible in the GUI.

In such scenarios, while editing the GUI, we may need to switch between different pages. To switch between pages currently we have only one option with the Right Click->Go To Page->select page process.

This is making the whole GUI editing process slower.

We also have some workarounds to avoid this Right Click->Go To Page->select page process delay by temporarily making the Page Labels Display visible during the edit time to select which page to be shown.

But lets consider the efficiency if we have this Ctrl+Scroll feature for Tab Controls to explore the pages!

And it may work only in the Edit mode.

LabVIEW Idea Exchange

Improving NI Example Finder

Give ALL controls the required color properties for its need

Actor Framework- Batch Message Accesor

Need Aliases for project items

multiple change to constant and show/hide

Type Casting Strictly Typed VIs

Allow type casting between Strictly Typed VI References

Why:

Idea:

.net function box

Remove bookmark name in bookmark text if already grouped by bookmark name

Rising Edge / Falling Edge and timer delays

New possible search target

move decoration element palette to highest level

Control of knob / dial using only single axis mouse movement

Allow user-defined Default Icon Library (and show in Alphabetic Order!)

Implement a usefull way for debugging LVLIBPS

Enforce proper spelling of "LabVIEW" online

Timeouts and UID should be readable properties of "Modbus Master.lvclass" and "Modbus Slave.lvclass"

Double-click on event source to accept and close "Edit Events" dialog.

Set TDMS Index Mod Date to TDMS Mod Date

Backwards Compatibility of Class Data -- After Name Change

Ctrl+Scroll Mouse Wheel to Explore the pages of Tab Containers on the Front Panel - Edit Time Only