LabVIEW Idea Exchange

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

Hello,

 

I propose a new floating/Dockable Text formatting tool for editing the FP controls/Indicators as shown below.

 

untitled.GIF

 

 Presently it takes multiple iteration to make a control Label to justify, bold,change the color , change the font etc.

 

This new floating bar can have the following features like

 

->Select font

->Text color

->Text Size

->Alignment/Justify

-> Bold, italic,underline

->etc etc

 

 

Also this floating bar can be put as part of the existing tools window here (circled in RED)

 

1.GIF

 

or as a replacement for the "Application font" selection ring

untitled.GIF

 

 

Regards

Guru

The LabVIEW Task Manager is an outstanding tool for debugging LabVIEW Applications. It should be included in LabVIEW in my opinion.

 

a345fe65cbe713b29f505a851e0fe597.PNG

Let's assume the following two classes. Prop 1 is of type Class 2.lvclass. Both data members have their corresponding property accesors created.

 

Class1     Class2

 

 

I suggest simplifying the access to the nested class properties using dot convention similar to cluster elements. Like this

 

Read

 

 

 

 

 

 

 

 

 

Write

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

While LabVIEW supports units (partly), the lack of ability to display them nicely in the Unit Label can make for ugly front panels where they're used.  A couple of small changes that would improve things would be:

  • to render "^2" as "²" and "^3" as "³" (that covers probably 99% of unit exponents used)
  • to render "u" as "µ"

The Unit Editor doesn't need to change, nor the way units are typed in, but these changes could then be automatically applied.  All three characters exist in most fonts.

 

Let's be honest: The easiest way to make a large VI unreadable is to click on the “Clean Up Diagram” button (if you're smiling, that proves I'm right). My suggestion would be to give this button some artificial intelligence. Maybe give the customer the option of setting what is “good” and what is “bad” design. And if you like the challenge, let them train it themselves.

Hi.

 

SubVIs are sometimes easily missed in a block diagram when you glance over it, and their current configuration is impossible to determine unless you open up each subVI and examine its VI Properties. I suggest a quick way to highlight and configure subVIs within a BD. Consider this section of code:

 

SubVI_Clean.png

 

Then one could hold down the ALT-key (or some other easily accessible interface) to get this view, which gives you an interactive highlight glyph overlay on top of each visible subVI. Letting go of the ALT-key returns your BD to normal of course:

 

SubVI_Alt.png

 

The interactive highlight glyph gives you direct access to this for each subVI:

 

- It highlights where in the BD there is a subVI.

- It shows if the subVI has unsaved changes.

- It shows the runtime priority of each subVI (more on that later).

- It shows the reentrancy mode of the subVI (as well as inlined/subroutine state).

- It highlights any unwired required inputs of that subVI.

- It shows if the subVI has debugging enabled (which can have a negative impact on performance).

- It illustrates if the subVI is otherwise configured for optimum performance (more on that later).

 

More on the subVI highlight glyph:

 

 

SubVI_Highlight_Details.png

 

I imagine tooltips might pop up containing additional info if you hover the mouse pointer over the elements in the glyph. I think clicking the "unsaved changes" asterisk should save the subVI with all the bells-and-whistles as if you opened it and did CTRL+S on it. I think clicking the "Debugging enabled?" element should toggle the Allow debugging property of the subVI directly. I think clicking on the colored frame should open the reentrancy setup dialog of the subVI. The colored icon frame is part of many LabVIEW style guides for icons btw, but not everybody is familiar with them, and thus don't use icon frame colors like this. Also such colors might clash with other style guides - class icon templates for instances, or company logo colors. That is why I propose the reentrancy setting being part of this subVI highlight glyph.

 

More on subVI priority:

 

I have earlier proposed a much simpler way of defining subVI priority with a number, which is along the lines of how it's defined in a timed structure, instead of the current way of setting Priority and Preferred Execution System in VI Properties (which many people find hard to figure out and keep mixing it with timed structures). That idea can be found here. This priority number is what I propose is located on the subVI highlight glyph. Clicking on this element in the glyph should open the subVI's Priority setup dialog directly.

 

More on the "optimum performance" element:

 

I haven't really thought deeply about this element, but I see it as an indicator of if "all the rest" about the subVI is optimized for best performance and least runtime pitfalls. Stuff like making sure Enable automatic error handling and Auto handle menus at launch are disabled. Anything outside of the optimum will light this indicator. Clicking on it should open the subVI's VI Properties dialog or similar.

 

What do you think?

 

Cheers,

Steen

I tried searching for a similar suggestion but couldn't find one but I would bet that this has been suggested several times.

Why is the routing to multiple adjacent array terminals (or similar) so terrible ? The top Build Array shows the standard routing chosen by LV when wiring from a group of refs starting at the top. Starting from the bottom isn't any better. The lower Build Array is what I always change it to !!  Why is this not the standard routing ? 

I'm sure all of you VI meisters with OCD can sympathise.Smiley Wink

 

Wire routing.JPG

Hi all,
For a lot of reasons, I have to work with several LabVIEW versions.

My biggest fear is to save something in a later version : projects are quite big, and a save for previous version is hard when using terce parts (such as OpenG, JKI, etc.)

My whish would be to have a warning message when I save a vi in a new version, such as :

"You are saving a 8.2 file in 11.0 : do you want to continue ?"

 

 

Have a nice day !

For pilot plants, we make P&ID's, the plant's interface (not PID) with decorations.

 

Now it would be nice to have more then two widths. But the real pain starts when we need to draw tracing. The standard for this is a dashed line. There is no way to put a dashed line on the frond panel! Amazing, since we're using a graphical language!

 

Now I have to make a line in powerpoint, but it can't be resized. Or use a picture control, but that adds code and complexity. Or put 200 tiny solid lines evenly spaced on a line.

 

This is all I'm asking for (inthis post anyway):

Right click.jpg

Line endings would be niced too. Arrow, dot, etc. Like line endings in office.

 

Put a scrollbar in the case strucutre case list instead of up and down arrows. With a long list the arrows are to slow fro my taste. Making then faster would probably sove it for me but anoy someone else.

 

 

case scrollbar.png

The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.

 

PrimaryKey_0-1573820513072.png

For community solution and examples of these features please go to -> https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Tree-Map/td-p/3972244

 

This could include also Pretty JSON since XML and JSON are interchangeable -> http://www.utilities-online.info/xmltojson/#.Xc6XjVdKiUk

 

Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.

 

Hi,

 

Currently I didn't see any option where I can just select particular control or indicator and convert it from one type to other.

Example: I have one classic control and want to convert it to other modern or System control type.

It will be great if I am able to do that just on right click.

As per my knowledge currently we need to replace contlol which I selected to other type for converting it. It takes lots of time if I need to do this for multiple controls or indicators.

 Any thoughts on this?

As mentioned here, "Event Sources can be time consuming in finding when you have lots of FP objects."  I'd like a FP node Right Click menu option on terminal (or on the node itself) to Find Event Case if it is applicable. (Event Structure must exist)".

Aesthetic issue: thick wires connected to Select inputs show as ugly corners behind the triangle icon, probably a result of the underlying connector pattern.This does not happen for other triangular blocks, at least not up to a reasonable wire thickness (to make a wire thicker, just make a N-dim array of something).

corners.png

There is a missing property that it will be very useful to have to access the menu reference.

 

Old way:

RuntimeMenuLoad_old.png

New way:

RuntimeMenuLoad_New.png

This way it's more clean and we can open a reference to the menu from another VI

 

Dany

There is something wrong with this VI, although you wouldn't know it unless you ran it (and I should warn you that it will annoy you if you run it):

 

AnnoyingVI.png

 

 

What's wrong with it is that auto grow has been disabled and there's some annoying code hidden there beyond the loop boundary. This is one of my least favorite things about LV - it allows us to hide code completely and get away with it. I don't think it should.

 

LV already has auto grow enabled by default to handle some of the cases which cause this issue, but I know that many many people don't like it when LV automatically plays with their BD layout (and rightly so) and auto grow only covers some of the cases, so I think we need something more encompassing and less obtrusive, and I would suggest breaking the VI if it has hidden code.

 

I also know that LV has warnings and VI Analyzer has tests for this, but I think this needs to be something which doesn't let you get away with it.

 

I think LV should break any VI which has any of the following:

 

  • Objects beyond the visible boundaries of structures (including wires and constants).
  • Objects behind other objects (possibly not including wires).
  • Overlapping tunnels on structures (or maybe just not allow them to overlap at all)?
  • Anything else?

Hello (again),

 

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

 

CrossedOutLoops.png

 

Instead I propose the Loop Structure which when initially drawn looks like this:

 

NewLoop_Infinite.png

 

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient Smiley Happy. One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

 

NewLoop_While.png

 

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

 

NewLoop_Unknown.png

 

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

 

NewLoop_42.png

 

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

 

NewLoop_50.png

 

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

 

NewLoop_42_Conditional.png

 

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

 

NewLoop_MultipleArrays.png

 

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

 

NewLoop_Timed.png

 

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

 

NewLoop_Events.png

 

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

 

NewLoop_PriorityStructure.png

 

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all? Smiley Very Happy

 

Cheers,

Steen

Hi,

 

I just thought of a small thing when I enabled the Dynamic Event Terminals on an event structure for the zillionth time - why don't they just appear automatically when I wire a compatible wire to the structure border? Like this:

 

DynTermPopup_1.png

 

DynTermPopup_2.png

 

DynTermPopup_3.png

 

Of course once in a while you don't want to wire to the Dynamic Event Terminal, but instead want that wire to tunnel through the structure border, but a dab on the CTRL or ESC key could make the Dynamic Event Terminal "suggestion" disappear.

 

Cheers,

Steen

Currently you can only set symbols of a Multicolumn listbox on the first column.  I think it would be pretty handy to put symbols in any cell on the MCLB.

 

MCL Symbols.PNG