LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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. 

 

smudged Cursor Labels Example.JPG

 

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:

Competitive Spectral Analysis Tool.JPG

 

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

 

 

 

 

When you create a class, it gets assigned a "random" color.  But there are only 6 (or so) colors that are randomly chosen from. I do a lot of LVOOP, and generate a lot of classes. But because there's such a small selection of colors, I'll often drop class methods with the same color banner next to each other (and yes, with text), and it can sometimes be a bit misleading.

 

Why not have, say, 64 colors that are used to randomly assign class colors?  Or better yet, just use a randomly generated color within a range of shades?  It's such a simple change yet it would have a meaningful impact on the developer experience (well, at least mine).

 

_carl_0-1721943387831.png_carl_0-1721943387831.png

 

Although I expect that it will take a while before this is implemented I would like to add the request so NI can start thinking about it.

 

As you might have noticed that Microsoft announced a few things on Microsoft build 2015.

 

Aside from the hololens and windows 10 for the raspberry pi they both share 1 common factor. They both run "Universal apps" (see http://www.engadget.com/2015/01/21/windows-10-makes-microsofts-dream-of-universal-apps-come-true ).

 

So it would be great if we can run LabVIEW programs as a "universal app" and run our code on all windows 10 devices..

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.

Dear LabVIEW Team,

I hope this message reaches you in high spirits and with a cup of tea in hand, because I am about to share a groundbreaking idea with you.

After years of fascinating work with LabVIEW, I would like to express my sincere admiration for the breathtaking number of windows that make your development environment so unique. While other programming environments like Visual Studio try to structure the development process in a boring way, you clearly rely on the "more is more" principle.

It is simply fascinating to see how each VI always has two independent windows. It makes me feel like I'm exploring a virtual windowscape - a journey into the unknown where each window is an adventure in itself. I can't remember the last time I had this much fun developing.

But why settle for just a few windows when we could take inefficiency to a whole new level? So I propose: Let's keep increasing the number of windows! Why not give every single structure in the code its own window? That would really be the pinnacle of chaos efficiency.

 

I imagine it like this: When I create a loop, a new window opens in which I can program the code for the loop. For each case of a case structure - another window. The possibilities are endless! An endless labyrinth of windows that turns my screen into a colorful kaleidoscope. That would be the pinnacle of innovation, wouldn't it?

I hope my ironic enthusiasm for the distinctive LabVIEW window concept has been well received. I am certainly available to discuss this idea further and am willing to contribute to the creation of an even more chaotic, but undoubtedly entertaining, development environment.

With sarcastic regards,

An enthusiastically chaotic LabVIEW developer

 


Sehr geehrtes LabVIEW-Team,

 

ich hoffe, diese Nachricht erreicht Sie in bester Laune und mit einer Tasse Tee in der Hand, denn ich stehe kurz davor, eine bahnbrechende Idee mit Ihnen zu teilen.

 

Nach Jahren der faszinierenden Arbeit mit LabVIEW, möchte ich Ihnen meine aufrichtige Bewunderung für die atemberaubende Anzahl von Fenstern aussprechen, die Ihre Entwicklungsumgebung so einzigartig machen. Während andere Programmierumgebungen wie Visual Studio auf langweilige Weise versuchen, den Entwicklungsprozess zu strukturieren, setzen Sie eindeutig auf das Prinzip "Mehr ist mehr".

 

Es ist einfach faszinierend zu sehen, wie jedes VI immer zwei unabhängige Fenster hat. Das gibt mir das Gefühl, als würde ich eine virtuelle Fensterlandschaft erkunden – eine Reise ins Ungewisse, wo jedes Fenster ein Abenteuer für sich ist. Ich kann mich nicht erinnern, wann ich das letzte Mal so viel Spaß beim Entwickeln hatte.

 

Aber warum sich mit nur ein paar Fenstern begnügen, wenn wir die Ineffizienz auf ein völlig neues Level heben könnten? Daher schlage ich vor: Lasst uns die Anzahl der Fenster weiter erhöhen! Warum nicht jeder einzelnen Struktur im Code sein eigenes Fenster zuweisen? Das wäre wirklich die Krönung der Chaos-Effizienz.

 

Ich stelle mir das so vor: Wenn ich eine Schleife erstelle, öffnet sich ein neues Fenster, in der ich den Code für die Schleife programmieren kann. Für jeden Case einer Case-Struktur – ein weiteres Fenster. Die Möglichkeiten sind endlos! Ein endloses Labyrinth von Fenstern, das meinen Bildschirm in ein kunterbuntes Kaleidoskop verwandelt. Das wäre doch der Gipfel der Innovation, oder?

 

Ich hoffe, meine ironische Begeisterung für das unverwechselbare LabVIEW-Fensterkonzept ist angekommen. Ich stehe Ihnen selbstverständlich zur Verfügung, um diese Idee weiter zu diskutieren und bin bereit, meinen Beitrag zur Erschaffung einer noch chaotischeren, aber zweifellos unterhaltsamen Entwicklungsumgebung zu leisten.

 

Mit sarkastischen Grüßen,

 

Ein begeistert chaotischer LabVIEW-Entwickler

Currently, "build path" function has input "base path" set as recommended. This can cause issue when you accidentally do not wire this input. By default there is empty path, which is not really helpful and even if there was any case when you want to wire empty path to build path function, you can easily create constant. Therefore, it would be much more user friendly to have "base path" input of "build path" function set as required by default.

I like to compare two build specifications of two different projects.

To do this it would be very helpful, that the build specification dialog box is not modal and that i can open each build spezification of each project at the same time. Resizeable would be also nice.

 

Untitled.png

Hello all,

 

I find myself constantly tweaking my wire labels so that they look like they are exactly vertically centered on the wire, rather than a couple pixels higher or lower.  They are not always created that way, and of course when you move the wire around they don't stay that way like I wish they would.

 

I'd like to propose an option to have LabVIEW automatically force wire labels to stay vertically centered on the wire (similar to other "snap-to" label positionings).  I know that other programmers prefer other positions, such as immediately above the wire, therefore having it snap to that position would be another option.  I'm not sure if it makes more sense to select one position that it always snaps to, or have it snap to one of a few options (like labels on controls do now).  I always use them consistently in the one vertical position, myself.

 

It may make sense to have the default be free-positioning as it stands today, but it would save me a non-trivial amount of time to have the option for it to be always enforced to what I think looks nice.  Smiley Happy  Hopefully I'm not the only one!

 

Obligatory pictures:

 

Initial vertical position when I select to make the wire label visible (looks terrible!):

Initial position.PNG

 

The vertical position I always want it to stay in:

Centered position.PNG

 

An alternative snap-to vertical position:

Above wire.PNG

Currently, the configuration file object only has access to save a file when you close the object.  I'd like to be able to save the file at any point in time and keep the object open.

 

 

 

Interfaces are a great improvement in LabVIEW OOP. For me steepest learning curve was in figuring out how to implement default behavior when interface class doesn't have a private data control.
For example I have created Collectable interface (inspired by iterable interface found in other languages). It has default implementation for methods like Next and Add. It has accessors methods like Read and Write Items, which descendants must override.
When I create a new class which inherits from my Collectable interface, I need to override those accessors, and manually add required controls to new class private data control, and unbundle/bundle elements, and wire the controls and indicators.

data accessorsdata accessors

My idea is that there should be a tool to do automate this code generation.

 

I think the straight forward way would be to use scripting and project providers to create something similar to Actor Framework Create message etc. tools. 
But a more fundamental change would be to implement this as part of property definition folders and property nodes. Which I think in this case should be in protected scope by default.

property nodesproperty nodes

The Collectable interface can be found from lavag.org 

Much like the ever-popular With with Errors, "Get Date/Time in Seconds" would be great with error clusters for inputs/outputs.  This would help with coordinating timing (start/stop and duration).

 

Here would be an example of what the underlying code is that I currently use:

 

GetDateTimeInSecondsWithErrors.png

 

Pretty simple...  and an example of what the use could look like:

 

GetDateTimeInSecondsWithErrors_Icon.png

 

And a duration example:

 

GetDateTimeInSecondsWithErrors_Example.png

As touch screens are becoming very popular and limitation of using keyboards in the production sites, the OSK is becoming very popular requirement and in LabVIEW applications.

Add OSK as an in-built property to String and Numeric controller. Based on control type open the numeric only or full keyboard.

 

AdarshaPakala_0-1620737397931.pngAdarshaPakala_0-1620737397931.png

 

 

The property can be set manually or programmatically.

Access to source code of OSK to customize the keyboard.

Multilingual keyboard option.

 

 

Thank you

Adarsh

CLA from 2014

I'd like to see the 3rd mouse button (scroll wheel button) activate the scroll window tool and allow me to move the window while held down.

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:

object.lvclass.jpg

 

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

When you create a library, its banner (the strip on the top of the icon) is 12 pixels high. This is pretty useless. NI is taking 10% of the icon's height (3 pixels) more than is needed to have a line of text using the default font in the editor. These 3 pixels can be very useful for the rest of the icon, which is what actually shows which specific VI you're dealing with.

 

I suggest that this be changed to be 9 pixels high, as shown on the right side:

 

Banners.PNG

I wish to have the option to pin the (relative datatype) pallette opened thro' short-cut menu, like inthe attached snapshot.

 

The use-case I feel is, most of the times when I want/need to navigate to the related datatype pallette in search of something, suddenly I find that I need more than one function to be used in my next steps of coding. So during those times, pinning is a viable & useful option.

 

Hope some of the folks would agree with me... Smiley Happy

Download All

When the Grid is on it is difficult to see Boolean wired due to their 'dotted' appearance.

 

Change the Boolean wire from a dotted green line to a solid green line to improve visibility

 

LabVIEW wires.JPG

Ken

 

 

 

 

Formula Node output variable names should be shifted right 1 pixel within their borders. Currently, the names are left-justified. Since each character is also left-justified (i.e. the white-space to separate them from adjacent text is on the right of each), input variable names have a 0-pixel left margin and 3-pixel right margin within their 1-pixel border. Since the output variable two-pixel borders grow inward to match the outer dimensions of input variables, the text pixel is cropped with excess on the right. This is problematic for the 1-pixel wide lower-case letter L which is cropped in half by the left border but still has a 2-pixel right margin. If shifted, names would be centered, cropping would not be as apparent, and the letter L would be distinct. The image below is enlarged 200% so the issue is more obvious (but the name is easier to read).

 

formnode.bmpformnode.bmp

Hi all,

 

Since the release of the new “Silver” control style in LabVIEW 2011, I had the idea of having a style control on the front panel. You would essentially click the drop down box and it would change all/selected controls and indicators on the front panel to that style.

 

Take a look at the mock up below.

 

Untitled.jpg

 

 

The idea could be extended to having a style of control that the User could populate, notice the “User” on the drop down.

 

I hope that you like my suggestion I can certainly see many uses for this.

Right now, you can add one group by which to filter the files you can select in a file dialog (e.g. when clicking the button next to a path control). You  can add extensions by opening the "Browse options" and adding the extensions. You can separate the extensions by semikolon to filter by multiple extensions. However, you cannot add multiple groups.

Here's how it looks now:

 

File Dialog now.png

 

In this setting you get to see all *.txt, *.doc and *.pdf files at once.

 

But what if you want more than one group to filter?

 

You could use .Net to call a standard windows File dialog. This dialog supports multiple groups separated by |

So, you can achieve something like this:

File Dialog.png

 

This feature should be available for the standard path control in LabVIEW, too.