Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
<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>
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?
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?
When you use Quick Drop to insert a division operation onto a wire: you almost always want the numerator to be automatically wired, and the divisor to be unwired. Yet, Quick Drop always wires up the denominator.
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
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.
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!)
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.
One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum). [NI Examples are certainly guilty of this].
I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation. Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z". Except there is no Undo, or at least it isn't bound to ^Z here.
I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text. It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.
To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?
Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes,example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a threaddiscussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:
This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closedis a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.
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.
After double clicking that file the TDMS editor of choice opens it and the directory looks like this:
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.
I search the idea forum and I see many Labview Upgrade suggestions as "DECLINED".
I know there are others out there like me, I HATE upgrading Labview. All the time required to update your custom configuration takes weeks. Heck, Labview upgrade isn't even smart enough to know all the software you're entitled to install...instead you have to force Labview to download and install your paid software individually.
Here's the deal, most of us don't have the time to upgrade because of all the maintenance we do to support our software. For instance, I have a paid Maintenance Agreement (as I do every year), I have been working in LV2015 and now it's time for me to upgrade my computer and I'm installing LV2018.
My wish, Have National instruments create a tool that would allow you to export all your custom settings, device drivers, and software requirements, etc..., so you could import these settings into a new version of LV. Making the upgrade process easier with a single tool.
Since it's so difficult to upgrade, I often wait 3 years or more before I try to upgrade. If it was more seamless to upgrade, I'd probably upgrade every release!
Anyway, we are all so busy we don't have the time to search these forums, so this request will be DECLINED too.
Perhaps NI should accumulate all of these requests to Upgrade and total them as one. Each individual request dies in a year because so many people are sticking with what works...often older versions of LV.
Sure, NI has a few upgrade tools, but, nothing that leaves you upgraded to the latest version of Labview without missing a step.
I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.
The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.
I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections
Be able to select multiple cases from the "Rearrange cases" window and select "Delete".
So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1. This means the function will wait forever until an event comes in. But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.
This idea is to have similar functionality when it comes to user events. I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it. If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running. In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.
What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.
When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.
DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing). Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up. An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open. Many dlls have similar pointers/handles that need to be properly closed. This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.
A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created. That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle. This VI would contain the code to cleanup/close the contained non-LabVIEW references. Could have other uses, such as debugging.
I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help. Please consider it.