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!
My suggestion is that a Polymorphic VI should be able to contain Malleable VIs - as of LV 2018 this is not possible, and I don't think I've seen it suggested before.
The particular use case I have in mind is for a VIM which computes the average angle of an array of such angles, but changes a constant depending on whether angles are in degrees or radians. The desired option is a polymorphic selector for Degrees/Radians which would then select the appropriate VIM. The only available option currently is to add an Enum to the VIM. (A VIM is used to cope with representation and number of array dimensions).
Many Real-Time Testing (RTT) systems require a mechanism to store data in one central location that can be accessed by the different parts of the application. The Buffered Variable Table (BVT) is a set of LabVIEW VIs that developers use to store and retrieve data asynchronously from different parts of an application.
Normally, when I program applications in RTT, I need store data in one central location that can be accessed by the different parts of the application, for this, I usually use "queue operations" with a fixed size.
But sometimes, I need to insert an element at the beginning of the queue, but if it is full, it is necessary to dequeue and queue again.
To solve this problem, I could use a code similar to the image, but the applications could become unstable.
For this reason, my proposal is that labview provides the function of "Lossy Enqueue Element At Opposite End".
Currently, while inserting node by default insert quick drop Ctrl + I, it inserts node without considering wire branching. Check the picture - first is target place, and second - where it is actually inserted. Using insert menu from right-click menu works fine, b/c it inserts function exactly to proper place.
It would be nice to update this quick drop, to have the same behaviour, as non-quick drop functionality.
This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.
To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.
Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. Theydon'tevencarewhatwasusedtodeveloptheprogram.There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.
My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.
Typical phone exchange yesterday:
me: "just click my installer and install the program"
him: "OK, done."
me: "now run it."
him: "OK, ...... error about 2013 run-time engine".
me: "OK, install the run-time engine using the link I sent you in the same e-mail".
him: "clicking the link to go to the run time engine page....
(..30 second discussion to decide between downloader and direct download...)"
him: "click..(wait for it!)... .it wants me to register..."
me: "OK, let's forget about that. come down to the lab and I will do it for you."
End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.
While gazillions () of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.
I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to " I don't want to register at this time, just download the run-time!".
Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers.
Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog. The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu. I can't think of one time when this has ever been what I wanted out of this action. Instead, I think this action should open up the VI Properties Window for the VI.
Currently in LabVIEW if you build an installer you end up with a hierarchy of files that look like this:
If you want to distribute this installer via the web, you need to use a third party program to zip it up, or create a self-extracting zip file. Since LabVIEW can already create zip files with no problem, I propose the ability for LabVIEW to create a single file installer that can easily be distributed, like this:
This can be as easy as a checkbox in the current installer Advanced page:
It would be nice, if the different kind of LabVIEW windows would have slighty different icons within the windows taskbar. It would be easier to quickly identify BD / FP / project / Ctrl / etc. windows in the taskbar.
I have used labview for a long time and avid user. One issue I have been hitting lately is the "LabVIEW everywhere" slogan never really panned out, it has become LabVIEW everywhere NI allows it to be. I am getting jealous of the Arduino and Rasberry Pi and hundreds of PICS and ARMs not avaliable to me (Yes I have the pro liscence but not embedded). I wish Labview pro opened up the toolchain and started porting to many other platforms by default. I am seeing jobs that labview is loosing ot to where it should be much more competetive like the embedded market.
Essentially I am looking to see the Labview development environment easily work with toolchains for the most popular processors and also open up a simple standard to add targets to projects.
Wouldnt it be nice to program a $25 ardunio dirrectly from labview (NO THIS IS NOT WHAT THE TOOLKIT IS DOING). Add a Ardunio target file (maps the io memory to variables and throw down a loop, boolean shift register, a wait and a digital line variable, download to the micro and the blink led example is done. Really open up the doors for LabVIEW everywhere.
I can't count the number of times I've seen this dialog:
Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]! This dialog must be a holdover from pre-Undo days. Do we pop-up a dialog when you select your whole diagram and press <Delete>? What about when you press Ctrl-B? These actions have the potential to remove just as much diagram content as Remove [Structure].
Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.
Add new features, flexibility, and new controls to the Front Panel. The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap). I think it's time for NI to give more options and features for the Front Panel Controls. I attached some suggestions. They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting. NI has done a great job on the Diagrams. I should hope it's time NI improves the Front Panel.