From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).

I just realized that when creating an interface you cannot create property node folders.

 

You can see from the pictures below that option is missing from interfaces.

 

second.pngfirst.png

 

You can also see from that screenshot that it is possible to have property folders in interfaces and they work just fine. You have to edit the xml to do that, but it works. So it is implemented, it is just removed from the IDE.

 

Now I talked to Darren and he seemed to think the original reasoning was "Well property nodes are for storing things in the class private data and there is no private data with an interface, so you don't need them." I can't really argue with that logic, however, there are times when an existing class uses a property node and you want to create an interface that includes that method. For example you may have multiple instruments that have a VISA ref property. You currently can't create an interface with that "write VISA ref" VI (without editing the xml.) If you create a method with the same name/conn pane and it is not in a property folder, the compiler complains. Now you could just go back and edit the original class and remove the property node and just use a regular method. However then you break every piece of calling code that is using a property node.

 

Here is a use case, which I think is fairly common - it happens to me a lot:


I inherit some code. It is using some particular instrument (Oscope, DMM doesn't matter) They want to support another similar instrument (maybe newer version of the DMM).

 

The instrument code is wrapped in a class. Great. As a first step, I can refactor. I can create an interface that has all the same methods and make the code rely on the interface. If it is a class wrapped in a DQMH module, all I have to do is replace the object in the Shift register with the interface and somewhere set the concrete class in the initialize. It all works exactly the same as before, but now I have an interface.

 

Then I create another class that implements that interface and add some logic to pick which one - some kind of factory. Done. I've made very minimal changes to the existing code and it now supports a different instrument. This is the holy grail of OOP. I create a new class and just inject it and everything works.

 

Not so fast. NI has decided I shouldn't be able to do this if the class uses a property node (oh no!) why? I should be able to have 2 classes that both have the same property. Sure the data's not getting stored in the interface, but what does that matter?

 

It does matter to the compiler. If I want to do what I proposed above and the original developer used property nodes anywhere this doesn't work directly. I have to either do some xml hack on the interface or I have to replace all the property nodes in the calling code with subvi calls and then go edit the class and remove the property folders. Why?

 

It seems like all that is needed is enabling the right click menu, because if you manually edit the xml, it all works. That is already implemented for classes, so I imagine the fix would be rather simple.

Dear LabVIEW Team,

I hope this message reaches you in high spirits and with a cup of tea in hand, because I am about to share a groundbreaking idea with you.

After years of fascinating work with LabVIEW, I would like to express my sincere admiration for the breathtaking number of windows that make your development environment so unique. While other programming environments like Visual Studio try to structure the development process in a boring way, you clearly rely on the "more is more" principle.

It is simply fascinating to see how each VI always has two independent windows. It makes me feel like I'm exploring a virtual windowscape - a journey into the unknown where each window is an adventure in itself. I can't remember the last time I had this much fun developing.

But why settle for just a few windows when we could take inefficiency to a whole new level? So I propose: Let's keep increasing the number of windows! Why not give every single structure in the code its own window? That would really be the pinnacle of chaos efficiency.

 

I imagine it like this: When I create a loop, a new window opens in which I can program the code for the loop. For each case of a case structure - another window. The possibilities are endless! An endless labyrinth of windows that turns my screen into a colorful kaleidoscope. That would be the pinnacle of innovation, wouldn't it?

I hope my ironic enthusiasm for the distinctive LabVIEW window concept has been well received. I am certainly available to discuss this idea further and am willing to contribute to the creation of an even more chaotic, but undoubtedly entertaining, development environment.

With sarcastic regards,

An enthusiastically chaotic LabVIEW developer

 


Sehr geehrtes LabVIEW-Team,

 

ich hoffe, diese Nachricht erreicht Sie in bester Laune und mit einer Tasse Tee in der Hand, denn ich stehe kurz davor, eine bahnbrechende Idee mit Ihnen zu teilen.

 

Nach Jahren der faszinierenden Arbeit mit LabVIEW, möchte ich Ihnen meine aufrichtige Bewunderung für die atemberaubende Anzahl von Fenstern aussprechen, die Ihre Entwicklungsumgebung so einzigartig machen. Während andere Programmierumgebungen wie Visual Studio auf langweilige Weise versuchen, den Entwicklungsprozess zu strukturieren, setzen Sie eindeutig auf das Prinzip "Mehr ist mehr".

 

Es ist einfach faszinierend zu sehen, wie jedes VI immer zwei unabhängige Fenster hat. Das gibt mir das Gefühl, als würde ich eine virtuelle Fensterlandschaft erkunden – eine Reise ins Ungewisse, wo jedes Fenster ein Abenteuer für sich ist. Ich kann mich nicht erinnern, wann ich das letzte Mal so viel Spaß beim Entwickeln hatte.

 

Aber warum sich mit nur ein paar Fenstern begnügen, wenn wir die Ineffizienz auf ein völlig neues Level heben könnten? Daher schlage ich vor: Lasst uns die Anzahl der Fenster weiter erhöhen! Warum nicht jeder einzelnen Struktur im Code sein eigenes Fenster zuweisen? Das wäre wirklich die Krönung der Chaos-Effizienz.

 

Ich stelle mir das so vor: Wenn ich eine Schleife erstelle, öffnet sich ein neues Fenster, in der ich den Code für die Schleife programmieren kann. Für jeden Case einer Case-Struktur – ein weiteres Fenster. Die Möglichkeiten sind endlos! Ein endloses Labyrinth von Fenstern, das meinen Bildschirm in ein kunterbuntes Kaleidoskop verwandelt. Das wäre doch der Gipfel der Innovation, oder?

 

Ich hoffe, meine ironische Begeisterung für das unverwechselbare LabVIEW-Fensterkonzept ist angekommen. Ich stehe Ihnen selbstverständlich zur Verfügung, um diese Idee weiter zu diskutieren und bin bereit, meinen Beitrag zur Erschaffung einer noch chaotischeren, aber zweifellos unterhaltsamen Entwicklungsumgebung zu leisten.

 

Mit sarkastischen Grüßen,

 

Ein begeistert chaotischer LabVIEW-Entwickler

Struggling to replace R&S FSW-K70 by VST and RFmx for my customer, found 16APSK and 32APSK are not directly supported by RFmx DeMod.  The customer is currently using FSW-K70 and their current test scnearios require 16APSK and 32APSK modulation and demodulation.  

 

I found a thread mentioning about APSK support below.  

 

https://forums.ni.com/t5/LabVIEW/APSK-Modulation-Demodulation/td-p/4232293

Often, I have wires already on a block diagram and I want to add a new structure (case, flat sequence, etc.) that utilizes those wires internal to the structure or in some cases passes them completely through the structure. For example, consider needing to implement data flow for a node that has no error input and output, such as when using the Wait (ms) function. To implement data flow when using this function, I might place it in a flat sequence with a single frame and pass an error wire through it as shown:

Ryan_Wright__1-1708013874803.png

If the wire already exists and you try to put a new structure over the top of it (using the same example referenced above), you get the following behavior:

Ryan_Wright__2-1708013992633.png

It would be really nice if LabVIEW would automatically pass the wire through the structure or at least wire up to the left border when doing this as shown in the following pictures:

Ryan_Wright__3-1708014077542.png

Ryan_Wright__4-1708014170821.png

The automatic wiring behavior of whether to pass the wire completely through the new structure or to only wire to the left border could be evaluated on a case-by-case basis for each structure (For Loop, While Loop, Case Structure, Event Structure, Flat Sequence, Diagram Disable Structure, Conditional Disable Structure, etc.).

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).

 

rearrange-subdiagram.png

This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.

 

rearrange-subdiagram-labels.png

Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.

 

rearrange-subdiagram-labels-preview.png

There should be a Browse button on the right click menu for front panel items as it is on the block diagram right click menu.

Quiztus2_0-1707817399604.png

Make the search in Browse traverse the displayed property tree instead of the type specialization.

Otherwise you won't find Increment when searching the graph's properties:

Quiztus2_4-1707817683201.png

 

Just display the hierarchy with the results like:
X Scale::Range::Increment

Y Scale::Range::Increment

 

 

 

 

 

Currently if you create a new VI for override, whether or not the terminals are displayed as icons is determined by the VI being overridden (e.g. overriding Actor Core.vi will always give you terminals as icons). Instead, I propose that it be determined by the user's preference in the Tools--> Options menu. If we've said we don't want terminal icons, shouldn't all newly created VIs respect that?

Many times a day I need to look at the full text of an error cluster's "source" string.

The workflow for this has always been awkward.

Additionally, "Explain Error" also requires some extra clicks.

 

What if we combined all of that functionality into the context help so that, when the user mouses over a populated error cluster with context help enabled, the user can see all the relevant information quickly?

 

ContextHelpErrors.png

Not every bundle is linked to a Typedef. It would be very useful to automatically inherit the names of previously named wires into bundles.

Showing the Current and Proposed behavior for name inheritance in the bundle functionShowing the Current and Proposed behavior for name inheritance in the bundle function

As part of everyday class development, I often want to track down everywhere where certain class data is being used. Would be convenient if there was a shortcut for doing this...perhaps something like:

 

_carl_1-1678141878195.png

 

 

On a block diagram string constant, there are shortcut menus to change the display style. Currently, we can change the style without making the selector visible. That leads to bugs when later programmers do not realize that the string they are editing is in a different mode. Currently, we have to choose "Visible Items >> Display Style" first, which makes the shortcut menu items useless (because then we just use the now-visible selector ring). In the future, when we change the style through one of the shortcuts, I would prefer that the selector automatically becomes visible. 

srlm_0-1685481071737.png

 

In LabVIEW IDE, when configuring executable build specifications, under "Version Informtion", it could be greate to have a string control to store free information depending on our version numering management (ex: alpha, beta, release candidate ...). This value could be used as a postfix to the 4 digits version (ex: version "1.3.0.1 alpha 5").

 

In "Details" tab of Microsoft Windows executable files, the "Product version" metadata is a string so there should be no problem.

 

Download All

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

 

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

 

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

 

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

 

Essentially, what I would like is a Type Specialization Structure that works backwards.

 

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

 

Simple example of SelectSimple example of Select

 

 

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.

 

If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation

 

I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.

I mean, OpenGL is cross platform, right?  Let's bring graphics performance at least into this century.

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

 

Before.png

Start wiring the new error, then click on the merge error node.

During.png

LabVIEW expands and connects the error wire

After.png

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

 

 

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

Bonus.png

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

 

When looking for unexpected behaviour in time or memory usage of a project the Profiler is useful and easier than the execution tracer, but it could be made much more useful by adding the ability to monitor for changes and analyse the issues.

 

Mads_0-1695798309247.png

 

Issue:
Currently detecting how the memory or run counts e.g. of a VI changes over time you have to take snapshots, save them and then compare the values in e.g. Excel. (which the saved traces do not directly fit into either...)

Proposed feature: Trends
It would be nice if you could just set the tool to automatically sample and log all/selected numbers regularly and then be able to view the trends. 

 

Proposed feature: Automated Analysis
Having trends will help in manually detecting issues, but the profiler could also have tools that helped you in this, e.g. highlighting which VIs show a continous growth in memory. This could also then be expanded by being able to call a VI analyzer on any given VI - preferably made/set up to identify possible reasons for a memory leak e.g. (unclosed references, continous array building e.g.).

In a simple project, the main entry point into an application is usually easy to find:

simple.png

 

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

complex.png

 

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project. 

 

One possible implementation:

links.png

  • Display tagged items as links at the top-level of the project.
  • Links would be pinned to the top row
  • Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
  • For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
  • In principle links could point to anything interesting, not just the main VI.
  • Double-clicking a link should open (or navigate to?) the target item

 

The current register event callback node is allowing an easy way to handle ActiveX and .Net Framework events. This node is also very similar in appearance to the property nodes, yet it does not have an insert (Add Element) or remove (Remove Element) function available in the context menu. Since the property nodes, and also the named (un)bundle nodes are having this implemented, I think it would be nice to have these easy to access functions instead or having to grow the node, change all the elements below the one that we want to insert and rewire everything.

One downside of this idea is, that it will throw the wires a little further away than the upper mentioned named (un)bundle and property nodes do, since it is a 3 terminal height element.