LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

FIR Filter is almost the same as convolution, except that it has a init/cont terminal while convolution has an input for algorithm (Direct, frequency domain). FIR filter always uses direct convolution.

If "cont" is not used, convolution based FIR filtering could be orders of magnitude faster because it scales much less steeply with input sizes. Examples have been discussed where switching algorithms from "Direct" to "frequency domain" can turn minutes into seconds (e.g. 1M points and 5k filter).

While the knowledgeable programmer can of course make his own using the convolution primitives (also programming around other limitations because this idea is not implemented :(), it might be more intuitive if the FIR Filter had an "algorithm" input where we can select between the same choices as for convolution. (From my casual understanding, "frequency domain" would ignore the "cont" input because it is incompatible. This can just be mentioned in the help.)

How many splitter bars does this VI have?

The answer is three, but they might not be where you think:

It would be useful if LV showed the splitter bars more clearly in edit mode. Switching to run mode would display them "correctly".

This idea is similar to Show hidden controls as "ghosts" in edit mode and the same basic concept can be extended further. If anyone has anything else which is difficult to see and can be shown more clearly in edit mode, why not add it as a comment?

View All (3)

Improve that damn Licence manager!

As you can read in the link below the licence manager uses the MAC addresses of a computer to create computer ID used for the activation process.

The trouble is that when you use a NI PCIe 8235 (Quad-Port GigE Vision Frame Grabber) you are adding 4 Ethernet ports to you computer and any change to any of these ports (even a fix IP change of one of the ports) will change the computer ID and therefore you will need to re-activate all your NI products... As day to day users we simply cannot work that way.

The knowledge base article below explains that in such cases we can get the hard drive serial number, send it to NI and they'll give us a computer ID based on that HDD serial instead of the computer ID given by the licence manager and we can then use it for the activation process.

The point of this idea is to ask NI to improve the licence manager so we don't have to go through this issues, I think the licence manager should inform the user about what the computer ID is based on and tell him about the options (MAC address or HDD serial) and let him choose between the 2.

How Can I Change the Hardware Used for Activation of NI Software?

PS :

and now that we're talking about improving that damn licence manager, you can refactor it to include other ideas such as :

- Smartphone application to activate NI Software

- Add a QR Code (2D Bar Code) Option To NI Product Activation Dialog

[admin edit]

I am copying the workaround posted by crossrulz in the comments to benefit users having these issues who find this idea:
"Here is a work around if you want to play around in the Windows registry:

In "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\National Instruments\License Manager" add a string value named "DiskOnly" and set it to "true". The license manager will now only use the HDD serial number."

View All (1)

As already partially mentioned in a very old discussion here, the integer display formats should have more typical defaults:

If I change an integer to hexadecimal, octal, or binary format, I want it padded with zeroes on the left and the default number of digits corresponding to the data type (e.g. U8: 8 digits for binary (%08b) and 2 digits for hex (%02x), U32: 32 digits for binary (%032b), etc. ).

These formats should appear whenever I switch formats from decimal and I can immediately change them to anything else if desired. If the current format is not decimal and is at the default for the current datatype, the format should adapt (e.g. more or less digits shown) if the datatype (e.g. U8>>I32) is changed.

When designing a application, I sometime find that I am not happy with the name I choose for a class after I have already integrated the class into my project.

I also often use the class name for the label on in/out terminals and block diagram constants of the class.

The problem arises when I change the name of the class from within the project. If I then go inspect the code, I find that the labels still have the old class name.

For example, if I rename the class from 'My original class name.lvclass' to 'My new class name.lvclass' I still see this on the block diagrams:

But what I want to see is this:

So, I propose a rule. If a control or constant of a class has its label visible and that label (or part of that label) matches the original name of the class on disk (with or without the .lvclass extension), when the class is renamed in the project, the label on the control or constant is also changed to reflect the new name.

The reason I say 'or part of the label' is if you have added a prefix or suffix (like 'in' or 'out') to the label, it would still get updated.

I also think that this should apply to labels that include the '.lvclass' and ones that do not, as I often will use the class name without the extension when labeling classes.

I am happy to accept that this correction would only apply to code within the project where the class rename happens. But it would be a bonus if there was a menu option to rerun the cleanup from a different project that might use the same renamed class.

Thanks in advance for the Kudos!

View All (4)

At present we can select only a single VI on "RightClick>Select VI" option in Block diagram. It would be much helpful if we can select multiple VIs at the same time. Image for reference

Present Method

Proposed Method

Download All

View All (1)

quick drop shortcut context help

Run As SubVI method

In LabVIEW we can dynamically run a VI in a few ways:

a) If it's not running Top Level VI or if the VI re-entrant with the Run method.

b) Already running as sub VI, with Call By Reference.

c) Make a new VI and drop the (running) sub VI on the diagram.

Downside of a) is we can't always make sub VI's re-entrant, but still want to call it by reference. Downside of b) is we need to know the strict type (connector pane). Downside of c) is we might end up with a lot of VI's just to function as Top Level VI for the sub VI's and it doesn't work in executables.

I like to propose a method, so we can dynamically call a sub VI without knowing the strict type.

This is all I want.png

Using it, we enable LV to dynamically run sub VI's while setting\getting it's parameters by name.

For sub VI's (already running) this method will act as Top Level VI. For Top Level VI's it will fail unless it's idle.

(Please ignore my first confusing attempt)

This idea is an extension of the idea given here How about a Front Panel Cleanup?. We could have a more generic front panel clean up which doesn’t really worry about the connector pane patterns (and if needed automatically connects the connector pane as well)
Here is the idea->
Often while writing a VI we create controls and indicators from the block diagram itself rather than going to the FP and creating it. Also we copy Control and Indicator terminals from other VIs and type defs and directly drop it on the block diagram than the FP because BD is what we are usually working on. Once BD is complete we look at the FP just to make sure everything’s visible and is in a good shape. Often we find that many controls and indicators are missing from the view and are badly organized. It is painful to search for controls and move them into view. Instead an FP cleanup could put things into the visible space and organize them in a simple way (controls to the left, indicators to the right, similar controls and indicators on the same level, error cluster in the bottom etc). For most cases this might be sufficient. If not it could be used as a starting point to organize your FP. Also at the same time we could automatically connect these items to the connector pane as well. If you already have organized some items on your FP and you don’t want that to be disturbed, you could select such objects and exclude it from your FP clean up.
Example->
Let’s say you are working on a block diagram creating controls and copying some from other VIs.

Now you look at the front panel and see all the controls and indicators scattered.

Also many of them are not even visible in the FP area.

Simple FP clean up with connector pane connection will put it into this state.

Note the connector pane as well. The user can either use the VI in its current state or use it as a starting point to organize his FP.

The LabVIEW IDE may coerce diagram constants when the enumerated typedef changes. The problem is: the constants may occur in many places, and the coerced value is not necessarily helpful.

In the pictures below, the "Idle" element is removed from the typedef and the IDE coerces the diagram constant to a neighboring value "triggered".

Now the program behaves as if triggered.

When a diagram constant becomes invalid, wouldn't it be better to flag it as broken, so that the programmer is forced to handle the problem?

View All (1)

Polymorphic XControl

View All (1)

To support modern web thin clients, the LabVIEW webservice needs to support the OPTIONS request. When a web browser makes a cross origin request there are a few rules that the response must comply with before the browser will provide with the result to the web application. The OPTIONS request is needed to respond to these requests.

A cross origin request is any request where an application running on one domain needs to make a request to another domain. For example, if there was a javascript application running on the domain www.labview.com and it needed to make a AJAX request to api.labview.com, the browser considers this a cross origin request. This is a common setup when the thin client is being hosted by one server, and the webservice is being hosted by another server. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Depending on the request, the browser may issue a "preflight" request. "Standard" requests are GET and POST requests without custom header fields only require the response has an additional headers. Other requests (PUT, DELETE, GET w/ headers, POST w/ headers) require a preflight request. A preflight request is an OPTIONS request. If the OPTIONS request doesn't get an appropriate response, the browser will not even make the actual request. https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

For example, I'm starting an application and here's how I'd like it setup.

1. Windows PC. This is the central server for the application. There will be a normal LabVIEW application running on this computer. There will also be a web service run on this computer. The web service will mainly host a web application written using HTML/CSS/Javascript (although it could be written using HTML vis from NXG).

2. A bunch of CRIOs. These CRIOs will also host their own web service to get system information, measurements, and diagnostics. As new CRIOs are commissioned, they'll report to the Windows PC.

Now a user uses their web browser to access to the windows PC. The Javascript Application (which is hosted on the Windows web service) provides the user with a list of all commissioned CRIOs. They then click on one and the javascript application starts to make requests directly to the CRIO's web service. Since these CRIO's are on a separate IP address, the browser flags this as a CORS request. This means that an OPTIONS request can be sent. Since I can't handle an OPTIONS request in a LabVIEW web service, I can't implement this.

This is just one example. Another case would be an Apache hosted web application hosted on an Amazon EC2 needs to make requests to a LabVIEW web service running in a different domain. Basically any time a web application (AKA something running in the browser) needs to communicate with a LabVIEW web service you'll run into this problem.

When you do a search for something in the hierarchy and you have a password protected VI, you get this dialog:

Often (for example in this case) we don't have the password for the VI and never will because it was developed by someone else. So why not allow us not to see this in the first place?

First idea - Don't display this at all for VIs in vi.lib. Just skip them.
Presumably before LabVIEW ships the VIs aren't locked anyway, so the LabVIEW developers shouldn't have a problem, and if they do, let them do a programmatic unlock. The users shouldn't be the ones to suffer.
Second idea - Generalize it a bit more. Allow us to have a configurable list of folders where the search won't bother to try and unlock VIs (so that if we have locked code from other vendors, we can discard it as well). The default folder for the list should be vi.lib.

My forum question asked here: http://forums.ni.com/t5/LabVIEW/Determine-and-Minimize-LabVIEW-Build-Dependencies/m-p/1441734 has prompted me to post a New Idea on this exchange.

To summarize: LabVIEW executables tend to be on the LARGE side especially when driver packages like DAQmx, VISA amd IMAQ are required. I'm asking if NI could add some enhanced functionality to the Application/Executable Builder that assist the user in determining and minimizing the size of the final distribution package. Ideally this would be a completely automatic function that would simply minimize the build parameters to the smallest possible set after analyzing the active project. Additionally, it would be great if this would be smart enough to pare down the driver package itself to the bare minimum. (I.E. It shouldn't require a 150MB DAQmx package size to read a few thermocouples with a 9211 module.)

At the very least, the Additional Installers tab should show the size of the packages you're checking off and the resulting installer's total size.

An example of the size increases of required installer packages for a simple DAQmx application:

Build	Size (MB)
Program Itself	8
Run-time Engine Added	104
DAQmx Core Drivers Added	258
DAQmx Core Drivers + MAX Added	712

View All (2)

I think it is very difficult to make a UI that runs on Windows and interacts with targets. Here are two suggestions to improve this:

1. We currently can't have \c\ format style in a file path control on windows. It would be nice to allow user to specify the OS syntax to use instead of assuming it should always be the local sytax.

2. The icing on the cake would be to have the File Path Control support a property node for an IP Address so when the user clicks on the browse button, it automatically browses the target (this is already an idea mentioned in the link below) and uses the syntax of the target. This becomes especially useful as we start to have targets that may have an alternative way of browsing files besides FTP. It would be a pain to figure out which SW is installed on the target and use the correct method to enumerate files/folders.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-control-of-VI-under-real-time-target-should-browse-target-s/idi-p/1776212

These two features could be implemented by having an enum property node for the File Path Control called Syntax which include options like: Local, Various OSes (Windows, Linux, Mac, etc), or IP Address. If IP Address is specified, another property Node called IP Address will be used to determine what target's OS to use (if it's not specified or invalid, we default to Local).

View All (9)

The "Coerce dots" are handled by LabVIEW as Visual warnings ... but a bad type coercion could have very bad issues !

It should be nice to be able to find all "Coerce dots" in all the VI's of a project, in order to check if they are critical or not.

[admin edit] This functionality is currently available with the VI Analyzer Toolkit (included with a LabVIEW Professional license or available for separate purchase). Specifically, you can run the Block Diagram > Performance > Coercion Dots test with the 'Block Diagram' option turned off, and the 'Single Wire' option turned on with a 'Maximum Number' of 0:

If you run the test with this configuration, it will return a failure for every coercion dot in the analyzed code.

Note: The idea will remain open, but we're mentioning the workaround here for the benefit of users who need this functionality today and find this Idea Exchange post via search.

LabVIEW Idea Exchange

"FIR Filter" needs an input for algorithm

Show splitter bars more clearly in edit mode

Improve that damn Licence manager!

Non-decimal integer formats should be padded with the correct number of zeroes by default

Update LabVIEW class controls and labels when class is renamed

Allow seletcion of multiple VIs in "Select VI" option

quick drop shortcut context help

Run As SubVI method

Front Panel Cleanup and Automatic Connector Pane wiring

Diagram constants changed by IDE when editing enumerated types

Polymorphic XControl

Add support for OPTIONS request to LabVIEW webservice

Automatically skip password protected vi.lib VIs when searching

LabVIEW App Builder Should Determine and Minimize Distribution Size.

File Path Control Support Sytax for other OS than the local one.

Find "Coercion dots" in LabVIEW project

Use a more random Random Number algorithm in LabVIEW

VISA/IVI name controls should grow to the left

Orientation of Tab Text

Array of XControls ...