Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Do you have an idea for LabVIEW NXG?
Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!
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.
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.
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?
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.
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!
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.
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!
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 ;))
(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)
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 Splash Screen (No border, has shadow, not square)
Microsoft Word 2010 Splash Screen (No border, rounded corners)
Resource Meter Windows Gadget (No border, specialized graphic)
Windows Media Center Gadget (Empty-transparent space between two UI elements)
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!)
Currently the only indication that a VI will run on error is this discrete line in the VI help:
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.
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!
This recent idea reminded me of something I have wanted for quite some time now: the ability to determine if a property is read or write based on wiring, not some half-buried option in the right-click menu.
The basic idea is simple: all properties have two terminals, one for writing and one for reading (except read-only of course). No right-clicking, just wire up the direction you want.
The bottom case is a bit interesting. I see a few possibilities:
1. Passthrough (cosmetically saves branching, crossing, etc.) Same behaviour regardless of errors.
2. Read then write : returns previous value. What happens if there is an error? Passthrough, old value?
3. Write then read: almost always passthrough. In case of error would it return old (ie. actual value) or passthrough?
4. Do not allow this.
I would expectit to perform the write and then the read (3) or passthrough (1). What is more important to me is the actual value and not the intended value. Mentally I just see data flowing into then out of the PN when both are wired.
Bottom line: I see no reason not to permit the wiring to determine read or write of a property.
If there is a cop-out lack of consensus and simultaneous connections are not allowed, I would at least ask for a keyboard modifier (say shift) such that I can shift-drag to expand the PN and get the same property repeated instead of going down the list. Then I could at least do the write+read with a lot less mouse movement.
The web format wars are over, and the plug-ins have lost. Microsoft has relented and will support HTML5 and SVG in IE9, and has admitted that Silverlight's role will change to that of a Windows phone development platform. Silverlight support on iPhone/iPad/Andoid/Chrome OS will likely never be fully formed, and will wither on the vine.
I have built my own SVG UI objects using Inkscape (free), and wrote a script (notepad/Inkscape script editor, also free) to handle WebSockets communication without a gateway. I have a simple LV class built on the TCP/IP functions that will stream data to/from a browser which is pointing to an SVG "webpanel" that I also built using Inkscape. So far I have a simple waveform graph, buttons, LED's, progress bars, etc. I have tested my Inkscape webpanels in Firefox 4.0 Beta and Google Chrome 9 and it works like a champ, and is very fast. The old-fashioned LV webserver will serve up SVG files with the addition of a mime type.
An alternative to SVG is the HTML5 <canvas> tag, which allows the rendering of graphics drawn using java/ecma script. There is a free-for-personal-use script library called RGraph Library that you can download with lots of example code. Here is RGraph/LabVIEW in action in Chrome 9:
So what is my idea?
0. Ditch Silverlight.
1. Convert all of the nice-looking UI panel objects in the Web UI Builder from Microsoft XAML to SVG and distribute them with the LabVIEW professional development license. I am programmer first, and I admit my web panel objects don't look too good.
2. Design a script library for handling WebSockets communcation (or add native support for WebSockets to the Shared Variable Engine) and manipulating/updating the SVG UI objects from streamed WebSockets data. Make this library open source.
3. Create a standard open protocol for streaming LabVIEW data that sits on top of WebSockets and is free and open.
4. Publish documentation for the SVG UI elements so users and thrid parties can create new UI objects. Make use of the creativity of the community at large!
5. Modernize the Web Publishing Tool so that it will optionally output an HTML5 and/or SVG document that accepts streaming I/O from WebSockets. The user could choose from compatible SVG elements to use in place of front panel elements on the VI being published.
6. Create a Web UI SVG element exchange for registered NI users to upload/download elements for free.
7. Work toward the long term goal of adding SVG Import/Export to the control editor (with better editing tools), or make the CTL format of custom controls SVG/XML.
How many times have you found yourself entering items in an array, typing merrily along, only to have to switch back to a mouse to click on the next element and type it it. I suggest that Alt-Enter complete the current entry and move to the next array element.
This idea proposed using the Tab key, which collides with manual tool changes. Shift-Enter was also proposed, but it collides with the ability to move to a new line in strings and to add another element to a enum/ring.
I propose using Alt-Enter to advance to the next array element:
Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?
Ever wish LabVIEW had more appearance customization to make better looking GUIs?
I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.
Take a look at the difference:
Not Ideal Front Panel with background image and NO Opacity Control
Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%
Before and After Appearance Settings tab in the Properties Window for a waveform graph:
Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:
Kudos and share this idea if you want it to happen!
i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...
Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!