LabVIEW Idea Exchange

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

Hi all,

 

What I'm asking for is an optional indication of reentrancy in the context help window.

 

contextHelpReentrancyIndicator.png

 

 

This would save the user from having to open VI Properties on several VIs, and would be particularly useful when viewing the VI hierarchy.

 

 

I realize that Greg Freeman suggested something similar.  My intent here is to narrow down several ideas from that conversation down to a single suggestion.


(I hope I still didn't manage to post a duplicate. Apologies if I did.)

 

Thanks,

 

Jim

The idea is quite simple to implement, I suppose.

 

Dimensions-tipstrip.png

 

 

 

 

 

 

Two main benefits:

 

1. allows you to know the exact size in pixels that the front panel will get at runtime, while the manual resizing of the FP occurs.
This feature should take in account VI's Windows Appearance options (Window has title bar, Show toolbar when running, ... etc). It helps you to set the FP size for the (different) screen on wich the program has to be run.

2. this feature can help you to set the BD size for the smaller screen on wich you know you'll have to edit the program.

Up to now you can only set a minimum FP size, and use it as a sort of "pixel size reference". However this is the internal net size of the panel, toolbars and title bar excluded, and the final setting is a bit tricky. You can also programmatically change the FP size, but this is of little use, if you don't want to risk that some control disappear out of the panel boundary.


The second benefit is only for those of you that use LV on different PC (Lab and laptop, for instance) like me...  and, like me, hate having to scroll the BD for editing it :-). Usually I set the BD size to the maximum possible dimensions of the smallest screen I use.

 

 

Cheers

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

 

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

 

DataForcing.png

 

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

 

ForcingImplementation.png

 

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

 

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

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,

Problem.png

 

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

 

remedy.png

 

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

When debugging (and at many other times), I want to copy data from a probe or control into a text file, Excel, whatever.

 

For reasons that I am totally unable to fathom, it copies the control as a bitmap. Print screen provides this functionality already. I think copy data should copy text instead!

 

copy_data.png

 

I wasn't able to find this on the exchange, sorry if I missed it!

Problem Statement

I often find myself debugging code that seems to have "hangged" and I want to find out which VI is causing the "hang" (maybe it's waiting on some event/queue/message/timeout or maybe it's stuck in an infinite/long loop).  There's no really easy way to figure out which subVI (or perhaps a node) is not returning from its call.

 

My Work-Around

The way that I currently do this is to start opening up VIs and looking at their "Run Arrows" (the run buttons on the VI toolbar) to see which subVIs are currently "running" (being called).

 

Running (Top-Level VI)

 

Running Top Level.png

 

Running (Sub-VI of a Running Top-Level VI)

 

Running Top Level.png  << This is what I look for


Not Running (Sub-VI of a Running Top-Level VI)

 

Not Currently Being Called.png

 

This technique works OK, but it takes a lot of time to track down the running VI (in applications where there are LOTS of VIs), since you have to just start opening up all your VIs a looking at their run arrows.

 

Question: Is there any way to look at the run state of a VI using VI Server or Scripting?  Unfortunately, the VI Execution.State property is "Running" for all three states shown/illustrated above (the "Idle" state is for VIs that are not reserved for execution, meaning they are not in the hierarchy of a running top-level VI).  Maybe I'd also add to my feature request that it would be nice if there were a way to interrogate this state using VI Server or Scripting.

 

Possible Solution(s)

What would be nicer is if I could ask LabVIEW to Find all Running SubVIs/Nodes and visualize them by their VI Hierarchy.  Maybe we could have an option to show the run state in the VI Hierarchy window.  And, maybe there could be a way to only show running VIs (hide all Not Running / Idle VIs).

 

VI Hierarchy.png

 

Now, I realize that the VI hierarchy window doesn't have any way to visualize multiple subVI "instances" of a VI, but maybe that could be an option as well (Show all SubVI instances.  Also, it would be cool if we could show "Clone" instances of reentrant VIs... but, I digress.

 

Also, the VI hierarchy window only shows VIs, it doesn't show nodes/functions that might be running (and what's causing my code to "hang").  It might be nice if we could also include nodes, at least for the purpose of helping me find out which nodes are running.

 

So, I'll end by just stating that I need some easier way to figure out why my application appears to have hung and I hope that this "Idea" leads to more discussion and maybe some more features in LabVIEW to help me debug and visualize my applications.

 

Do you have any ideas for how to better debug applications that appear to have hung?  Do you have ideas for new LabVIEW features that could help?

 

Thanks!

We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).

 

Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.

 

This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.

 

These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.

 

Coercion.png

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!

hierarchy.png

 

Credits:

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

Feel free to link more! Smiley Happy

The VI documentation window could use some improvement and several additions could be made to make editing the text a lot easier.

 

6-4-2010 2-31-40 PM.png

 

Improving adding control and indicator name.

 

Typically the text in the documentation window does refer to the control and indicator connected to the connetor pane.

It would be very convenient to have this information already in that window so we don't have look it up when needed. Additionally, the control and indicators are typically bolded in the resulting text using the <b></b> tag. It would be convenient if this would be done automatically for us.

In the propose idea (see image below) the VI icon with the controls and indicators is shown and the controls and indicators when clicked do insert their name into the VI description. 

 

Note: The control name may be made to look like an hyperlink to indicate that there are click able.

 

For example, in the image below, clicking the "Items to filter" will insert the "<b>Items to filter</b> tagged text in the VI description.

 

6-4-2010 2-16-46 PM.png

 

Improve general text editing

 

While fancy text editing is limited in the VI description, adding a toolbar to improve text formatting would be useful.

 

6-4-2010 2-31-40 PM.png

 

 

Cluster Size as a Wired Input:

 

  • Easier to see
  • More implicit
  • Nearly impossible to forget to set it (if it were a required input).

 Cluster Size.gif

It has come up here in a different discussion, but I think it should be a separate idea, so here it is!

 

If we disable part of the code using the diagram disable structure, the disabled code gets lighter in color. The new compiler is good at eliminating dead code (i.e. things that don't need to be computed because there is no output), so it could be useful if these code parts are also bleached in a similar way to indicate that fact.

 

Here's how it could look like.

 

I would even suggest this to be enabled by default. Of course there also needs to be an option to turn it off....

 

(I was about to write up this idea, but then, searching for "dead code", I found comment by SynchronizationOverhead. So the original credit goes there, of course ;))

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)

 mouse coordinates FP.png

 

1. Show coordinates along with the mouse

2. Show coordinates at the bottom of the pane

 

Thanks,

 

 

 

Current it is very hard to reliably manipulate decorations using VI server.

 

LabVIEW need to be able to create explicit decoration references (like it is possible to do on other objects through right click Create>>Reference).

 

Decoration Explicit Reference.png

 

Note: Thanks to TonP for the idea.

The function Index & Bundle Cluster Array can be quite useful and mimics a bundle in a for loop.

 

The reverse operation (= unbundle in a for loop!) would be equally useful.

 I wonder why it is not part of LabVIEW. Seems like an omission. 😉

 

I suggest to add it with the same icon graphics, but with left and right halves swapped.

 

(See also this example)

Message Edited by altenbach on 06-17-2009 01:21 PM

(This is an idea related to Jack's idea here, which however deals with "reshape array".)

 

When using "built array" with parts that are mismatched in lenght, the largest input wins and the rest are padded with the default value for the given datatype (zero for numerics). This is often not desirable, for example when graphing multiple plots.

 

Padding with zero causes extra data (zeroes) to show on the graph that did not exist in the original wires. A more desirable option here would be to pad with NaN so only actual data is graphed.

 

My suggestion is to add an optional input to "built array" that allows defining the pad value is case the inputs are mismatched.

 

Here is an example how it could look like. (of course the icon would probably need to change a little)

 

 

 

This has been discussed in various places like here, but I couldn't find an idea for it...

 

 

There are quite a few LabVIEW primitives which will always run, even if presented with an error on the "error in" terminal. Common examples are "Close Reference" and "Close File". 

 

What would be really useful is to have some kind of visual indication of this behaviour. Ideally this would be a simple marking on the VI icon which could be easily replicated by LV users when we create such VIs ourselves. (It could possibly even be an option in the icon editor!)

 

runonerror2.png 

 

Currently the only indication that a VI will run on error is this discrete line in the VI help:

 

runonerror.png

 

I believe a visual indicator would be much more fitting for LabVIEW as a visual language, and would make this behaviour far more obvious to LabVIEW users.

This is a very small suggestion, and hopefully easy to implement.  When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires.  All I'm asking is that Error wires are always placed underneath all other wires when they are created.  To my mind, this improves the readability of the diagram.

 

ErrorWire.png

 

What would help further is if Error wires were "faded", as if they were 50% transparent.  You do need to be able to see them, but not such that they stand out.  But I'm much less certain that such a change could happen.  The khaki color is an improvement on the old pink though, that's for sure!

 

I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes).  This one item would expand the UI possibilities.  It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets.  Below are some industry examples:

 

Adobe X.png

Adobe Splash Screen (No border, has shadow, not square)

 

Microsoft.png

  Microsoft Word 2010 Splash Screen (No border, rounded corners)

 

Meter.png

 Resource Meter Windows Gadget (No border, specialized graphic)

 

Windows Media Center.png

Windows Media Center Gadget (Empty-transparent space between two UI elements)