LabVIEW Idea Exchange

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

From considering a number of other ideas (see below), I want to suggest that the Block Diagram is the only item initially created when defining a VI, and becomes the place where ALL VI functionality is defined.  The BD is the place where dataflow is specified and the functionality of the VI is determined.  So it makes sense that the con-pane should be linked to the BD rather than the FP -- it defines the data interface between calling VIs to this VI.  Similarly the icon often provides a visual clue to the VI functionality, rather than its FP look.  So both con-pane and icon are natural components of the BD window.

 

From the BD, it should then be possible to define one, or more, Front Panels which provide user interfaces to the data.  These FPs may contain some or all of the variables in the con-pane (why ever show Error In/Out?), along with some or all of any other controls/indicators used in the block diagram.  In fact, the Probe Window is already almost an additional FP - just allow several data indicators to be grouped on a single window, and you essentially have a Debug Panel.  It would be great to be able to save the Probe window (or several of them) with a VI. 

 

Yes, there will be problems, not least that I'm sure some existing code assumes that an FP (and only one) exists if a BD exists.  And that every control/indicator must have a FP representation.

 

Here's a rough mockup (though the Probe points could be "virtual indicators" instead):

BD+FP.png

 

Other related ideas:

Be able to link to the connector pane in Block Diagram

Sub VI without Front Panel

Custom Probe Watch Window

We need to uncouple the "edit mode" FP size from the "run mode" FP size

 

and one trying to address the same concerns, but in a way I don't like:

Add Data layer for VIs... 

Please include mSec value in probe watch. This helps to find the execution time between two events within a few mSec delay. Thanks

It makes no sense (from a Software Engineering and Process standpoint) to force (and store) an absolute path for a build destination directory, in the project. What if a group is sharing a project but each developer prefers to have their files located in a different folder?!!

 

I recommend NI consider replacing the line of code in LabView that is checking for the presence of an absolute path for the build folder with on that does: "If user entered an absolute path, use it; otherwise, prepend the current project location to whatever (relative) path the user entered before building."

 How many developers are using a splash screen for their applications ? Shouldn't this be a straightforward task even for beginners ? NI should provide an easier way to implement this technique.

Feedback nodes can reside entirely inside one case of a case structure. This simplifies coding if feedback operations are limited to one single case. Unfortunately, there is no easy way to retain the output once the loop has finished if the last iteration executes one of the other cases. As a result, we might see local variables or even indicators inside the case containing the feedback node, defeating the "in place" purpose. For a "wired" solution, we need to place the feedback node outside the case and wire across all other cases (image top).

 

I propose an output terminal that sits on the output edge of a loop and contains the contents of the feedback node at the time the loop finishes. Typically that would be the edge of the same loop that contains the initializer terminal (image bottom), but it should also be available for globally initialized feedback nodes and on other loop boundaries surrounding the feedback node (selectable).

 

I am sure this idea needs to be worked out in more detail, so this is just an initial concept. 😄

 

 

 

 

Message Edited by altenbach on 06-16-2009 09:34 AM

In a big project I needed to insert a function at several (read "more than hundred") places.

How much would I have appreciated a history which gave me a direct access to this function without the need to go to the specific functions palette again and again !

This would have saved me a lot of time... and made this annoying task a little bit less annoying !

 

LabVIEW should memorize at least the last inserted function/VI but a history of four or ten would be much better.

 

The history could be implemented either with an extra menu (see below image) or by listing the X last inserted functions/VIs right under the All Palettes menu entry.

 

The incompatible functions/VIs for the wire type should be grayed out or, even better, the history should be contextual and list only the compatible functions/VIs.

 

Insert history.jpg 

As mentioned in this post, and elsewhere, it is very helpful on the forums to (1) post images and (2) post code that is usable by the masses (typically 8.6+).  Snippets are a useful way to post both images and code (for 9+ officially and earlier with a few tricks like the Code Capture Tool).  One downside is that if you are working in LV10 your snippet is not usable in earlier versions.  It would be nice to be able to Create a Snippet for a previous version in one operation.

 

I do this myself, for example:

 

 

Makes life easier for both the posters and the responders on the forums.

When I need to access project-related non-LabVIEW files in my VIs, I usually write code like this

File path relative to the VI path in LabVIEW 2019File path relative to the VI path in LabVIEW 2019

I can't afford to use absolute paths because my collaborators don't set up source code control on their computers the same way I have it on mine, and I am fine with that.

 

Writing this type of code is tedious. I have to place four nodes and three wires between them to get one path. On top of that, coming up with the relative path requires either browsing the absolute path, and deletion of the portion of that, or copying and pasting paths from the OS.

 

I would like to express this with a single node. It could be a mode on the path constant, with some visual difference to convey that it's doing something else. Here is one idea

Path relative to the directory that contains the VIPath relative to the directory that contains the VI

You'd be able to browse the path the same way you do today, and change the mode with a right-click and/or configuration dialog.

 

This idea was inspired by TestStand, where you can typically indicate whether you want a path to be stored as absolute or relative.

One of the quickest (and easiest to forget) methods to improve performance of your VI is to disable debugging.  It requires a trip down the VI properties to get there, however.  I propose adding a button on the BD alongside the other debugging buttons to Disable and Enable Debugging.  

The current implementation of script nodes (formula, mathscript, etc.) is a bit unwieldy. We have to find a delicate balance between node size and content. (too small and we need to constantly scroll the text code. Too big and it is difficult to wire around it and fit it into the rest of the g code.)

 

My suggestion is that script nodes on the diagram look just like e.g. call library nodes (or possibly express VIs). Double-clicking them would open a separate editor window that floats above the code. Near the top we have a growable area where we can define the connector names, inputs and outputs  (variable name, datatype, etc) and below we have a nice code editor window similar to the current mathscript node, just comfortably big (e.g. like notepad)! At the bottom there could even be extra tools, e.g. like import from text file, save to text file, etc.

 

Typically the node would be collapsed into an icon but the script window can be left open during editing and debugging.

 

This is one case where breaking out of the confines of the 2D diagram would be helpful. The current formula nodes just don't really belong directly on a diagram. Nobody want to compose and edit text in an area the size of an old cellphone screen.

 

This is just a very rough Idea. The details would need to be worked out further....

My front panels are typically large tab controls so most of the FP design and editing takes place on tabs.

 

In this scenario we lose significant usability, for example:

 

 

  • We cannot double click on empty space to create a free label
  • We cannot see the alignment grid.
  • ...
Proposal:
  • The background alignment grid should continue across tab controls and other containers (e.g. clusters) in edit mode.
  • double-clicking inside an empty area on a tab should start a free label operation, same as on the plain background. (only clicking near the border should "find" the terminal instead).

 

Many of the property accessor VI creation scripting is currently hard coded, or not easily changeable. There might be some conventions around how to name a property accessor, or about the usage of the error handling case structure inside the accessors. It would be nice, if there was a user settable option for these.

The things that I have to change often:

  • The read VI to Get, the Write VI to Set
  • Front panel controls and indicators to the default style
  • Removal of the error handling case structure
  • Renaming the Error in (no error) to error in (this might be solved by the global ini setting though)
  • Organizing the labels to the left for controls and right for indicators on the block diagram
  • Cleaning up the front panel, with the Ctrl+U shortcut, while there is a scripting code in the quick drop to arrange both the front panel and the block diagram, by default Ctrl+F

To fix most of these, I modified the scripting library, for all the templates and the global defaults containing the name for read and write VIs.

It would also be nice if we could override the scripting class as a whole, in order to customize the end result, without needing to go over trough VI again.

This LV typedef for the Waveform Graph property Cursor List is missing Line Width and Line Style! This is probably a solution to the mystery behind another post Show Attributes Selections I made earlier today. In order to completely define our Cursor List properly with one Property Node, those two elements must be part of this public typedef.

 

CursorListProperty.png

Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.

Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.

This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.

 

To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).

 

Current situation:

current situation

 

 

improved functionality:

improved functionality

HABF?

 

An acronym for one of my favorite Spolskyisms. Great article, read it.

 

Background

 

When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.

 

Problems with Current Issue Tracking Platform

 

"Platform" is a generous term for the current reporting and tracking process:

 

  1. The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
  2. Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
  3. Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
  4. Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms

 

Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. Smiley Very Happy The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.

 

I want to see an analogue for Issue Tracking.

 

Proposed Solution

 

A web-based platform with the following capabilities:

 

  1. Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
  2. Allow embedded video screen captures (such as Jing)
  3. Allow uploaded files that demonstrate reproduceable issues
  4. Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
  5. Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
  6. Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
  7. The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
  8. A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
  9. Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
  10. An email-based alert system, letting you know when the status or content changes in bug reports of interest (:thumbup1:)
  11. Same username and logon as the Forums
  12. Bonus: Visible download links to patches and other bug-related minutiae

 

Additional Thoughts

 

  • I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
  • I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
  • Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.

 

BugFeature.png

(Picture first spotted on Breakpoint)

 

Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.

 

My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

This is similar to the idea about moving items in the connector pane and is an extension of it for any input or output on the block diagram -

 

Often, you connect a wire to a wrong input or output. Today, fixing it requires wiring to the new location and manually deleting the old piece of wire. The only exception is two-input functions with both inputs already wired, where you have a keyboard shortcut for swapping the wires. 

 

A much more natural and general method would be this - if you use the wiring tool on a wire source or sink and then on another, the wires should be swapped (or if there's only one wire, it should be moved).

 

 

In this example I wired the 7 into the wrong input and I want to move it one input down, so I:

 

1. Click the top input. This "grabs" the wire, so to speak.

2. Click the bottom input. This moves the grabbed wire to that input.

 

Move Wire.gif

 


Message Edited by Support on 10-22-2009 01:25 PM

I would like to have the ability to set the compare aggregates mode for comparisons involving containers (arrays certainly, clusters would be a nice bonus) and a scalar value.  This includes the comparisons to 0 functions as well.

 

compareAggregatesIdea.png

As described here, the Event Structure has a few interface issues. One of which is that the "Rearrange Case" Dialog window is not resizable, and the "Complete selector string" has no scrollbar:

 

ScreenHunter_004.jpg

 

If you have dozens of cases, some of which may contain a dozen different events, this is a nightmare to use.

Don't get me started on the way you can rearrange cases only by dragging and dropping one at a time (ever heard of alphabetical sorting for instance?)!

 

Thanks for reading.

As a service to trivia buffs everywhere, as well as helping us help people with different LV vintages, I would really appreciate it if the LV help detailed the required version for the various functions and VIs in the palettes.  A simple indication in the 'Requires' field would suffice.  The more the better, but at least start with recent/new additions and work back.  "When was that added?" is a quite common theme.

 

NewHelpInfo.png

I often work with DVRs, usually using typdefs or classes for the underlying data.

 

It's a serious pain to access the typdef or class from the DVR itself (control, indicator, or wire).  There's no option for accessing this through the menu, and I often find myself dropping code in my block diagram to output the data type, then right-clicking on the data type and then from that menu opening the typdef or class.

 

The request: add a menu option for "Open Data Type Def." or "Show Data Class Library" to directly access the underlying type if it's a type def or class. This menu option could be exposed on wires, controls, and indicators.

_carl_1-1673552680629.png