LabVIEW Idea Exchange

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

I often use LabVIEW projects.  Projects may contain libraries, classes, etc.

 

Changing the contents of any component (such as a library) within a project causes the project file to change -- even though the project definition itself shouldn't have actually changed. For instance, if this is my project:

_carl_0-1656622304965.png

and I delete a VI that is inside an .lvlib, the project file itself claims to have had an attribute change:

_carl_2-1656622426038.png

_carl_3-1656622515498.png

In theory, this top-level project change isn't necessary -- since the project should just reference the library, and only the library should reflect a change.

 

These unnecessary file changes make it trickier to deal with source control, merging code, tracking changes, etc, along with adding one more file that you get prompted to save every time you close a project.

One of the fiddly things I seem to do more than I'd like is adjust the bottom of block diagram comments to the right height. At a minimum there, but also for similar text boxes on the front panel or subdiagram labels, etc. I'd like to have a snap feature that sizes to a multiple of the text height. Examples:

 

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • This idea would speed up development by enabling us to cycle through element selection without using the mouse.
  • When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
  • This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
  • I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.

Thanks!

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:

 

  • Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:
    _carl_0-1718205041101.png
    The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
  • VI Properties aren't available in VIs:
    _carl_1-1718205311007.png
    I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
  • Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
  • Private class methods don't show up in the project.  But if you click on the sub VI for a private method, you can open up the block diagram.  If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
  • Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked.  For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup:
    _carl_2-1718205991996.png

     

 

                             

                              lvproj : be able to rename a folder

 

SR2.png

 

             SR3.png

Back in the NI-CAN days, there was a handy development tool which was the usage of two virtual CAN ports, ports CAN256, and CAN257.  If you wrote a frame on one, it would be read on the other, and vise versa.  Other CAN hardware like Vector, and Kvasar support virtual CAN hardware which does something similar, where initial development can be tested before having access to the hardware.

 

This idea is to add virtual hardware support for XNET which supports this same feature.  it has been talked about in a thread here several years ago, but nothing ever came of it.  Adding support for virutal hardware for CAN, LIN, Flex-Ray and any other XNET hardware would be a great development tool, and enable the testing of the expected handshaking of software, with simulated communications.

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

It would help a lot if we have an option called pause on first Error. So that the VI at the node/primitive that generates the error and highlights that node so that user decides to continue or abort.

 

Have you ever created a cluster like this?

 

 

Big Cluster.PNG

 

 

I have. Numerous times. It's fairly easy to create clusters which get out of hand. The magic number is usually around 10-15 elements, assuming some of them are clusters as well, but even if those numbers are manageable, I've also created larger ones, and those aren't manageable.

 

Using LVOOP mitigates this to some degree, but does not solve it completely.

 

So, it would be great if we could divide the cluster into "pages" or "categories":

 

Cluster Tab.PNG

 

This will allow us to logically divide the cluster into manageable areas.

 

The names of the pages will appear in the selection list and in the unbundle node, as shown in the example (although you could hide them in the node by unchecking the full names option), but they will NOT actually be part of the element's name. Changing the name of a page or moving an element from page to page will NOT require you to change code which already uses that element.

 

Notes -

 

  1. In my mockup I used a tab control. I understand that LV R&D has some aversion to the concept of tabs inside clusters, so I would like to make it clear that I'm NOT asking for a tab inside a cluster. This is purely a cosmetic and organizational feature.
  2. I already posted this as a comment on this idea, but I figured it was worth posting as a separate one.

String containers have display format Glyphs to help us understand the String Values when the display is Normal, Hex or Escape codes.

 

Integer numeric type containers have them too to show radix.

 

Timestamp containers must be inspected for their display format property to determine if they are in System Time or UTC.   

 

Timestamp Controls, Indicators and Contsants SHOULD have a similar optional display format glyph.

 

This could be used instead of the misleading coercion dots when operations are performed on Timestamps as Seen Here 

Estimate and show the Time Remaining during LabVIEW Installs, using selectable and realistic time units:

.

install.png

It's useful that we can open the Error List window via the Ctrl + L shortcut.

 

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It would be great to have keyboard shortcuts that allowed us to navigate to the next and previous errors (broken run arrow locations). This would be similar to how Ctrl + G and Ctrl + Shift + G can be used to navigate to the next and previous result in the Search Results window.

 

I would be happy with any key combinations chosen for this purpose.

 

Thanks

I would like to be able to change the z-order of FP Objects programmatically. For starters, I envision the following properties:

 

  1. Layer - Explicitly sets the z-order layer in which an object resides.
  2. Promote/Demote - Implicitly sets z-order layer by -1 or +1 (assuming Layer 0 is frontmost)
  3. Send to Back/Send to Front - Explicitly sets z-order to the foremost or rearmost layer
  4. (Optional) Container property "Layers" - Returns an array of all layer indices currently in use by the container (Page, Panel, Cluster, etc.)
  5. (Optional) Container method "Layer.Objects" - Returns array of references to all objects on a layer
 
ControlLayers.gif
 
Question at this point: can more than one object reside on a layer, or should each object represent a discrete z-order? Does changing the z-order of one object likewise affect the z-order of other objects? Discuss in the comments.

 

I'm totally on board with Embedding Labels for Property and Invoke Nodes! Here are some additional improvements to those nodes:

 

Property Node Concepts

22360i1B976CE68F1194B3

 

Scripting and Invoke Node Concepts

22364iA43FCE953263A787
  1. Most importantly, the banner now more closely resembles a Static Control Reference.
  2. The directionality arrows are a pixel width's larger - more distinct, and matching the size of the new LV2010 Local Variables.
  3. The node banner is the same height as the unlinked property node.
  4. Property Nodes and Invoke Nodes are distinguished by the Property Wrench and the Action Arrow glyph.
  5. Scripting properties/methods are now more distinct. Currently, the small node banner inherits a few pixels of light blue distinction if any one property on the property stack IsAScriptingProperty. Proposed, shading will be applied on a per-property basis, allowing better visual distinction and a more coherent choice for what to shade.

Discussions/suggestions/insults/questions encouraged in comments section!

Why not create the option to change how the data is viewed on screen, similar to formatting in Excel or the Calculator function?

 

This could also be used for a hex display (I.E. FFFF FFFF), octal or even binary.  Options could be expanded to include how many characters before separation and what to use as a separator.

 

LV_Separator.PNG

With the IPv4 address pool quickly getting used up I think we need to have native support for IPv6 connections in LabVIEW.

It would be useful to be able to disable the handling of a single Event Case in an Event Handler Structure. Note that this is distinctly different from merely Diagram Disabling the contents of the Event Case; using that method, the Timeout event case will be reset, and additionally program execution will continue past the Event Handler Structure (in the example below, continue to the next iteration in the While Loop).

 

Here's an example of what a Disabled Event Case might look like - the Event Structure and contained code is "washed out" as if Diagram Disabled - additionally, the disabled event in the list of Event Cases is struck-out and in italics:

DiagramDisabledEventHandlerCase.png

 

And here's a proposal for how one might disable a given Event Case, using the context menu that pops up by right-clicking the border of the Event Handler Structure:

 

HowToDisableAnEventCase.png

Right now a lot of SubVIs in Vision Development Module looks like that:

 

IMAQ Vision Connector Pane.png

 

Because in most cases we using IMAQ Images on the top and error outputs - the wires fully misaligned. It would be nice if all (or most) of them will have standard and same "default" connector pane (if possible, of course).

Thank you!

 

Andrey.

 

Picture says it all.

 

Concatenate with an option of 'concatenate to new line'

 

 


I am not allergic to Kudos, in fact I love Kudos.

CLA_Short.jpg

 Make your LabVIEW experience more CONVENIENT.