LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Auto index by row or column

Hello,

the current functionality doesnt allow to asynchronously call a method that has any dynamically dispatched inputs. This causes a need to create a statically dispatched wrapper around the dynamic method which then can be called.

This is a source of frustration for me because it forces you to have code that is less readable, and this doesn't seem to be any reason for having functionality like that. Since you allready need to have a class loaded in the memory to provide it as an input for the asynchronously called VI why not just allow to use dynamic dispatch there (the dynamic method is allready in the memory).

How it is right now:

Solution: Allow to make asynchronous calls on methods with dynamic dispatch inputs.

Please address the problems/shortcomings when setting file security permissions in Windows File I/O. The current Get Permissions and Set Permissions File I/O vis do not work.

Currently when LabVIEW creates a file it assigns the default security permissions, which are inherited from the parent directory. This is a pain as the current user is allowed, in general, read and write access, but other users are potentially only granted read access. For example, creating files in the public application data directory (as the sample projects demonstrate for storing settings) means that only the user who first created the settings file can update its contents, whilst other users will get a file permission error.

At minimum, I would like to be able to specify what kind of access other users should have when creating a file. Better still, I would like to be able to get and set security info. Currently I am forced to call functions in advapi32.dll to set acceptable permissions (e.g. GetNamedSecurityInfoA).

I am not the first person to encounter this limitation (see, for example, https://devs.wiresmithtech.com/blog/config-files-in-labview-locations/).

Please add to AF:
Ability to seamlessly communicate over the network and create your own queue specifications. For example actors should be able to talk between physical systems. Using the Network Actor is not a good solution, because it is simply to verbose and difficult to understand. The philosophy of AKKA should be embraced here "This effort has been undertaken to ensure that all functions are available equally when running within a single process or on a cluster of hundreds of machines. The key for enabling this is to go from remote to local by way of optimization instead of trying to go from local to remote by way of generalization. See this classic paper for a detailed discussion on why the second approach is bound to fail."

Anti-Alias or Smooth Intensity Plot

The Application refnum method "All VIs In Memory" returns a list of VIs. This list includes the instance VIs created by Express VI nodes. This list includes private data controls of classes. It does not include the clones of reentrant VIs.

It would be nice to either add some parameters to this method or add some new methods to get some different behaviors, including:

"VIs In Memory That Actually Exist On Disk" -- would not include instance VIs or private data controls

"Really All VIs In Memory" -- would include the reentrant clones

These are the two I most commonly wish we had. There may be other commonly used variations that would be worth including.

View All (1)

When you wand to exchange a VI with another VI (which you do very often when you put VIs of one class into a case structure - to program modular - and don´t want to wire all stuff again, like errorwires or instrhandle wires), you have go a long way through the context menue all the time. I would suggest to add the menue item "Replace with VI" on the top menue.

Example:

old menue path: Replace -> All Palettes -> Select a VI ...

NEW: "Replace with VI"

New Inline Code Node

In my opinion VI Properties/Execution is the wrong place to decide if a VI should be inlined or not. It should be on an individual instance basis, hence I suggest a new Inline Code Node:

or or or

You should be able to either drop a subVI as usual, or you can drop that subVI into an Inline Code Node if you want it inlined. The new Inline Code Node doesn't have VI refnum inputs, as the definition must always be static (to allow for the compiler to inline the code at edit time). With an Inline Code Node you can inline existing subVIs, no matter their inline setting. It is you who programs the caller who knows if it makes sense to inline the subVI or not.

Since execution of inlined code differs quite alot from an ordinary subVI (and possibly even more in the future), it will make sense to highlight this difference with an Inline Code Node.

An Inline Code Node would also make it possible later to remove the synchronization barrier that is in place in the current inlining implementation, since when you debug with execution highlighting enabled, it should no longer be surprising if the Inline Code Node runs before any inputs are ready, nor should the asynchronous behaviour of IO surprise (since that's the defined behavior, and has to do with the Inline Code Node and not the subVI you've embedded in it). If you can step into such an Inline Code Node or not when debugging, would be up to the debugging capabilities of the version of LabVIEW you use. Maybe you can't do that now, but it might be possible in LV 2015 (just as it maybe would be possible to step into a Call by Reference Node at that time?).

Cheers,

Steen

Data-flow visual improvement

One ugly way i usually have to code is

A better way would be to be able to wire, a wire to every function.

This wire will carry data, but it will not pass them in the middle function. It will be a bump input-output, just to determine which function to be executed first. There should be an indicator, when this dump input-output is activated. It can be activated with right clicking on the icon.

This wire should be able to be, a dump wire without any data so you can impliment this

The images way not be so nice, but that's the idea..

Fix XControls

Ok I'm going to try again.

I've already posted ideas on XControls before HERE and HERE but here's another try.

My feeling is that XControls COULD be a wonderful addition to the LabVIEW universe. However....

1. XControls are kind of weird. The implementation is kind of unusual and I finf the help available being not overly helpful. I HAVE implemented XControls but I find myself having to re-scratch my head every time I take on such a proposal. I would love a more intuitive way to work with XControls. Even a state diagram showing what's called when would help.

2. XControls are buggy. I've reported on these before but NI seems to not take this seriously. There are two issues which make XControls unusable for me (I'm willing to overlook the complexity).

2a. Synchronicity. Updating a value to an XControl terminal will return control to the calling code IMMEDIATELY event hough the XControl may require some time to process tha data. This is completely inconsistent with existing LabVIEW behaviour.

2b. Dynamic events don't work properly with XControls. If I register for a dynamic event in an XControl, firing the event will not "awaken" the XControl but the events will queue up until a valid event DOES happen at which point all the backlogged events get processed in a hurry.

If points 2a and 2sb w2ere addresses, 99% of my problems would go away but at the moment, XControls are just not worth the effort for most applications I could otherwise use them for.

Come on NI, you can do better.

Shane.

I find it rather depressing how so many of the new user questions contain code that is just a big Stacked or Flat Sequence structure.

I understand that we need to leave the Sequence Structure there for compatibility with old (poorly written) programs and the very few places we still have to use it...

But it's beyond time to deprecate it.

Warn users with a pop-up or the big red X like the old "Write To Spreadsheet vi" or something that this is an old outdated programming structure that should not be used in new programs!

View All (4)

The conditional disable structure gives the developer to create multi-function applications. However, right now in order to build these applications into different executables the developer must go in and change the project conditional symbols and then re-build the applications and hopefully remember what the symbol states were when the application was built. It would be great if during the application build process the conditional symbols could be set. This would allow the developer to create multiple build specs for each different implementation of the application. An example is shown below:

View All (3)

I would like to use this pattern for launching an asynchronous VI:

The specific use case here is to run a specific subVI, but not have to wait for the subVI to complete (i.e. to launch a daemon-like VI).

There are a few advantages to this method:

1) The Static VI reference makes it very easy to open the VI that is being "launched" and make changes.

2) If I change the connector pane of the Asynch VI, the Asynchronous Call By Reference Node updates or indicates that I broke something (like a regular subVI would).
3) The Asynch VI is automatically included in deployed code (exe's, TestStand deployments), because of the Static VI Ref.

The main problem I have is that I can't determine at run time if the VI is already running or not. That's because the Static VI Reference causes the Asych VI to be "Reserved for Execution" when my launcher VI runs, and always report "Running" for the Execution State. In the case structure above, I can't take meaningful action based on the ExecState (like don't run if already running), because the returned value is always running.

This idea proposes that the Execution State property (or some new similar property) be expanded to truly tell us whether a VI is actually running or not (regardless of whether it is a subVI, or reserved for execution somewhere). Since the "Run" button is capable of showing this difference, there ought to be a way to programmatically access that state information.

View All (1)

Resizable Max & Min

View All (1)

Add data types: table, frame

Languages like 'R', 'Python', and MatLab (yes I use the old name) have these. They are useful.

One of the key ideas in LabVIEW is that the user needs minimal interventions to code a useful result. As more information is encoded in a data type there is more opportunity to make "hands free" code that "just works". I think these two data types can do that.

Data Frame:

Primary data type in R
It is Array-like, but NOT an array
- each column contains one measurement (row) on one variable
- It acts like a list of vectors, but the vectors have the same number of rows, and indexing allows a return of all or subset from all columns
- column types are heterogenous - they can be different
- column types can be set. A column of 0 vs. 1 can be set as factors/binomial values or as continuous.

There are functions that data analysis folks do every day that are informed by variable type, so the function operating on the inputs doesn't need type specified because it is interior to the table. This means you can say "plot(mydata)" and if your data is set up well, the graph parameters are already specified and useful.

Some references:

Data table:

This is from Hadley Wickham, a very famous person in 'R'. He does great work, and his name has high brand value in data-analysis.

It:

Uses the "data.table" package
is able to be screaming-fast (think roller-coaster) especially when used with the "split-apply-combine" approach to data analysis, and SQL-like operations.
is built for handling huge data (100GB tables) quickly and efficiently.

In many applications the same operation is not possible due to memory constraint or viable due to processor overhead can execute adequately (aka wonderfully) by using this data type on the same hardware.

References:

View All (2)

LabVIEW Idea Exchange

Auto index by row or column

Allow Dynamically Dispatched Methods to be called Asynchronously

Address problems/shortcomings setting file security permissions in Windows File I/O

A Native Function to Preallocate Memory in a Queue

Improved debugging features like MGI Monitored Actor

Ability to seamlessly communicate over the network and create your own queue specifications.

Anti-Alias or Smooth Intensity Plot

Give "All VIs In Memory" some parameters or create alternative methods

Make VI replacement more comfortable with "Replace wth VI" menue item

New Inline Code Node

LabVIEW Version conversion tool

Make ctrl+click swap the wires on the top and bottom terminals of "In Range and Coerce" function

Data-flow visual improvement

Fix XControls

Deprecate the Sequence Structure once and for all

Better Application Builder - Conditional Symbol Control

More Specific Execution State of VI Reserved for Execution (is it actually running?)

Resizable Max & Min

Show buffer allocation pop-up detail

Add data types: table, frame