LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Clear specific error

Good programming practice says to handle your errors. If you want to clear a specfic error, you have to do some variation on the following code:

Since this can be pretty cumbersome in your code, I would love to have a Clear Specific error VI/function that will do exactly this. It can also be polymorphic and accept an array of multiple errors. To make it even better, you could probably merge it with the existing clear error VI and set it up where if the error input is empty, it clears all errors.

CaptainKirby made a nice community example that does all this, but I'd like it to be on the palette for everyone to use...

https://forums.ni.com/t5/Example-Code/Clearing-a-Specific-Error-From-The-Error-Cluster/ta-p/3517242

It is common, in writing reusable code, to handle arbitrary clusters in variants. To access the elements of the cluster, one wants to convert the cluster into an array of variants containing the individual items. After access, one needs to convert the array of variants back into the original cluster.

There are several examples of packages that use this on NI.com and in the LAVAg.org Code Repository. They mostly use functions for working with Variant Clusters from OpenG; however, these can be quite slow. Recent LabVIEW versions have had the ability to do much of the functions quicker, however, there is a very imortant missing native ability: to convert an Array of Variants into a Variant Cluster.

The other direction, Cluster to Array of Variants, works like this:

But trying to reverse the process breaks:

So my idea is make the second image work; make an Array of Variants interchangable with a Variant Cluster in the "Variant to Data" LabVIEW primative. The interchangability should apply to contained subclusters/arrays also. The matching of array to cluster elements can be by cluster order rather than element name.

This would greatly aid the performance of reuasable packages that operate on arbitrary clusters.

View All (3)

The current implementation of flattening and unflattening from XML is quite noisy and includes information unnecessary for the users. Rewriting it or including Pretty Print functionality to LabVIEW would greatly simplify loading settings, exchange of data with other languages, dynamic configurations, visualizations of complex systems, network communication etc.

For community solution and examples of these features please go to -> https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Tree-Map/td-p/3972244

This could include also Pretty JSON since XML and JSON are interchangeable -> http://www.utilities-online.info/xmltojson/#.Xc6XjVdKiUk

Additionally the XML parsing should be implemented without requiring Windows .NET platform components, so it can be done on a real-time system. Current XML parsing functions cannot be called on RT.

View All (7)

Under Web Services there is a conversion palette. One of the functions here is to convert LV Image data to a PNG stream. This is super useful when dealing with sending and receiving large amounts of PNG data over something like websockets. I've used this in places where a web page can control a VI, and the image of some front panel controls can be sent to the web page.

However only recently did I realize this function turns the image into a PNG stream that is completely uncompressed. This idea is to expose the Compression input to the VI. Here is just one example where I get the image of a control then represent it as a PNG. With no compression this file is over 64KB. With just the most minimum compression that drops to 3KB, and down to 2KB under the highest compression.

View All (4)

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

View All (3)

Situation:

You want to show a coworker or customer something "real quick" in the LabVIEW. So you open a new VI, open the block diagram, and open the quick drop accidentally because you thought the palettes were already loaded.

DANGIT you forgot that you haven't accessed the palettes since you started LabVIEW. Now you have to resort to awkward conversation defending LabVIEW about how awesome it is, even though it can sometimes be slow, etc, etc. If you decide to skip the awkward conversation and instead try clicking out of the window you see this awful image:

Oh No! Did LabVIEW crash? Is it broken? How long will this take?

Solution:

Cancel button on the windows in question that allows you to stop loading the palettes (or switch it to loading in the background) so that you can go back to work and find your function the old fashion way. Save you time. Save you annoyance. Save LabVIEW some street cred.

The world is a happier place...

Swap Long

View All (1)

Hello LabVIEW Experts.

I am using LV 2017 (Not sure how it works in Recent Versions of LabVIEW). Sorry if its fixed in Recent versions.

Started this thread to share my recent learning/bug.

It all started like this.

One my Engineer was re-architecturing existing LabVIEW Application and it has 40+ States/Cases Defined- Out of which two were identical and he is not able to figure out the duplicate.

We spend sometime to resolve by sorting and finding the duplicate.

Later i was working on the same to figure out why cant LabVIEW Highlight the issue/restrict from adding.

LabVIEW does restricts User from adding identical Items when using Edit Items of Enum Properties.

But it allows me to add identical items when users adds using shortcut/add items.

During this experiment i also found that LabVIEW doesn't allow user to create (Make Type Def) if the items are identical.

The above behavior is perfect but there should be a warning why they are not able to (Make Type Def)

I have Few Points on this.

1. There should be Error Warning/Highlight to make user to debugg where the identical cases located (helpful when more states are mapped)

2.There should the restriction in adding items at all levels (all possible options to add items)

3.There should be an warning why user cannot (Make Type Def) when there are identical items.

View All (2)

It's got to be a duplicate, but I could not find it...

A significant number of vi.lib VIs are still outputing error codes (I32) instead of an error cluster.

For instance, the famous Ramp.vi:

returns an error -20006 if you ask for zero samples. Type in this value in the "Explain Error..." window of the Help menu and you get:

So it's not that the error code is mysterious and cannot be interpreted (I must say I was a bit puzzled by this discussion on error codes).

NI has to fight with this problem themselves. For instance, here is the code you find in the NI_AALPro.lvlib:AAL Resample Filter Prototype Design.vi:

What is that "?!+Magnifier" VI , you'll ask (AAL Error Information.vi, in the same library mentioned above)? I am probably supposed not to post it, but I will nonetheless, considering what it REALLY does:

Yep, it simply returns the same numeric error code value (again) and the call chain for the VI generating the error (but it won't tell you that the real source is the DLL called in the "Kaiser" VI above). I assume (but I can't prove) that the codes returned by the analysis library are among those recognized by the Explain Error VI.

It is not only an annoyance to not be able simply connect VIs using an error cluster wire, it does not make error handling particularly easy (basically, the way I read the answers of Aristos Queue and Norbert_B in the thread I quoted above is: "reverse engineer our VIs if you really want to 1) get the complete list of error codes it can output, 2) understand their cause").

My suggestion: Hire a couple of interns to sift through NI's VI librairies and change error code outputs into error cluster outputs with proper messages.

Obviously, for compatibility reasons, open previous code with an added unbundle primitive which will return the old error code (with a list of warning after the first compilation). You've done that before and we have survived.

View All (4)

View All (5)

View All (1)

timeout control with occurrences

How about having a timeout occurrence as an input for functions which support timeouts?

I am illustrating a single use case with queues (and a notifier) but I would see this as being beneficial to nearly ALL functions with timeout inputs.

Sometimes we'd like to wait for one of a few different functions (an example of mine which springs to mind is the Dequeue primitive). At the moment we must essentially poll each primitive with a relatively short timeout, see if one responded and then handle accordingly. This is (for me at least) ugly to look at and introduces polling which I generally don't like. I'm an events man.

What I propose would be that instead of simply defining a timeout in milliseconds we can define both a timeout (in milliseconds AND an occurrence for the timeout). If we wire this data to several primitives (all sharing the same occurrence) the first primitive to receive data triggers the occurrence so that the others waiting in parallel return also.

In the case where no data arrives, each function waits the defined amount of time but upon timeout DOES NOT fire the occurrence. This would cover corner cases where you may want different parallel processes to have different timeouts (Yes there are cases although they may be rare). It is possible to change the "priorities" of the incoming queues in thie way.

Background info: One example where I could use this is for RT communication. Here we multiplex many different commands over TCP or UDP. On the API side it would be beneficial to be able to work with several strictly-typed queues to inject data into this communication pipe while still maintining maximum throughput. I don't like using variants or flattened strings to achieve this multiplexing.

Being forced to poll means the code must decide between efficiency (low CPU usage) OR response time (setting a very low timeout). Although the CPU load for polling may be low, it's not something I personally like implementing and I think it's generally to be avoided.

There IS a LVOOP solution to this particular problem but not everyone can use LVOOP in their projects (for various reasons). I can envisage other use cases where interrupting a timeout would be desireable (Event structure, wait on ms, VISA read and so on and so forth).

Shane.

It seems there are a lot of NI services that start running directly after logging in to windows. I even tried manually turning them off using msconfig thinking the services would start when LabView was loaded or on an 'as needed' basis, but I was wrong.

The user should have the option of starting services at windows startup or at LabView startup, or even not at all if it is not required. Perhaps this could be added to select the services within LabView's 'Options' menu. An explanation of each service and why it is needed would be great also. With all of the programs that run on our computers these days, the less running in the background, the better.

View All (1)

Add a native File Open event

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.

This is a major showstopper in creating professional applications.

LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

View All (3)

View All (2)

LabVIEW's Query Input Devices uses LVInput.dll to return information about the Keyboard(s), Mouse(s), and Joystick(s). However, it appears that the number of Joystick entries returned is limited to 8, whereas on several machines that I've examined, the "joystick" device can be present in slot 10 (as noted by DxDiag's Input test, which otherwise matches what LabVIEW returns in the first 8 slots).

Can this function, which returns an Array, be modified to return as many entries as the DxDiag utility returns for DirectInput? This would facilitate using multiple joystick-like devices as control units using standard LabVIEW procedures.

Bob Schor

LabVIEW Idea Exchange

Clear specific error

Convert an Array of Variants into a Cluster

Include Pretty XML parsing for map/set/tree data structure

Add Compression Input to LV Image to PNG Data

The Border Nodes on the In Place Element Structure need a "Replace With" option

Custom automatic error handling callback

Cancel load for Quick Drop, Palette Search, etc

Swap Long

Make Trim Whitespace polymorphic and handle an array of strings

Handling Identical Enum Items on Multiple Instance (Add Items, Case Structure and Make Type Def)

error output instead of error code output

Get Date/Time in Seconds with Error PassThru

Add a save file method to the configuration files object.

Make Type Def. should launch the new type def.

timeout control with occurrences

NI Startup Services running in the background

Add a native File Open event

Or (and And) Array Elements should work on numeric arrays

VI Analyzer: Add option to "VI Documentation" to skip .ctl's

Allow Query Input Devices to return all available Devices