LabVIEW Idea Exchange

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

Allow the user to right-click a given test result on the Results Window called "Retest", which re-runs the selected test, and if the test now passes where it previously failed, it clears it from the Results Window.

 

Start with this:

Ozfarmboy_0-1654068733860.png

 

Right click on the selection, and select "Retest":

 

Ozfarmboy_1-1654068909415.png

 

The VI Analyzer just retests the selected tests.  And then once complete, it returns to the VI Analyzer Results Window, with the selected tests cleared from the list (assuming they passed):

Ozfarmboy_2-1654069263041.png

 

 

This idea was posted years ago and declined for lack of interest  (it got 6 out of 7 necessary, but I would have been the 7th!).  I would like to bring it back, I would like my application to have access to it's own version number.  In fact you can open the project programatically and see some build properties but not that one.  I can then grab the version from the build properties and set the default values on my FPGA code before compiling.

 

I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control.  Can't be done.  I find this very useful to make sure that my RT system and my FPGA code have the correct versions.

 

Same as with an about box, or version checking for compatibility.

 

The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform.  Not useful for RT linux or Mac.  The version is not available until the executable is built which does not work for FPGA.

 

At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP.  (Then select them all and set their values to default, hence the other suggestion about right click)

Probes are so useful for debugging, but monitoring them within the Probe Watch window can be a headache. I constantly find myself focusing back and fourth between Probe Watch and the code to translate a probe number to a position in the code. A solution would be to have the probe's value float just above the probe itself. LabVIEW already has a similar feature. When you use Highligh Execution wire paths display their current vaules, but using Highlight Execution is too slow and no practical for every debug situation.

 

Here is the issue as it stands today:

probe_watch_window.png

 

Here is my proposed new feature! :

probe_text_annot.png

 

I have a rather large string indicator for displaying operator messages/alarms

and I would like to have the option for an automatic vertical center of the text,

so that all messages get displayed in the center of the screen (if too many lines, justify to top and display the scrollbar).

I also have a 2 line statusbar, but displaying a 1 line message that is not vertically centered, looks very strange.

 

The work-around I'm using now is to display the multiline string centered in a picturecontrol,

but I'm not a big fan of this fix because there are many boundary-conditions to keep in mind ...

 


 

Another annoyance is that to prevent selection of text in the indicator I often disable the indicator

(it looks unprofessional if an indicatortext can be selected in the GUI),

but if the displayed text is larger than the string indicator, the scrollbar is also disabled !?!? 

and therefore not controllable by the user

 

When working with binary data it is often useful to parse off "chunks" for stuff like header data and proceed with parsing the rest of the data. I appreciate the fact that the "Unflatten From String" node makes it easy to do exactly that using the "rest of the binary string" output. Let's add it to the similar "Flattened String To Variant" node.

avogadro5_0-1677885367432.png

 

When programming with large applications, often times you'll have clusters carrying a lot of information.  If you hover over the cluster wire and observe Context Help, you might see something like this:

ContextHelpOriginal.PNG

 

This Context Help window above is rather large and doesn't necessarily make it any easier to see the structure or contents of the cluster. My proposed idea calls for the ability to expand or collapse the cluster contents within the Context Help window, such as this:

ContextHelpNewIdea.png

 

What do you think?

 

NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas (http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas/tab/most-kudoed) 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.

Imagine you save a new VI and LabVIEW automatically creates a suitable icon based on various information, such as the VI name, library, class and documentation.

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

Hello,

 

I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).

 

But many VIs written by NI have been programmed very sloppy.

 

Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:

 

spreadsheed_file.PNG

 

Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.

 

Regards

Hi folks,

 

While disconnecting terminals, the amount of context menu selections can be cumbersome.

I'd like to propose that for disconnecting a terminal it'd be nice just hold down ALT or another key, followed by a left click to disconnect a terminal.

 

That would save users from repeatedly doing this:

Disconnect this Terminal.png

 

Thank you,

 

Mr. Jim

 

Data Type Representation Pallette

 

Can the the options on the data type Representation pallette be changed from grey to match the color of the numerical icons and terminals?

 

Thank You!

Melissa McQueen

As shown by below RG code, the Select function should be redesigned in order to align the s input with the output vertically. Currently, the input is too low.

 

Select.png

I'd like to suggest to add a small button to the header of a disable structure.

Clicking to this button would enable the currently visible case while all others should be disabled automatically.

 

quick-enable-button

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 don't know how many times I've built an application or packed library during my 25+ years using LabVIEW. What still annoys me extremely much is when the AppBuilder gets a tiny error, like "wasn't able to copy this file" (always at the END of the job), or something else having no effect on the (already built and completed) application or PPL itself. Still AppBuilder deletes the whole build, sometimes 30+ minutes time wasted, and simply tells you the build "FAILED". 

 

My suggestion is: Make AppBuilder just a tad smarter and don't delete the EXE or PPL! Just let the developer know what file(s) to copy manually, or what post action didn't work! 

Just as for Clusters, I would like to be able to change a Map constant on the Block Diagram to be viewable as an Icon when it has been made a TypeDef.  You can't directly edit the constant data, so for me it doesn't make it worth the large amount of real estate that it can take up, especially if you have a Map of Maps/Sets.

So for example, instead of this:

I would like:

 

Current Behavior:

When using the "retain all errors" option of the Merge Errors function the combined error message JSON output is not a valid JSON string.

This is the source output of Merge Errors when retain all errors is active - it is not a valid JSON string.

 

<JSONErrorMultiple_1.0>[{
    "status": true,
    "code": 111,
    "source": "This is a test message including\nnewlines"
},{
    "status": true,
    "code": 222,
    "source": "This is a test message including\nnewlines"
}]

 

 

Desired Behavior:

Make the combined errors source string a valid JSON string so that it can be parsed by other tools.

Valid JSON string:

 

[{"status":true,"code":111,"source":"This is a test message including\nnewlines"},{"status":true,"code":222,"source":"This is a test message including\nnewlines"}]

 

 The above JSON string can be formatted nicely by most tools - e.g. JSON pretty print - https://jsonformatter.org/json-pretty-print

 

The below string including the JSONErrorMultiple_1.0 key (but formatted correctly) also works:

 

{"<JSONErrorMultiple_1.0>":[{"status": true,"code": 111,"source": "This is a test message including\nnewlines"},{"status": true,"code": 222,"source": "This is a test message including\nnewlines"}]}

 

 

Codewars - Achieve mastery through coding practice and developer mentorship

 

What language is missing in this list??

wiebeCARYA_0-1662972904604.png

 

Codewars for LabVIEW should be mostly community driven, but NI would have to set it up.

There is a strange asymmetry in the conversion pallet:

heel_1-1628866756838.png

 

I cant see any reason why it is not supported to use the type conversion on an array of FXP when it is on an element. It should be either none or both.