LabVIEW Idea Exchange

Currently (in LabVIEW 2010), you can add labels to wires. Hurray!!

But it's painful. Boooo!

Curently => Right-Click wire, navigate to sub-menu of Show>>Label

It should be as easy as adding free text to block diagrams or front panels. For example: If your auto-tool is on then just double-click on freespace to add text.

So we should make it just as easy to add labels to wires:

• Step 1: Single-Select Wire
• Step 2: Start Typing
• Step 3: Profits!

Another for the wish list.

It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).

The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.

A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.

See attached pic for an mock up.

 There are probably lots of menus that could benefit from something like this.

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.

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.

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.

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!

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

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,

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

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

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 (Sub-VI of a Running Top-Level VI)

  << This is what I look for

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

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

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.