LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I often get this dialog when a class is locked because a VI is still in use by some running process. It might be a reentrant process that for some reason didn't shut down as expected, but in a system with 3000 VIs and lots of asynchronous processes it can be very hard to guess what code is still running. And this dialog doesn't give much information. It would be great if this dialog could show exactly which VI (with full information of what reentrant copy of the VI it is) is still using the class/VI. Even better if you could click on the filename in the dialog to open the VI.

I often run into this dialog, asking if I want to continue with prompts or continue without prompts when saving all. Sometimes I want to continue with prompts because I don't want to check out (Subversion) and save all of the changed files, just some of them. (I might have files with some debug changes, for example, that I don't want to save.) But it would be great if this dialog also showed a list of all VIs that need to be saved, so I know if it's only 2 more that will get a prompt, or if it's 35. Two more are okay to do a manual check out for, 35 not. Then I probably will check out a whole class or folder of classes. So please take away the guesswork of how much there is to save!

Create a Picture Ring Constant

I feel like in a few cases, my code could be more readable, if a picture ring constant existed. By that I mean if I could have a block diagram object, that showed an image, and clicking it would allow me to select one of the other images in the ring, which correspond to a numeric value, just like the picture ring control does.

I've come into a few cases were I want to know if my picture ring on the front panel is equal to some case. So I will use the equal primitive and compare my picture ring control value to a constant. Problem is my constant is just a numeric, because that is what the data type of the picture ring is. I then usually need to put down a comment explaining what the value of 2 or 3 is supposed to be. I feel like a better solution for readability would be to have an equal function, and wired to it, is another instance of that picture ring type def, where you can see the image that the value is being compared to.

Now sure this doesn't come up often, and in most cases it is recommended you convert that ring into an enum, and then you get a bunch more benefits, but in a few cases I feel like adding a picture ring constant would only make the code more readable.

I sometimes need to add (paste) text documentation to the block diagram. This often results in a single line of text that can stretch, as a single line, for what seems like miles off to the right of the text-block insertion point. I then need to make multiple drag-edge/shift-block/repeat adjustments to beat the text block down to something that will fit on the screen. It would be nice to instead be able to select the text block and either specify a width or else say to make it the same width as something else on the block diagram.

Scroll bars in text blocks would be nice too, as long as I am wishing.

Copy any Data Type to Clipboard

Currently the Clipboard.Write Method in the App Invoke node only accepts text as a data type. I think it should accept any data type. So for example, if you wire a array of doubles to it you would than be able to paste that data into a spreadsheet. Or wiring a picture data type would allow you to than paste that picture into a image editing program.

XNet Virtual Hardware / Ports

Back in the NI-CAN days, there was a handy development tool which was the usage of two virtual CAN ports, ports CAN256, and CAN257. If you wrote a frame on one, it would be read on the other, and vise versa. Other CAN hardware like Vector, and Kvasar support virtual CAN hardware which does something similar, where initial development can be tested before having access to the hardware.

This idea is to add virtual hardware support for XNET which supports this same feature. it has been talked about in a thread here several years ago, but nothing ever came of it. Adding support for virutal hardware for CAN, LIN, Flex-Ray and any other XNET hardware would be a great development tool, and enable the testing of the expected handshaking of software, with simulated communications.

Although new folders can be created in the application and installer build specifications, they are not created unless a file is put there. An empty folder is desireable for data output. It would be better for it to be created before running the application so that security access rights can be set by the person doing the installation if administration priveleges would otherwise be needed to create new files there. It leaves quite a bad impression on those who waste time finding out by trial and error that the folders defined in the build specifications are not created. The forum also documents complex schemes to work around this limitation by people who surely would rather have been doing something productive instead.

View All (1)

There are currently two NI toolkits which add a software layer on top of the automotive CAN bus.

The Automotive Diagnostic Command Set (ADCS) adds a couple of protocol standards like KWP2000 (ISO 14230), Diagnostics on CAN (ISO 15765, OBD-II), and Diagnostics over IP (ISO 13400). This is a pretty handy API when all you need is one of these protocols. But often when you need to communicate to an ECU, you also want have a normal Frame or Signal/Channel API where you get raw frame data, or engineering units on signals.

The ECU Measurement and Calibration (ECU M&C) adds XCP, and CCP capabilities on top of CAN allowing to read and write parameters based on predefined A2L files. This again is super handy, if the A2L you provide can be parsed, and if all you need to do is talk XCP or CCP to some hardware. But often times you also need to talk over a Frame or Signal/Channel API. And what if you need to also talk over some other protocol.

Every time I've had to use one of these toolkits, it has failed me in real world uses, because you generally don't want just one API you want severaal. And to get that kind of capabilities you often are going to close one API sessions type, and reopen another, then close that and reopen the first. This gets even more difficult when different hardware types either NI-CAN or NI-XNET are used. The application ends up being a tightly coupled mess.

This idea is to rewrite these two toolkits, to be as pure G implementation as possible. The reason I think this would be a good idea, is because with it you could debug issues with file parsing, which at the moment is a DLL call and hope it works, and it would allow for this toolkit to be used, independently of the hardware. Just give it some raw frames, and read data back. NI-XNET already has some of this type of functionality in the form of their Frame / Signal Conversion type, where it can convert from frames to signals without needing hardware. If these toolkits could support this similar raw type of mode then it would allow for more flexible and robust applications, and potentially being able to use these toolkits on other hardware types, or simulated hardware.

I have an application with multiple Waveform Charts, each with a visible Plot Legend, Scale Legend, and Graph Palette. I'd like to give each Chart a distinct color (a sea of gray is boring). There is a Frame Color property that does the Frame, and I figured out how to color "underneath" the X Scale numbers, but I can't programmatically color the Plot Legend, Scale Legend, or Graph Palette. To do so, I have to break out the Tools Palette and wield the Paint Brush (boring and tedious, especially when compared to wiring a single Color Box to a set of Properties). Can we get the "missing Color properties" made available?

The Figure shows the original Grey Chart, the result after wiring Yellow into the Frame Color property (note that there's still a lot of Grey, including underneath the X Scale values -- this is fixable), and the third shows what I'd like to be able to accomplish with additional Property nodes made available. It is frustrating to able to color Frame, but not the "Extras".

Bob Schor

View All (3)

Debug mode - Radix

The In Range and Coerce function is frequently used to determine whether a value is within range of an upper limit and lower limit values.

But when it is out of range, you often also want to know whether the value is out of range too high, or out of range too low. It is easy enough to add a comparison function alongside and compare the original value to the upper limit. It's another primitive and 2 more wire branches. But since comparison is one of the primary purposes of the In Range and Coerce function, why shouldn't it be built into it?

The use case that made me think of this that as come up in my code a few times over the years is with any kind of thermostat type of control, particularly one that would have hysteresis built into it. If a temperature is within range (True), then you would often do nothing. If it is lower than the lower limit, you'd want to turn on a heater. If it is higher than the upper limit, than you'd turn off the heater. (Or the opposite if you are dealing with a chiller.)

Request: Add an additional output to In Range and Coerce that tells whether the out of range condition is higher than the upper limit, or lower than the lower limit.

(That does leave the question as to what should the value of this extra output be when the input value is within range. Perhaps, the output should not be a boolean, but a numeric value of 1, 0, and -1, perhaps an enum.)

The "new" File-Dialog (alignment)

below, here is the "old" File-Dialog

But NI advises this :

the problem is that this "new" File-Dialog isn't aligned like the "old" one

Please ... align this "new" File-Dialog-Express-VI"

(thank you)

It would be quite helpful if LabVIEW would automatically grow down a function when bringing a new wire to build array/string concatenate/build cluster/interleave arrays/build matrix/compound arithmetic, allowing the programmer to make a new connection to the function if the function currently does not have room for the connection.

Even better is if it would grow/insert where the wire is near the function, below an existing connection, similar to 'ADD INPUT'.

Find and Replace ( Recent Words)

I hate right clicking. Currently (for me LV2014) double clicking on a Block Diagram Class Constant does nothing. Many times class constants are connected to launching Actors or other class VIs in the Class library. But right clicking to pop up a menu and clicking "Show Class Library" wastes a lot of time (around 2 seconds ).

To quote an example from Steve Jobs about wasted time:

“If it could save a person’s life, would you find a way to shave ten seconds off the boot time?” he asked. Kenyon allowed that he probably could. Jobs went to a whiteboard and showed that if there were five million people using the Mac, and it took ten seconds extra to turn it on every day, that added up to three hundred million or so hours per year that people would save, which was the equivalent of at least one hundred lifetimes saved per year.”

View All (2)

If I have this:

I want to be able to select the objects along the wire, outside of the frame, and then right click inside the frame (or out of it) and move them without a copy-paste-rewire to end up with this:

The key point: I'm not looking for the "wires" to change, but I want the visual structure to change to meet my needs. This is about making the VI better more quickly and with fewer errors and manual inputs.

Note: this is the simplest, most reproducible option. I am dealing with things that are substantially more complex than this.

I have found these "single pane flat sequences" to be amazing for organizing the VI, enhancing readability and utility without hitting performance. I use them to stage for convert to subvi, and moving things in/out of the box is an decent (and manual intensive) part of that.

Ergonomics is also important.

GitHub is amazing.

Figured that deserved to be on its own line just to let it sink in to the importance of this idea. Version control is no longer something only used by professionally trained software engineers. It's here for the masses; for the graphical design artists, animators, document writers. GitHub has a really cool web front-end to version control and brought sanity to DVCS (maybe bitbucket deserves some credit as well). It has championed a simplistic work-flow via pull-requests: GitHub Flow. It supports Issues for reporting bugs or other issues, and has an assortment of other collaboration features that make GitHub amazing.

GitHub (I don't mean git) integration with LabVIEW would demonstrate the power of Graphical Programming to the world.

Again, let that one sink in. There are 3 tenants of GitHub integration that LabVIEW must achieve:

1) Display the image of the block diagram and possibly front panel on GitHub when viewing a repository. Isn't it embarrassing that JKI State Machine Objects has to resort to putting images of VIs in the repo because GitHub can't render the VIs block diagram source?

2) NI must give away graphical diff and convince GitHub to run it. GitHub shows diffs on the web; Source Tree shows diffs in its tool. It's decision circa 1990 to not give Diff and Merge away with the basic version of LabVIEW. To think of diff/merge as advanced software engineering tools is a thought stuck in the past. LabVIEW needs its graphical diff shown within GitHub on a source file's history.

As a side note, vote for a version agnostic Diff/Merge idea here.

3) VI merge needs outstanding auto-merge capability that is built into pull-request merges. When creating a pull-request on GitHub, you'll see this statement (possibly), "Able to merge. These branches can be automatically merged." To work well in a DVCS multi-contributor, possibly open-source environment, the language needs superior auto-merge capability. Pretty much all other languages get it for free because they are text.

Keep in mind that NI will need a partnership with GitHub to accomplish this; however, this type of thing is not unprecedented on file type (maybe unprecedented with a proprietary langauge...). Just take a look at GitHub's ability to Render and Diff Images and GitHub's ability to Display Jupyter Notebooks (formerly IPython Notebooks).

TDM add-in for LibreOffice Calc

View All (1)

There should be an option to fully enable optimization when building an application as to automatically remove performance impacts caused by diagram elements that shouldn't cause any.

As summarily declined by NI, this idea

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-Diagram-Disable-performance/idc-p/3253939#M34372

shows that unless you manually go over ALL your VIs disabling debugging, Diagram Disables (that are supposed to not avoid executing some code!) you'll suffer a performance impact.

It is preposterous to expect the users to manually disable/reenable debugging on every single VI when building an application.

Please add an option to enable full optimization.

Shared Icon Editor Glyphs Directory

So at the moment LabVIEW has the icon editor glphs stored in the following location.

<username>\Documents\LabVIEW Data\Glyphs

This is fine, until you login as another user. Then you realize all of your icons are gone because LabVIEW installed the icons for the user that was logged in when LabVIEW was being installed.

Similarly a problem exists if I am distributing icon editor glyphs of my own. I have a reuse package with a bunch of useful icons, and I have VIPM install them to that users folder. The problem is if I login to a machine remotely, and perform the update as my user, then those icons are only installed for that user name, and not all users.

What this idea is for, is to have a shared folder for icon editor glyphs, which is used for all users on that PC. Some place like

<LabVIEW Install>\Resources\Icon Editor Glyphs

would work, or...

<ProgramData>\National Instruments\Icon Editor Glyphs

Then icons can be installed in one folder, and be shared for all users.

LabVIEW Idea Exchange

Library is locked - more information, please!!!

Show list of files that need to be saved

Create a Picture Ring Constant

Add "Resize Objects" option to to block diagram toolbar

Copy any Data Type to Clipboard

XNet Virtual Hardware / Ports

create empty directory folder in application and/or installer build specification

G Implementation - ECU M&C and Automotive Diagnostic Command Set

Programmatically Color All Chart/Graph Elements

Debug mode - Radix

High Low Terminal for In Range and Coerce

The "new" File-Dialog (alignment)

Auto-grow build array, string concatenate, build cluster, interleave arrays, build matrix, compound arithmetic

Find and Replace ( Recent Words)

Double Clicking on a BD Class Constant should "Show Class Library"

right click - move selected along wire into structure

GitHub First Class Integration with LabVIEW

TDM add-in for LibreOffice Calc

Add an option to disable debugging/enable optimization when building application

Shared Icon Editor Glyphs Directory