LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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.

If You drag a tunnel of a loop, case structure or any other structure along the border over a corner, then

the connected wire becomes hidden behind the frame.

Sometimes, the wire looks alike it is connected to another wire instead - like in the example below.

I fell into that trap, because I've just seen the frame to the right and didn't expect, that the wire was

connected to the tunnel near the bottom.

Wouldn't it be great to break up the wire with a 90° corner and place it in the visible area?

More similar situations like this are posted in this thread:

http://forums.ni.com/t5/LabVIEW/wire-vanishes-behind-frame-of-case-structure/td-p/3221167

I decided to dive into the world of custom error rings, andit is a clean way to implement customized errors throughout a project.

That being said, forcing the custom error file to be in the user.lib folder makes this feature quite a bit less useful for me. I am working on a project with source code control and multiple developers. Since the custom error code file is in user.lib, it is not in my source code repository, and is awkward to share between developers.

I propose that custom error codes should be a project level feature. 99% of the error codes I want to add are specific to a certain project, so I don't need them in other projects, however I do want them to distribute with my project. I understand how to distribute this with my built application, but during development it is not as easy to share.

I am proposing that the error code text editor should be in the Project menu, and the error code file should not be required to be in user.lib (allowing it to be stored in a repository and shared among developers easily).

View All (1)

"New -> Child Class" menu item

I've been using block diagram cleanup extensively over the past year in an attempt to speed up my LabVIEW programming. I am definitely faster as a result of using the feature, but there are still some VIs that I have to arrange myself, because diagram cleanup's arrangement is unacceptable. So the feature still has a ways to go in making all my diagrams acceptably clean. It's my understanding that there are many more configuration options in diagram cleanup that could potentially be exposed to the user, but I think an easier way to conform diagram cleanup to my standards would be to point it at a folder of VIs that I have personally deemed "clean", and have diagram cleanup mimic the arrangement in those VIs when cleaning up other VIs.

As an example, I am ok with input tunnels into a case structure overlapping somewhat, if those tunnels are coming straight from subVI output terminals that are close together. Diagram cleanup insists on adding space between the tunnels so that they don't overlap, which results in unnecessarily crooked wires. Ideally, I would have VIs in my "clean" folder that have slightly overlapping tunnels, diagram cleanup would discover that I'm ok with this, and subsequent cleanups would allow this arrangement.

View All (3)

View All (6)

LVCompare for Classes and Libraries

View All (3)

Often when using tables (and multicolumn listboxes), the content of the table column or row header is longer than the desired width of the cell. It would be nice if there was an option to make the contents of the cell wrap to the next line, similar to how tables work in Excel or Word.

Also, adding vertical justification options such as Top, Center, Bottom to the Active Cell property subset would be nice.

Here's a crude illustration of what I'm talking about.

View All (1)

This is a small thing but it drives me nuts. Whenever I place a case on the diagram, I always need to move the case seletor up or down so it aligns with the source output that will be driving the case. But, the newly placed case always has the seletor right in the middle of the left side. This is also where the drag hover control (?) is located. I seem to at least 50% of the time grab this drag control when I want to grab the case seletor and move it. If the selector was just placed above or below the middle of the left side, this issue would go away. I suggest placing it 1/4 of the way from the top, since most of the time the source of the selector is above the midpoint of the case block (at least in my code). YMMV.

I know it is a nit, but it is low hanging fruit to fix and it is annoying.

View All (4)

Dealing with fonts in LabVIEW can be a nightmare due to the variations in fonts, types of fonts, rendering variations, resizing, etc. If you are deploying a LabVIEW application on another machine, frequently the fonts or settings on the target machine don't match; creating a very ugly looking panel.

When developing for Windows in the past I have always edited my LabVIEW.ini file to include the following:

appFont="MS Sans Serif" 13
dialogFont="MS Sans Serif" 13
systemFont="MS Sans Serif" 13

And when deploying an application; I include these in the app's ini file also.

This seems to work for most windows targets since MS Sans Serif appears to be a common font. I suspect this will produce unpredictable results in OSX or Vista for that matter.

What I expect as a developer is not having to deal with these font issues. I expect that when I develop an application that it has the same look and functionality; regardless of where it is deployed; even as a VI being edited on another machine with different font settings. This means that the font information must be encoded and stored with the VI itself. I would expect that both the LabVIEW editor and run-time engine would be able to recognize detailed font encoding within the VI and adjust the display accordingly based on the local machines font capabilities. This is what one expects when printing or viewing an Adobe Acrobat PDF file; and the behavior of LabVIEW code; particularly since it is so graphical in nature; should also be similar. I wouldn't expect that the actual font bitmaps be stored within the VI itself; but some detailed metrics about the font should be; height, width, kerning, etc. Thus if a font substitution takes place when being deployed on another machine; at least the text will occupy the exact same extents as the original.

Though I don't know exactly what the detailed implementation would be; it does need to be transparent to the LabVIEW programmer, i.e. zero code; zero hassle; zero worries. It should just work. I hope we can all agree on this.

View All (5)

We're all familiar with how fast programming in LabVIEW can be when using the right click menu to quickly access the associated palettes of the function we've right clicked over. Below, we can see that right clicking on the DAQmx Create Virtual Channels VI gives us direct access to the DAQmx - Data Acquisition palette. This is a lot faster than manually navigating to the Functions Palette to get the same result.

However, nothing similar exists for when programming in LabVIEW Object Oriented Programming (LVOOP). Development for LVOOP programmers would speed up dramatically if they didn't have to switch back and forth between their VI and the project window when making use of VIs from their class library.

The idea is shown below. On the left, we have the current Right Click context menu available in LabVIEW. On the right, the suggestion; the programmer is able to search through all of the VIs that are accessible to the class without having to scroll through the Project Window.

View All (4)

A couple of recent ideas regarding the VI Hierarchy window are good, but do not go far enough, in my opinion. I would like to see the VI Hierarchy window annotated with a lot more status information about VIs, including:

A glyph showing if Execution Highlighting is enabled
A run arrow on any VI that is running top level.
A path from the top level VI through any currently executing subVIs (the path may be forking as there may be multiple subVIs running in parallel)
That path would have temporary lines going to VIs that are invoked using the Call By Reference node (as opposed to reordering the hierarchy tree to put such VIs as subVIs of the caller)
A glyph showing any VIs that have breakpoints on them and a different glyph if the VI is actually stopped at a breakpoint.
Reentrant clones of VIs, so that call chains can actually be seen, including the ability to double click on a particular reentrant clone to open its front panel
Any other execution state information that can be easily expressed as glyphs and highlighted connections among VIs and/or other file types shown in the hierarchy window (open to brainstorming).
Whether debugging is enabled or disabled on each VI

The VI Hierarchy window has already been updated in LV 2009 and 2010 to show all the connections among different files and resources. Finishing it out to show the full state of the system would make it a powerful debugging tool.

View All (4)

We I love the idea of the new cluster constants. I have found thought if I need to edit these constants to change something It opens the control back to full size. This really defeats the purpose of these space saving features. We need to be able to double click these constants and have them open in a new window so that my block diagram size does not change

If my diagram gets this big if I need to change a true or false state every time I need to change it what good is the nice new icon or constant.

Just a thought.

View All (1)

I would like to remove all broken wires that are currently visible, and not ones hidden in other cases.

I want to be able to select a case, review the broken wires, and mass delete (if applicable). Then select the next case for review.

I never use ctrl-B when working on a large application. I want to review all broken wires before deleting.. but I hate trying to double or triple-click each wire.

Something similar to this post: broken wires ...which notes that it can be accomplished with Quick Drop scripting...

LabVIEW Idea Exchange

View String Constant as Icon

XNet Virtual Hardware / Ports

Avoid hidden wires when a tunnel is dragged to another border

Make custom error code files part of a project

Allow replace of multiple controls in one operation

"New -> Child Class" menu item

Tell Block Diagram Cleanup What "Clean" VIs Look Like

Function to Count Number of Items in Enum

LVCompare for Classes and Libraries

Automatically disable autoscale when the user changes min/max values of a graph

Additional formatting for tables and multicolumn listboxes

Place case selector anywhere other than the middle of the left case border

Getting Started window should try to Find My Files

Fix font behavior between windows versions, platforms & executables

Add right-click option to delete class mutation history

Quick Access to a LVOOP Class Library via the Right Click Menu

A VI Hierarchy window that shows full state of VIs in memory

Need Edit Window for New Cluster Constants

Make Trim Whitespace polymorphic and handle an array of strings

Remove ONLY broken wires in visible cases/sequences/structures