LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

My request is for NI to review and develop the ability to select where (IP specifically) a NSV will deploy on a system (eg. PC) containing multiple networks.

After searching through various forums and issues, I understand that currently we can only choose LabView software's global default adapter via unusual Windows methods. What if other projects do need to use the primary NIC ? or what if in one project I need some NSV to go to primary NIC and some to use the secondary NIC ? As various hacks and workarounds did not fulfill my requirements I opened a request for technical support. After review, the case (#03609821) concluded that this was not possible and suggested I post here to see if others also would find this useful to boost development priority.

My example scenario is this. My company develops specialized motion products (mainly automotive transmissions for heavy duty and defense applications). We primarily use NI in our dyno and own a few NI hardware systems: cRIO, cDAQ, PXI.

I work in the dyno room here and am trying to set up a cRIO as a datalogger and RT OS to primarily measure analog and CANbus signals and thereby control testing.

The test fixture is operated on a PC with two network cards. One private LAN to talk to the cRIO to stream data and control. The network shared variables keep track of various statuses. The other network card is on the company LAN primarily so we can transfer data and share fixture status. The secondary purpose of being on the company LAN is that we have 6 configurable dyno motors (usually used in pairs) in the room that run on a shared master controller (non-NI). Currently that is done via PC RS232 to the cRIO, but we’re planning eventually to transition that to a more open ethernet architecture. NSVs would be ideal for sharing each dynos’ status as the serial is limited in 1-1 connection and bandwidth.

View All (2)

View All (4)

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

But...if it's a class override method, I can't do this:

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up. This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

If you copy a group of controls/indicators from a front panel to another, the layout of their terminals on the block diagram is not maintained (instead it is typically messy...)

Vice versa: If you copy terminals from a block diagram to block diagram the block diagram remains the same, but the control layout is messed up.

Why not just keep both as they were when copying?

[video]

Bonus-idea: If you try to fix this by using the diagram clean-up function controls with the same name, but an iterative suffix (which the IDE is able to automatically generate itself as well, so it has a relation to it alread) the clean-up ignores the order of the names when ordering the controls...(so it might stack them nicely, but then control ...<n+1> is not put after/below ...<n> e.g. Perhaps it could be a bit more intelligent and include that in the ordering algorithm too?

(Inspired by this discussion)

The Index & Bundle Cluster Array function currently discards any labels of the input data. I think it would be more useful if it would try to retain the names (i.e. copy the original array labels (if available) to the element labels of the output).

The picture illustrates the idea. On the left we see the current behavior and on the right what we would get after this idea is implemented.

In the old days the digital display was automatically aligned with the plot legend (if I remember well). Now it is by default not.

It takes some manual alignment actions to get them right. But don't resize your chart!! You can start all over again.

I propose the option to align the digital display as shown in the last picture.

(BTW, looking for duplicates I found one comment in http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Assembly-of-the-graph-s-plots/idc-p/1085440)

This is a really basic thing, but it would be helpful if the qualified name (as seen in VI Properties) was enabled so it could be copy and pasted into documentation.

When I'm writing detailed documentation to tell other developers how the software works I often use the qualified name as opposed to VI name. For example "Send Creep Command.vi" doesn't tell the developer where to find it, but "Motion Control UI.lvlib:Motion Card 2 Data.lvclass:Send Creep Command.vi" does.

I would be happy with the string being enabled (so it can be selected and copied), or a button that copies the string into clipboard.

View All (1)

Many common functions include a "found" or "exists" output. Examples include:

Get Variant Attribute
Element of Set?
Config file VIs (Read Key, Write Key, Get Key Names, etc)
Chek if File or Folder Exists

Why then does Look In Map provide an inverted ("not found") output? Wouldn't it be better if it was consistent with other similar functions??

This is most frustrating when replacing existing code using variant attribute lookups with equivalent maps. "Look In Map" is pin compatible with "Get Variant Attribute" except for that one inverted output! This has caught me out on more than one occasion...

View All (1)

Editing the Font Styles and Size of a text, can't it be Simpler? rather than a lot of mouse clicks each time??

Many had suggested the use of Key board shortcuts, but it may be used for some other things. But Why shouldnt we use a dialogue box instead?

The problem is lot of mouse clicks to go to Dialogue font, Styles/size and then to the respective selection like,

The Key board shortcuts are being used for other functions., But Why shouldnt we have solution like this??

I am not sure whether it can be done or someone already suggested., but i didnt come accross anything like this when i searched for.

Thank You..

View All (3)

Showing Mouse Coordinates on FP

Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.

As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.

So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)

I was thinking about two methods (see attached)

1. Show coordinates along with the mouse

2. Show coordinates at the bottom of the pane

Thanks,

View All (1)

Add Target to VI Analyzer (API)

View All (5)

Currently (in LabVIEW 2010), you can add labels to wires. Hurray!!

But it's painful. Boooo!

Curently => Right-Click wire, navigate to sub-menu of Show>>Label

It should be as easy as adding free text to block diagrams or front panels. For example: If your auto-tool is on then just double-click on freespace to add text.

So we should make it just as easy to add labels to wires:

Step 1: Single-Select Wire
Step 2: Start Typing
Step 3: Profits!

We don't need no stinkin' right-click menus.

PS: I am proposing a single click on the wire instead of double-click because that performs a different action.

View All (1)

(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)

I've got some code on my diagram:

I need to wrap the code in a case structure, so I do:

Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.

There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:

If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:

(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)

If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.

With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.

I have wasted ~~days~~ weeks of my life tracking down why dependencies are loaded in LabVIEW.

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

Let's Encrypt support for NI web server

View All (2)

Classes? OOP? ... Huh?

Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!

The problem:

Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.

Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:

Opening the "class properties" window takes 10 seconds or more
Renaming a class brings the editor to a standstill

For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!

Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.

The idea:

Improve the responsiveness of the LV editor when working with classes.

Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
Modifying inheritance is a fundamental operation. It should be quick and easy! (See this related idea)
Placing classes in libraries promotes good project organisation. It should *not* bring the editor to a grinding halt!

Credits:

Others have written about this topic well before me. Here are a few relevant discussions:

Feel free to link more!

View All (7)

Immutable Boolean constants

I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

View All (2)

LabVIEW Idea Exchange

MultiCard Network Shared Variables

Allow vertical Case and Event selector lists.

Drill-down debug capabilities for class overrides

Expanding a block diagram should only affect the case that is shown

Keep block diagram layout when copying between front panels and vice versa

Index & Bundle Cluster array should retain element names

Digital display locked to chart legend (as an option)

Enable Qualified Name in VI Properties or add copy button

Output of "Look In Map" should NOT be inverted

Editing the Font Styles and Size of a text, can't it be Simpler? rather than a lot of mouse clicks each time??

On auto-generated class palette, properly scope available VIs

Showing Mouse Coordinates on FP

Add Target to VI Analyzer (API)

Make adding label wires super easy (Step 1: Select Wire, Step 2: Start Typing, Step 3: Profits!)

Overrides of interface methods that have error in/out terminals should wire the error by default

Optional (and easily-dismissable) prompt to change newly-dropped case structure frame to FALSE

"Why is this item in Dependencies" should only show items that are directly dependent on it

Let's Encrypt support for NI web server

Improve IDE performance when working with lots of classes

Immutable Boolean constants