LabVIEW Idea Exchange

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

Currently, the TDMS File api does not offer a way to get the TDMS file size.

 

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too).  To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

 

 

Jim_Kring_0-1707938415587.png

 

History probes are a very useful tool in LabVIEW. However, one improvement can be made to them when working with enums. Currently, the values in enum history probes are returned as numbers, as shown in the picture below:

 

Enum History Probe.png

 

It would even be more useful if enum history probes returned values in terms of the enum item names rather than the numeric values associated with them, as shown in the picture below.

 

Enum History Probe.png

The asterisk (*) that LabVIEW automatically places in the title bar when a file is modified should be placed first not last so that it can be seen when the window is too narrow to display the whole string, e.g. where other programs like Notepad.exe put it when then text truncation is indicated by an ellipsis (...). Some titles can be much longer when they include lvlib and lvclass contexts.

 

ast.jpg

When selecting a set of object that are from the same class, I'd like to be able to change some of their main properties at once from the right click menu.

For instance, when selecting a bunch of numeric controls, being able to change all their representation to U8 without having to open the property page (which sometimes take some time to load.

This could be done either via the r.click option, or even via the properties page that would show that it is for more than 1 item. Via the property page 

VinnyAstro_0-1705567415946.png

 

From the property page, it would be nice to have the possibility to easily change their label and caption independently and faster (using tab) than to have to change them manually by double clinking on the labels, hoping to not click on the side of the box.

 

This happens to me all the time:

VinnyAstro_1-1705568287315.png

This could be a viable option in my opinion (Please excuse my poor designer capabilities):

VinnyAstro_2-1705569130610.pngVinnyAstro_4-1705569195313.png

 

 

 - Vincent.

The following code will essentially do what I want, but I want this to be natively incorporated into the IDE as an option.

CaseyM_0-1695271655726.png

 

90%+ of the VIs that I write have a front panel that doesn't get shown to the end user, and yet, whenever you open a VI what does it show you? The front panel. I think the default behavior of opening a VI should be to show the block diagram ONLY. This would have several advantages for the developer:

  1. Fewer windows to manage - Even if you minimize the front panel, you can still accidentally restore the FP when you Alt-Tab or click in the taskbar which brings me to...
  2. Less clutter in the taskbar - Once you open more than a couple VIs, navigating to the block diagram of the VI you want in the taskbar becomes very unwieldy.
  3. You could more easily get to the BD of VIs running in a subpanel.
  4. It would be possible to get to the BD of a VI that has a custom run-time menu where Ctrl-E is disabled.

Ideally this would be an option in the Tools --> Options dialog (that I would always turn on).

 

This idea is similar to one posted almost 15 years ago, but I don't consider this a duplicate because this takes things a step further by not opening the FP at all.

A portal view to the Front Panel elements from the Block Diagram through a feature like "View As Portal". This would be especially useful in the case of G codes doing calculations, simulations, and modelings in the Block Diagram for people like researchers, scientists, and educators.

 

Picture1.png

Picture2.png

Scroll bar should be disabled if all elements are visible! Kudo here to get a big bang for the buck sooner than the 2nd in TOP KUDOED IDEAS from 2013 with 600+ kudos (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indicate-that-array-constant-contains-more-elements-than/idi-p/2299860). It points out that the scroll bars are not a viable method because it looks the same when all elements are visible. That is EASY to fix; disable the scroll bar if ALL elements are visible! Currently it is disabled only if an empty element is visible. Perhaps the behavior was originally by design like block diagram scroll bars as mentioned in the reason that the following was Declined, '...without this "boundary", it is impossible to create more space...' but constants can easily be stretched by border handles to create more elements (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-window-scroll-bars-reflect-actual-contents-of-window/idi-p/1844127).

 

dwb_0-1703104642443.png

 

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

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

 

BD-Only VIs would be beneficial because:

  • They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
  • They would reduce the developer workload, thus making developers faster.
  • They would reduce the surface-area of the codebase.
  • They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

 

Notes

  • I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
  • The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
  • Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
  • I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
  • It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!

The compare tool is fundamentally broken which is somewhat shocking considering that such a tool is essential to any sort of large scale or long term software development.

 

Attached is a basic LV 2023 example which illustrates some of the many flaws with the tool.  If you compare "old version" and "new version" vi without including cosmetic changes, the tool shows 33 differences, most of which are incorrect.

 

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

Currently if you draw a diagram disable structure around a section of code any wire coming out of it will be set to "Use Default if Unwired". This is almost never the desired behavior, and can easily lead to bugs if people forget to connect wires through on the Enabled case. The VI should be broken until the developer makes any necessary changes in the Enabled case. Diagram Disable Idea.png

I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

 

CuriousSwede_0-1702651324354.png

 

I may want to use it 0-5% of the time.

However, I want to scroll through cases in a structure 95% of the time.

 

Making the 5% use case the default (ctrl-scroll) was a bad design choice.

Reverse it before it's ingrained.

 

(ctrl-shift-scroll is frankly awkward and imagine will become painful eventually)

 

 

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

 

 

 

 

 

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

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.

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

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.

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