LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Sometimes large clusters need to be 'rebundled' with one or a few elements added to make a new cluster. Currently, the programmer has to completely unbundle the entire cluster and wire all of the elements to a bundle function with the new element(s). It would be nice if there was an "Unbundle Input" option for a Bundle input that has a cluster wire to it. The Bundle function would unbundle the cluster at the input and add all of the elements (in order, of course) to the new cluster. It would only unbundle on level. That is, if the input cluster has a cluster in it, the lower level cluster would not be unbundled. When the proposed 'Unbundle Input' option is selected, the input terminal changes to a standard unbundle arrow graphic to indicate the input cluster is being unbundled.

Hello,

I have a little complain about the product (LabVIEW or other) installer.

Since most of the time the installation lasts for a (very long) while, I still continue to work on my computer (i.e.: writing docs).

Because some new install window pops up regularly and unpredictably, taking the focus, and because the default cancel button is active and it happens just when I type the enter key in my doc, the installation just get cancelled. With the help of Murphy, this happens after one hour of process without the knowledge of what has really been installed so far. So just, to be sure I can just restart the process.

This happened not only once, It’s the 2^nd time this week, one time during setup from DVD and the second while updating from the updater service.

Would it be possible to set the focus on something else than the cancel button, not let it as the default button and add a confirmation dialog to the cancel request ?

Best Regards

XControls inherit from ancestor object types (Control and GObject, namely) properties and methods that I would like to hide from the public API shown on the "Create..." context menu. Why do I want to hide these methods? Those properties or methods have the possibility of placing the XControl in an undesirable state, or possibly I have created "Override" implementations as a User-Defined property or method ("override" may not be a technically correct term here, but it conveys my intention).

I envision a tree control on the XControl Properties dialogue that contains a hierarchy of inherited properties/methods. Each entry would have a checkbox which controls whether the property/method appears on the API context menu. If, for some reason, there are some properties that should not allowed to be hidden (as determined by R&D), a disabled-and-greyed checked box would be appropriate.

(I don't expect these properties to be disabled - if you were to upcast the XControl ref to Control, you would see all the default properties/methods again, and they would perform their default action. This action may be discouraged by the XControl designer, but still permissible by LabVIEW.)

View All (12)

View All (3)

Polymorphic + Malleable VIs

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).

View All (3)

I'm using Key Down? and Key Up events to turn the keyboard into a series of switches for a behavioral experiment. For example, I want the user to push down Caps Lock with the left hand, Return with the right, then use the appropriate hand to do a specified task. By monitoring Key Down and Key Up events, I can capture the timing of the user's "button sequences" (to the accuracy of Window's clock).

Key Down? provides three indicators of what key is pressed -- Char, which is an I16 representation of the Ascii character (and hence can be "converted" easily into a string one could test, e.g. is this "A"?), VKey, an enum saying if the key is an Ascii character or a "special" key (such as Caps or Return), and ScanCode, which is another I16 that corresponds (somehow) to each key on the keyboard. There are also boolean indicators that can tell you if Ctrl, Shift, or Alt are being simultaneously pressed. Of these, the least "transparent" is ScanCode, as there is no obvious way (other than placing a comment on your code) to know that 58 corresponds to CapsLock.

Unfortunately, Key Up only provides ScanCode! So while I can write "nice" code that can more-or-less self-document that I'm testing for Caps Lock or Return (simply wire VKey to a Case statement, which will allow me to have a case labelled "Caps", pretty obvious, no?), I don't have such functionality with the Key Up event.

Suggestion -- add Char and VKey inputs to the Key Up event! This will make it "symmetrical" with respect to Key Down?, and will enable producing Key Up code that doesn't need to rely on "magic numbers" (Scan Codes) for specific keys.

Bob Schor

Dear NI devs,

scrolling using the mouse in the Project Explorer window is slow. Each move of the mouse wheel equates one line in the project explorer, hence one subVI. Please increase the steps size or add an option to set the scrolling speed, please.

The behavior can be tested only when the list of subVIs in the Project Explorer is longer that the window size.

Cheers,

P.S. Previous discussion on the topic: scrolling using mouse in the project explorer window is slow

Project INI file ...

For the moment the INI file is managed as global feature (Link in the executable : Link to Labview.ini by default )

I think the INI keys are part of the project.

So it would be more "User Friendly" to be able to edit them as "Project properties". (Like conditional disable symbols)

Associated directly the INI keys to the project will avoid to lost important part of your application.

For example the key "useLocaleDecimalPt" is usefull when you want to force the decimal point to ".".

This is usefull when you use "Instrument drivers" which are decimal point dependant ... but don't alert when the active decimal point is ','.

I think that ini keys are part of the source code. So theire place is in the project, as project properties ... (Not globaly managed in the Labview directory)

I think that adding INI keys to the project will limit the problem of "source lost" when you many personns works on the same project ...

Or when you had to modify an old project on a new installed PC.

For the moment, I create my own local INI File in my project ... but it is not user friendly, it's manual !

View All (5)

Almost every time when I'm building an application, I always have to reconfigure the created ini-file (based on labview.ini file) denpending on what to use.

Then I have to go search for the tags in labview.ini and copy them in my ini file.

It would be easier if you could hit a configure button in the application builder so you could select which setting you want to use in your own ini file and which one you don't.

I'm especially struggling with some standard ones like useLocalDecimalpoint

View All (3)

OK... i have been using LabVIEW from 2003 (i guess) and i started using 6i or a version less than that.

Ever since i see that the size of the installer is getting bigger and bigger due to RTE and now it takes aroud ~100MB. I suggest to get rid of this so that i can straight away run the executable in any PC/MAC without ever requiring to install the RTE. (may be even replacing the RTE with a .NET or other technology which gets installed automatically when windows OS is installed)

Guru

The LabVIEW Help for the OPC UA Connect VI has this statement in the description of the "OPC UA data change event" output: "NI does not recommend using this output."

The example VI "Data Access Client.vi" inside "OPC UA Demo.lvlib" uses this output. Could it be possible to add a possible explanation as to why in the Example the "OPC UA data change event" output is used? Or could the Help for the OPC UA Connect VI be modified?

Example:

Help documentation:

View All (2)

Keep supporting NI-CAN

Today I discovered NI has discontinued support for NI-CAN hardware (not XNET) beyond LabVIEW 2015SP1. If you want to use your code with NI-CAN hardware and LabVIEW 2016 and beyond, you are out of luck unless you have the cash to buy XNET replacements and want to rewrite your code for the XNET API.

I have a very large J1939 simulation/monitor application I wrote and have supported for the past 8 years that is used on several lab benches and by numerous software developers across the country. Now, we stuck with LV2015SP1 forever unless we can find a large amount of cash to replace all the NI-CAN hardware, which isn't going to happen anytime soon.

So, my idea is for NI to keep supporting NI-CAN in current and future versions of LabVIEW

View All (1)

View All (2)

View All (5)

Three level TDMS hiearchy

Let's assume I must do three (or more) operations in sequence (in the following example, instrument control operations)

There are several ways to force execution order. But I want to use a flat sequence (for example, in order to insert timing VIs).

My goal is the following:

There are at least two problems:

- if I try to include the first VI on a flat sequence, other VI's wires will appear "beneath" the sequence (not throug)

- If I add a frame afterwards, there's no way to include existing code without redrawing the wires.

I propose two possible solutions:

- Create a flat sequence for each VI, and add the possibily to combine them in a single sequence afterwards.

- Create a flat sequence for the first VI, add a frame after, and allow the "drag edge" action to "fagocitate" existing code (instead of pushing existing code to the right, or extending above the code if AUTO-GROVE is disabled).

Anyway, when there's a wire running beneath a structure, the possibility to "let him through the structure" (by adding tunnels) should be added as well.

View All (2)

LabVIEW Idea Exchange

Cluster Unbundle Input for Bundle primitive.

Automatically run a VI within a LabView Project when a LabView Project is opened.

Product Installer / upgrader caveat

Customize Properties and Methods Menu for XControls

Highlight a block of text (Ctrl+Shift+Arrow)

Detect Bookmark (hashtag) on Front Panel

Polymorphic + Malleable VIs

Improve default shipping quick-drop for function insert Ctrl + I

Allow subVIs to inherit colors from the calling VI or Top Level VI

Recommend "improvement" in Key Up Events

Enhance scrolling using mouse in the project explorer window (currently slow)

Project INI file ...

Add config button in build apllication for Labview.ini file

Getting rid of the RTE (Run time Engine)

OPC UA: Contradiction between help documentation and example VI, some more infomation would be good.

Keep supporting NI-CAN

Edit -> Create SubVI should respect label positions

Combine the event structure and the timed loop

Three level TDMS hiearchy

Include existing items in flat sequence