LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I have written and read code that sets Disabled property many times, and it always looks the same.

Enabled or Disabled and Grayed Out.jpg

I wish I cold say the same thing with two nodes and one wire instead of five nodes and four wires. This is what I have in mind.

EZ Enabled.jpg

I am not attached to the name of the proposed property. I am partial to the Boolean data type and I prefer to go with positive language (enabled as opposed to disabled).

One alternative for naming is to use plain "Enabled" for the proposed property, and change the name of the old property to "Disabled Mode" or "Enabled Mode".

Add QControls to LabVIEW Core

The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.

I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.

View All (4)

The "Convert Instance VI to Standard VI" right-click option on malleable VIs made me think if this technology could be used for debugging otherwise inlined VIs (and therefore also malleable VIs)?

VIM Convert.png

VIs are obviously inlined without their block diagrams, so my suggestion would require two changes:

1) 'Allow debugging' must be settable in combination with inlining in VI Properties >> Execution.

2) LabVIEW IDE and RTE would have to call inlined VIs in different ways, depending on this setting. Suggestion follows:

Running in the IDE

The IDE would now create a temporary unique instance for each running inlined subVI that has debugging enabled. This would allow us to double-click on an "inlined" subVI while it's running, and have that temporary instance open up ready for probing. Settings like the 'SubVI Node Setup' dialog would now also be available for inlined VIs, if they have 'Allow debugging' on. Set 'Allow debugging' off and inlined VIs will behave as today (so no change for any existing code).

Running in the RTE

Executables are built with 'Enable debugging' either on or off (Advanced page of the Application Builder). I suggest that Application Builder builds in unique instances in place of debug-enabled inlined VIs when 'Enable debugging' is on, and bakes in ordinary inlined code when 'Enable debugging' is off. This would allow us to debug into inlined (and thus also malleable) VIs inside executables with remote debugging. Loose VIs called with the RTE would have had their inlined callees compiled with either debug capability or not, depending on their 'Allow debugging' setting as discussed above in "Running in the IDE".

What do you think - would it be nice to be able to debug inlined VIs?

View All (8)

Pict rings support drag and drop from File Explorer, but only for a single image. Filling a pict ring with more than a few images is a slow and potentially error prone process:

Drag and drop image from File Explorer into pict ring
Right-click pict ring -> Add item after
Drag and drop image from File Explorer into pict ring
...
Right-click pict ring -> Add item after
Drag and drop image from File Explorer into pict ring

The idea is to allow dragging and dropping multiple images from File Explorer into a pict ring, and have it auto fill with each image as a new item.

View All (3)

Panel Actors provide a very extensible UI tool. There is simply nothing better than panel actors to build composite UIs, but we are still limited in that we can only insert UI elements into existing sub-panels or new windows. What if there was a simple function called Create SubPanel.vi with inputs of size and position, and an output of the reference to the created subpanel? What if closing the subpanel reference removed it from the front panel. Now we could create an infinitely complex UI at runtime. It should be a simple matter to build special support for this into the runtime environment. (I actually have no idea how hard it would be)

Use case: an acquisition UI with pre-defined display elements (graphs, gauges, numeric boxes, etc, etc), all created as individual panel actors. The user asks for a new graph element display during runtime. We programmatically drop a subpanel and then spawn the requested graph actor into it. User wants it moved, and we can do that with mouse events. Same for resize. User wants it gone and we can do that too. User wants 10 elements or 10,000. We can do that with no problem. Give us this and we can create literally any UI of any complexity, fully configurable by the user.

When I print a front panel containing a graph (who ever does that?) I get a stunningly beautiful publication-quality render of my data (overlooking the poorly done vertical y-axis label). However, all the many options of directly exporting a graph image (detailed here) ultimately provide only a screen-resolution image. See the contrast in image quality below:

Printed front panel vs exported graph image.

This idea has been discussed ad infinitum on the forum (see, for example, here, here, here, here, and here), but has never been adequately resolved. (Enlarging the graph for export does not work since graph elements do not scale, so lines, points and labels end up being far too small.) High time to implement a feature that has been in demand since (at least) 2002!

<bakground>So i just had a silly thing happen to me, i compiled a program and deployed it to the target computer, just like i did yesterday. Then it started complaining about a missing LV 2017 Runtime ... How? Why?

I reinstalled, repaired and it didn't help, both program and RT, several times and it didn't help.

I tested another program which started just fine, so what's missing? Is it some sub-package that my custom RT-installer didn't include?

I called NI and the support technician couldn't see anything wrong either, so with him on the phone i went to the development computer to look at some installer settings he had dug up. That's when i noticed i was in LV2017 64 bit! The messages said nothing about that! </background>

Suggestion:

Improve error messaging when missing RunTime. Include the bitness that's missing, now it only said "Missing LabVIEW RunTime 2017", if it had said "Missing LabVIEW RunTime 2017 (64 bit)" i would have reacted and understood directly, now it cost way too much time to admit. 😕

Also, isn't it time to scrap the 32 bit version and go only 64? 🙂

View All (1)

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)

For all of us not running an english OS but want to install plain english versions of NI products:

Please give us an option or a documented method to install LabVIEW and MAX and driver, etc. in plain english.

While it is possible to install LabVIEW in ENG, the MAX and the driver installer lookup the OS language and install the localized versions 😞 (just tried with a new PC, W10 and LV2018 full dev suite, even set my language setting to ENG, however I have to install the localized W10) That is not helpfull if you want to look up the big commuinty help or knowledge base entries and can result in 'funny' error messages.

For the driver DVD I think I found a hack in the setup.ini

[Localization]
Languages=9,7,12,17,18,2052
#ForceLanguage = 9
CustomRes0009=SupportFiles\resourceEng.dll
CustomRes0007=SupportFiles\resourceDeu.dll
CustomRes0012=SupportFiles\resourceFra.dll
CustomRes0017=SupportFiles\resourceJpn.dll
CustomRes0018=SupportFiles\resourceKor.dll
CustomRes2052=SupportFiles\resourceChs.dll
StandardRes0007=SupportFiles\niresdeu.dll
...

by uncommenting the red part. But editing the setup.ini ??

OK, in this case the hint was there (or forgotten to remove :D)

The actual suite installer comes with a .xml configuration file where that hint was missing or overseen.

I suggest something like:

Installer found local language version: <OsLang> ,

Install (where possible) in language: <ListOfSupportedLanguages>

That setting is hopefully stored for future automatic updates 😉

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)

Search windows results

Right now the search window results have 3 columns, a check box, a number, and a string containing 4 pieces of info (the vi name, window type, object type and element type).

My idea is to reformat the last column into 4 columns. The results would be the exact same, however they would be in 4 columns. Then make the multi-column list box sort-able. So if I click the list on the top of window type, then all the diagrams would be sorted together and all the panels would be together.

The most useful part of this for me would be sorting by object type. If I look for something very common and get say 500 hits in my project, sorting by object type would be a big help. Now I can quickly locate the group of hits for, like, an "EnumConstant", or whatever type of object I'm interested in. Now I don't have to slowly look though the whole list looking for the object types I'm interested in.

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.

View All (1)

With the advent of the IoT and the growing need to synchronize automation applications and other TSN (Time Sensitive Networking) use cases UTC (Coordinated Universal Time) is becoming more and more problematic. Currently, there are 37 seconds not accounted for in the TimeStamp Which is stored in UTC. The current I64 portion of the timestamp datatype that holds number of seconds elapsed since 0:00:00 Dec 31, 1900 GMT is simply ignoring Leap Seconds. This is consistent with most modern programming languages and is not a flaw of LabVIEW per se but isn't quite good enough for where the future is heading In fact, there is a joint IERS/IEEE working group on TSN

Enter TAI or International Atomic Time: TAI has the advantage of being contiguous and is based on the SI second making it ideal for IA applications. Unfortunately, a LabVIEW Timestamp cannot be formated in TAI. Entering a time of 23:59:60 31 Dec 2016, a real second that did ocurr, is not allowed. Currently IERS Bulletin C is published to Give the current UTC-TAI offset but, required extensive code to implement the lookup and well, the text.text just won't display properly in a %<>T or %^<>T (local abs time container and UTC Abs time container) We need a %#<>T TAI time container format specifier. (Or soon will!)

More robust & powerful SMTP library

The NI SMTP library is good at making e-mailing simple. But now and then I will get error 363513 (an error occurred on the network).

There are multiple known causes for this error that one can prevent, but also some unknown. The error does not specify them. I am therefore still struggling to get my e-mailing routines impervious to this error. The library should return more specific errors.

There are multiple other known issues with this library, making it quite unreliable for automation purposes. A shame, as there are few alternatives available.

A few suggested VIs for beefing up this library could be:

check if server is online
set popular SMTP header values (I don't know them, like most of us I assume)
check if e-mail was successfully sent to recipients
meta data returned: unknown recipient, attachment size exceeds limit of xMB etc

View All (3)

View All (1)

LabVIEW Idea Exchange

Easy Way to Enable and Disable Controls with VI Server

Add QControls to LabVIEW Core

Control of knob / dial using only single axis mouse movement

Drag and drop data value into variant

VIM and Inline debug with temporary instances

Support drag and drop of multiple images on a pict ring

Provide a tooltip for Recent Project entries to see project path

Easily create sub-panels during runtime

Provide access to high resolution graph export

Improved error message when missing runtime

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

NI software installer should allow a plain english installation (not only for LabVIEW)

Implement a usefull way for debugging LVLIBPS

Search windows results

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

Set TDMS Index Mod Date to TDMS Mod Date

Scripting of Actor Framework Abstract Message Wrapper for Child Classes (Actors)

New Absolute Time Format Specifier TAI %#<>T

More robust & powerful SMTP library

Allow object/text search to find items in the whole project, including VIs not in memory