LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Opening two VIs with same name

View All (6)

The convolution tools have polymorphic instances for 1D and 2D data.

The 2D instances have a very useful input to control the output size (full, size X, compact).

The 1D instances don't have this input (Why?!). In the vast majority of my 1D convolution applications, I would prefer a "size x" behavior for the output, making the output size identical to the input spectrum, no matter the size of the convolution kernel. If the 1D convolutions would accept this option, performance and inplaceness could possibly be optimized compared to a manual trimming later.

Suggestion:

All convolution instances need an "output size" input, not just the 2D versions.

"To FXP" must accept array data

Create new empty array

When I have an array of clusters and I want to locate the array index where a specific element of the cluster has a certain value, I need to first build an array from the Array of Clusters and then search that to find the Array element I want:

It would be nice (and cleaner and likely faster) if I could wire the Array of Clusters into an unbundle by name function and select String[] to get the array of string element to search.

In addition, if the cluster contained nested clusters, I could access them the same way, using the dot notation alrerady supported. For example, the unbundle would let me select 'cluster1.subcluster2.String[]' to access the subarray of an element.

View All (4)

View All (2)

Both the diagram disable structure and the conditional disable structure are intended to allow easy enabling or disabling of blocks of code. These nodes ought to have no effect on a diagram except to remove or add sections of diagram. But they currently have the side effect of formalizing the blocks of code they surround, as if they were a sequence structure. There are two cases where this is undesirable.

1. Without the disable structure, these two loops would run in parallel.

2. This VI arguably ought to terminate because that wire dependency from the loop to the Stop primitive is only created because whatever is in the disabled frame needs the result of the loop, but the code in the enabled frame does not. But because the disable structure acts as part of the code, this loop runs forever.

This ties into a recent post I made on the NI Forum HERE.

I have already run into this problem a few times.

Somewhere in my code I have a process returning an object of a particular class which does not have the exact same type as a dynamic dispatch input. My post above shows a workaround for this (which, if it wasn't so horrible it'd be funny).

I've run into similar problems where the object is being passed via Queue or Event where I have to pass the Objects as a parent class to enable portability but where I KNOW the only source of the data is a VI sending an object of EXACTLY THE SAME TYPE as the dynamic dispatch input.

A normal "to more specific class" does not work presumably because the resulting object COULD be a further sibling of the required object, thus breaking any dynamic dispatch tables.

Up to now I've had to write a class member to take the existing object and another object of type parent and make a cast and update the values manually which is really annoying because it requires each and every child class to implement this (and make use of the parent function).

So what I'd like is a function to allow an EXACT cast of an LVOOP object so that I can still satisfy the Dynamic Dispatch requirements without having to have a piece of code for each and every child class created. If the Object classes don't match EXACTLY, return an error and the contents of the object used for the cast.

Shane.

View All (2)

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

We need this:

Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.

As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

View All (7)

If you write a multi-purpose sub-VI, it is sometimes desirable to know during run-time, if an input of the sub-VI is connected to some source inside the calling VI or not. E.g. if you have two inputs and you want to do a certain action whichs depends on which input is connected, you have to write a polymorphic VI. Therefore you have to write at least 3 VIs: one VI for each input and the polymorphic VI. With a new control property or method, which tells you if the input got it's data from some source, you could do this with just one VI. There are of course other scenarios where this new feature could be useful.

Regards,

Marc

The current behavior of LabVIEW is as such:

The pick list of event data strips the cluster, only allowing access to the elements inside the cluster. In order to manipulate the native datatype, you must reconstitute the cluster inside the event structure, a performance hit on large data structures firing at quick event rates. This is not to mention a messy FP.

I suggest that User Events preserve the clustered event datatype, allowing the programmer to access to the native datatype on the consumer end. The option to select only the element "Clustered Typedef.Array of I32s" of course still remains, but is not forced upon you. (Note that the below block diagram is NOT a direct LabVIEW screenshot... brought to you by trickery and a paint program. I clustered the cluster on event datatype [not shown] so that the event structure could eat the outer layer)

My motivation with this suggestion is directly linked with my other post on the Big Typedef Issue.

View All (11)

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

View All (9)

Array size via Property node

When developing a utility to traverse any control using VI Server and save its contents to a file (similar to the OpenG utility using Variant) it is quite challenging to find out the size of the array's data.

There are various workarounds, but all of these are relatively tedious and over-complicated.

Why don't we have a "array data size" read only value on the property node of an array?

This would make things MUCH easier.

Shane.

Message Edited by Intaris on 06-12-2009 12:33 PM

This is something that would be a great addition for those of us working on different platforms (i.e. Windows and RT).

When a VI is compiled for a particular platform, add a seperate area to the actual VI file to keep the platform dependent compiled code. This way a vi that has been compiled for use on windows and for RT would have two sectons that keep a seperate copy of the actual machine code for each OS.

Where this issue becomes a problem is when you have common code called from a project that has both Windows and RT components. This creates an endless recompile operation as code is built

As an example:

Code is compiled for Windows.....windows machine code is generated and saved in the vi

Code is opened under RT.....changes pending because the compiled code does not match the platform

Recompile vi for RT....RT machine code is generated and saved in the vi.

When the code is reopened under Windows, it requires another recompile due to the existing RT machine code.

Obviously any changes to the FP or BD would cause all of the machine code areas to require a recompile.

This would add more size to each individual VI, however disk space is relatively cheap with respect to LabVIEW development systems.

Asyncronous Call By Reference

Here is an idea that I have wanted to make happen for a while. It is the Asyncronous Call By Reference. Basically, it is just a Call By Reference, but split in half so that the call is not syncronous (blocking), and return data can be obtained from multiple locations. Plus, there should be ways to check the status of the asynchronous call and kill it. I've even implemented this, to some degree, here http://forums.openg.org/index.php?showtopic=88

Message Edited by Jim Kring on 06-10-2009 08:14 AM

View All (2)

If you want to fork a VI (start a parallel running VI), you have to load the VI reference, use the set control elements values method to initialize the controls of the VI, and than start it with the run VI method without waiting to finish. Quite complicate, if you ask me.

It would be cool, if there would be a fork VI method, which you call inside the VI you want to fork. The method copies the VI to a new place in memory including its actual running state. The new copy just goes on as it would without the fork, while the calling VI would get back the values of the ouputs, which they have at the moment of the execution of the fork method. Of course this does only work with reentrant VIs.

I can think of a LOT of applications which can use this!

Regards,

Marc

View All (2)

LabVIEW Idea Exchange

Opening two VIs with same name

Add a Terminal that Defines Default Data for Reshape Array

Output size configuration for 1D convolution

"To FXP" must accept array data

Create new empty array

Allow access to subarray from array of cluster elements by array and dot notation

Defer panel updates from within property node

Both disable structures should have less effect on diagram synchronization

Give us some way of FORCING a specific LVOOP cast

In "Sort 1D array" node uses can get both ascending and descending ordered elements

Select several controls/indicators and right click to combine them to a cluster

Allow a quick "Timing Probe" for Timing Metrics

New property of Method to indicate, if an input of a sub-VI is connected to some source inside the calling VI

Allow Dynamically Registered User Events to preserve Native Datatype in Event Structure

Allow Data in Wires to be Forced During Development

Array active index via Property node

Array size via Property node

Allow platform independent compile operations for all VIs

Asyncronous Call By Reference

Add "fork VI" method to VI method nodes