LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Malleable Classes

OK, using Malleble VIs is cool. Imaging being able to not only wrap code around a variable datatype but wrapping an object around a variable datatype.

I personally have quite a few classes which do pretty much exactly the same thing but which only differ by the precide datatype contained within its private cluster. No changes in the number of elements, no changes in methods, only the datatype of the specific data.

Obviously, the datatype would have to be compatible with all methods and VIs of the class which use that data field or we would have broken code.

View All (4)

Currently: When you "Find Missing Items" in a project, it thinks a few seconds (on a large project) and pops up a non-resizable window. You can double click on an item in the list, which closes the Missing Items list and it highlights the missing item in the project. You remove that item (or relink it) in the project, and then have to "Find Missing Items" again. Wait a few seconds, rinse, repeat...

Proposed:

1. When you double click on an item in the Missing Items list, do not close the list - leave it open, and gray out items that have been taken care of and are no longer "missing" (like the find dialog, when you delete a found item).

2. Allow the columns to be sorted by clicking on the header Name, Location in Project, or Path (this one holds a dear place in my heart)

3. Finally, allow the window to be resizable (a common request...).

(I have given the example for "Find Missing Items"... you can apply the same concepts to "Find Items with No Callers")

Message Edited by mechelecengr on 08-26-2009 02:19 PM

View All (5)

Enum Datatypes

View All (12)

I suppose this is a grey area between feature and CAR, but it is certainly a long-standing aspect of the LabVIEW editor that vexes me on a daily basis that could be improved.

The issue is that if you are dragging to select objects on the block diagram or front panel and you accidentally move the mouse cursor to the edge of the window, LabVIEW starts scrolling insanely fast in the direction of the mouse. By the time you've figured out what's happening and released the mouse, you're often 4-5 screen lenghts away the actual content of the diagram, and you must now manually scroll back to the main area. To make things worse, you're not really sure where the origin is anymore, so it takes a little blind searching to find the screen contents again. In addition, you're likely left with a selection that is not what you intended, meaning you have to start over (more carefully) from scratch.

I really don't see any reason to scroll the panel so terribly fast. At all. A slow, steady scroll, in my opinion, would always be preferable, since the fast scroll leaves the user no real control at all over what's being selected. If anyone really wants a chaotic super-fast scrolling operation to be preserved, I would perhaps accept a shift-drag option to enable this.

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

Hello all,

This is an elaboration on a prior request by RavensFan:

When AppBuilder reports a file related error, such as error 8, could someone please provide a path?

I have no idea what's causing my file IO error, as I am running LabVIEW as a local admin and there should be nothing interfering with my path.

I can't probe a path wire in the AB method because the diagrams are understandably locked.

This is so frustrating. No one likes to debug by guessing and it wastes a tremendous amount of time.

Thank you with my deepest respect to the AB team.

Jim

For example:

View All (10)

I've got some calls to low level VIs that rely on windows system dlls within a larger top level VI. To make that application work on Windows and Linux, I've put conditional disable structures around the dll calls. When I open the top level VI in Linux, I have to click through a bunch of "Find missing file" dialogs for the Windows system dlls. If I cancel through all the dialogs, the VI still compiles and runs correctly in Linux, so the Conditional Disable structures are doing most of what they should, but the dialogs are annoying and can cause problems with automated builds and other hands-off activities. Since the code is inside a conditional disable structure, it seems to me that LabVIEW has all the information in needs to know it shouldn't load that stuff, so it would be great to get rid of these nuisance dialogs.

Keep dropped snippet code selected

When dragging a snippet onto the block diagram, its code should remain selected so we can immediately drag (or use the arrow keys to move) it to a better location.

Currently, the new code is not selected and it is nearly impossible to separate it from the existing code, for example if a complicated snippet is dropped on an already complicated block diagram.

(Not everybody has a gigantic screen to resize the existing BD for plenty of whitespace. I also often only have a small strip of the BD showing, with the explorer window containing the "droppee" on top. Dragging the snippet to the BD invariable ends in a complete mess.)

View All (3)

Allow for Stacked Feedback Nodes

Encryption of VI Server traffic

By default, VI Server uses TCP to communicate between applications. This stream of data is not encrypted and open to hacking and snooping.

My suggestion is allow VI Server traffic to be encrypted, perhaps using SSL/TLS or an AES algorithm.

The reasons are obvious. There is an increasing number of cyber attacks in industrial control systems. Many cyber attacks are perpetrated internally, so a firewall or air gap is only so helpful. And in certain environments (ie military, medical) you can't even consider transmitting data without encryption. This means VI Server is not an option for many users.

I see that LV2020 now supports SSL/TLS in its TCP functions (see here), so the logical next step would be to make use of this in VI Server also.

View All (1)

View All (2)

This one is pretty basic...and I'm guessing there is a valid reason for the way it is. Still, I wanted to throw it out there.

Right now, if you make an object, the localized name defaults to <object>.lvclass. Therefore, when you put it on the front panel, create a constant on the block diagram, etc. it will be stored with the label <object>.lvclass:

My request is that the default name be changed to the name of the class, rather than the name of the class.lvclass. The size of the icon makes it pretty clear that we're using an object, making the extension unnecessary. Either way, this is something that I change every time I make a new object and I'm curious if the other lvoop users feel the same way.

Thanks

Having sold applications that use functionality from the OPC UA Toolkit we run into an issue if we upgrade our LabVIEW version and continue to develop those applications beceause the OPC UA deployment license will then stop working if we upgrade the software we have delivered to them to one developed in a newer version. So, even though the customer has an OPC UA deployment license and we have an updated developer license it is not enough because the deployment licenses have to be updated as well (and it does not help that deployment licenses are not something we can bunde with the upgrade of the software either). From what I understand new deployment licenses will not actually cost anything, they are provided by NI as long as you already had a deplyment license for the previous version - but the logistics of this is a nightmare for us. Instead of just delivering a new installer with an updated version of our software we have to get involved in upgrading the dpeloyment license for all of their systems each time we have gone to a new version of LabVIEW.

View All (4)

Hi all,

When LabVIEW prompts the user to locate a file and the file is inside an llb or lvlibp, long names of VIs are truncated in the title bar such that the user cannot easily verify which VI was prompted for. This ought to be fixed by allowing users to resize the window horizontally.

Here is an example wherein it is ambiguous which VI is being prompted for. Allowing horizontal resizing of the window would offer a straightforward fix that would help people with waning short term memory capabilities.

The relevant LabVIEW help topic unambiguously refers to this window as "File Dialog Box".

I am not referring to the File Dialog function on the palette.

Thanks as usual!

Mr. Jim

View All (7)

View All (1)

In many spectral monitoring applications such as vibration spectrum, electrical power spectrum and other frequency analysis, it is standard practice to label peaks in the FFT graphic. To do this in LabVIEW, we use cursors and cursor labels to point out specific frequency of interest. However, LabVIEW does not allow the fonts and rotation of cursor labels to be adjusted either manually or programatically.

It is common practice to use a cursor marker on the peak of the FFT frequency, with its label in a vertical orientation. Here is a common peak labeling practice used in most all vibration spectral applications:

It is painful to create work around such as programatically relocating cursors, writing text on graphs, etc. Is it possible to add at least the rotate cursor name property to LabVIEW?

Here are some other posts I have seen in the discussion forum related to this topic.

Rotate Text on Cursor

http://forums.ni.com/ni/board/message?board.id=170&message.id=242378&query.id=1281596#M242378

Move the name of the cursor

http://forums.ni.com/ni/board/message?board.id=170&message.id=45856&query.id=1282652#M45856

Change the Text Font:

http://forums.ni.com/ni/board/message?board.id=170&message.id=406465&query.id=1282652#M406465

I look forward to comments and feedback.

Preston

View All (3)

View All (5)

LabVIEW Idea Exchange

Malleable Classes

Have All Clones included in AllVIsInMemory property

A Better "Find Missing Items" and "Find Items with No Callers" in Projects

Make Trim Whitespace polymorphic and handle an array of strings

Enum Datatypes

Don't scroll so fast on Front Panel and Block Diagram when selecting objects

Remove ONLY broken wires in visible cases/sequences/structures

Application Builder File IO Errors: Reveal Which Path

Respect Conditional Disable Structures when Loading VIs

Keep dropped snippet code selected

Allow for Stacked Feedback Nodes

Encryption of VI Server traffic

VI Analyzer: Add option to "VI Documentation" to skip .ctl's

Change default localized name for objects

OPC UA deployment licenses should be version agnostic

Allow lvlibp and llb "File Dialog Box" to be resized horizontally

Get Date/Time in Seconds with Error PassThru

Case structure: easier selection for structures with a large number of cases

Rotate and format cursor labels on graphs

Add a save file method to the configuration files object.