LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
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

 

the input value of the conditional terminal should  " pass through "

 

                  (like the "case selector" of the "Case Structure")

 

 

                    xxxxx.png

 

                                                         like this,

 

                    yyyyyy.png

There is a method how to call a .exe with Parameters over the  ( http://digital.ni.com/public.nsf/allkb/17C3AD70493CE0208625666A00763364?OpenDocument)

But there seems to be no Way to give a Value to Return to the cmd as ReturnValue.

In C this would be expressed instead of

void main(void)

as 

int main (char *Args[])

{

return = x; // returns X as return value back to cmd

}

or similar.

 

The only way to do this now is to write a C DLL wrapper around the Exe and call this one to get a custom Return value. This is not very comfortable when you choose LabVIEW in order not to have to write in C.

Instead this should be included in the Build Specs just like with the Arguments. The Datatype and Data to be returned should be specified via Property nodes, and the Value should be passed back up to the CMD when finished.

BuildSpec.png

This is handy when using Batch scripts.

This has been brought up long ago, but I thing it deseves to be discussed here in the Idea exchange.

 

There are situations where it might be beneficial if we could have a string datatype that has a defined length. Arrays of such string would be stored flat in memory.

 

Application would include:

  • Typecasting a long string to a string array where the element is fixed length would slice up the string into an array of equal length strings.
  • Reading a binary file as an array of fixed strings would do the same.
  • ...

 

The default value would be a string of the defined lenght filled with \00. Shorter inputs would get padded with \00

Of course certain operations would drop the length, e.g. when concatenating such strings, the length would get dropped from the result, turning it into a plain string.

By default, when you build an application, the front panels of all VIs are removed.

 

Of course, this would make applications completely unusable, so there are certain changes which cause LV to keep the front panel in, such as setting the front panel to open when the VI is called. This gives LV a clear indication you want the front panel and these changes are generally enough for most of the VIs which people use.

 

There are, however, times when you want a VI to keep the panel, but it's a VI which usually (or sometimes even never) won't be displayed. Today there are several ways to handle this case.

 

 

The official way is too flimsy:

 

Keep_FP_AB.png

 

 

It's limited to specific build specs and it's too easy to break (e.g. remove the VI from the project and add it back).

 

 

 

 

The automatic way relies on additional changes you're likely to make if you intend to show the VI, but is also too easy to break:

 

Keep_FP_Property.png

 

Someone could just unset the property and then it's gone.

 

 

 

 

What I usually today is something like this:

 

Keep_FP.png

 

The static property node ensures the FP will remain and the comment makes it less likely that someone will remove it.

 

 

 

 

What I want to see, however, is something more explicit, possibly in the shape of a new VI property:

 

Keep_FP_New_Property.png

The "Convert Instance VI to Standard VI" right-click option on malleable VIs made me think if this technology could be used for debugging otherwise inlined VIs (and therefore also malleable VIs)?

 

VIM Convert.png

 

VIs are obviously inlined without their block diagrams, so my suggestion would require two changes:

 

1) 'Allow debugging' must be settable in combination with inlining in VI Properties >> Execution.

2) LabVIEW IDE and RTE would have to call inlined VIs in different ways, depending on this setting. Suggestion follows:

 

Running in the IDE

The IDE would now create a temporary unique instance for each running inlined subVI that has debugging enabled. This would allow us to double-click on an "inlined" subVI while it's running, and have that temporary instance open up ready for probing. Settings like the 'SubVI Node Setup' dialog would now also be available for inlined VIs, if they have 'Allow debugging' on. Set 'Allow debugging' off and inlined VIs will behave as today (so no change for any existing code).

 

Running in the RTE

Executables are built with 'Enable debugging' either on or off (Advanced page of the Application Builder). I suggest that Application Builder builds in unique instances in place of debug-enabled inlined VIs when 'Enable debugging' is on, and bakes in ordinary inlined code when 'Enable debugging' is off. This would allow us to debug into inlined (and thus also malleable) VIs inside executables with remote debugging. Loose VIs called with the RTE would have had their inlined callees compiled with either debug capability or not, depending on their 'Allow debugging' setting as discussed above in "Running in the IDE".

 

What do you think - would it be nice to be able to debug inlined VIs?

I would like to propose the use of a stacked parallel execution structure.  Especially in FPGA applications, this will solve the problem of diagrams running off the screen.  All execution pages will run simultaneously as if independent while loops were scattered across the BD.  This idea potentially leads into a 3 dimensional visuallization of coding LabVIEW. Note: In the image, the pages are offset but should look similar to a stacked sequence structure.

 

 

Parallel Execution Structure 3.JPG

 

 

In LabVIEW if I want to use a property/method of a control I have to right click and select property. Same for second control I want to use same property I have to do same operation again. My idea is if we select all the controls and right click, some common property like value, visible and etc..... Should display and by selection it generate automatically. This can reduce my application development time.

 

 

Multiple Control Selection.png

 

So if this key feature is there in LabVIEW we can select multiple controls or properties and perform some basic operations to reduce our application development timing.

 

Thanks and Regards
Himanshu Goyal | LabVIEW Engineer- Power System Automation
Values that steer us ahead: Passion | Innovation | Ambition | Diligence | Teamwork
It Only gets BETTER!!!

I finally found the time to download a trial version of LV2012. I find that the new 2012 features are really useful and interesting. Good job NI! Smiley Very Happy

One of the greatest for me is definitely the new "concatenating tunnel mode".

I've noticed that it cannot be activated with a variable of scalar type, and this obviously makes sense for almost every type of variables. However, strings are only formally scalar variable. I have lots of VI where the concatenate string vi has exactly the same use (on strings) that Build array has on numerics type of data, particularly when the concatenation had to be conditional. Obviously it is possible to convert the string into a U8 array before to connect the wire to the tunnel, and reconvert it into a string out of the loop, but this convertion probably can be internally managed without too much effort.

The attached snipped can show you what I mean. So, in my opinion, if tunnels could accept strings also when in Concatenating (conditional or not) mode would be great.

Cheers.

Didn't find this idea posted, I think it's a must.

 

It would be very usefull for MulticolumnListbox Item Names in which we need to change cell values...

inplacepropertynode.png

Right now we can make a conditional disable structure that behaves one way if we the VI is running in the Run-Time engine or not.  What I think would be useful is if we could also decide on performing one case or another based on the version of the Run-Time/Development of LabVIEW.

 

Say I develop some neat little reuse VI that relies on getting the name of the label of data type passed in.  OpenG has a functional already that does this called Get Data Name.  NI has a version as well in vi.lib called GetTypeInfo.vi.  The problem is in 2011 the OpenG method is about 10 times faster, but in the 2013 version the NI version is 10 times faster.

 

Wouldn't it be nice if a conditional disable structure could choose to do one thing over another, based on the version of LabVIEW it was being run in?  This way reuse code could be written to perform best in what ever version it was running in.

 

There are many situations were one code written using some function either runs slower or faster in different versions of LabVIEW and using this we could choose the best option for that environment.

 

Of course there is a work around and that is to read the App.VersionYear property, put that into a case statement and perform different code for one version or another but this has added over head, and is called every time it is needed.

 

EDIT: Also the App.VersionYear can't be used in inlined VIs because it is a property node which a conditional disable can be used.

It would be better if we could probe the auto indexed tunnel while the for loop is still executing.

 

If the For Loop is running for a huge number of iterations and if the Auto-indexed tunnel is having a condition. Then to check the values in the conditional auto-indexed array should be made possible even when the for loop is still running for debugging purpose.

 

If something like the below can be done it will be helpful in debugging.

For Loop Tunnel Probe.png

This is a simple suggestion regarding returning all variant attributes from a variant in the correct data type if the name is left unwired but the default value is wired.

 

As you probably know, if you leave the name and value terminals unwired the "get variant attribute function" will return an array of names and variants for all of the variant attributes. If you wire the name or the default value then the node will adapt and return only a single value with the 'found?' output.

 

Here is a diagram to show you what I'm talking about:

2015-02-18_11-55-39.png

 

Currently, if you leave the name unwired but wire the default value this results in a broken block diagram.

 

The reasons for this suggestion are as follows:

  • Cleaner block diagrams - if you know all of the variant attributes are the same data type then you save the extra constant/variant to data node
  • Possible performance improvements - maybe NI does (or can do) something to improve the performance/memory allocations if the data type is known and can be done within the SubVI
  • I can't see a case where it would break compatibility other than perhaps a broken block diagram would no longer be broken if the default value was wired but not the name but the runtime functionality would remain the same
  • As variant attributes are a very efficient and recommended way of doing key/value lookup tables I think this minor change will tidy things up nicely and if there are performance gains to be had under the hood by doing this then all the more reason to do it!

Thanks for reading and hope you'll +1 my idea!

 

 

So many times, Darren's history probes have been a great help while debugging my code ! This concept may be enhanced. But at least, these probes should ship with the LabVIEW installer.

A pretty common use case of LVCompare in my workflow is to use it as a diff tool in SVN to compare different versions of a VI. When I do that, the previous version is downloaded into a temp directory, and then there is a decent amount of load time because dependency paths have to be resolved differently for the version in the temp directory and some recompiling happens. For top-level VIs in large applications, it seems like the whole dependency tree is getting loaded, which takes a long time. But really, for comparing VIs, there's no need to load the contents of lower level subVIs (and their dependencies, and dependencies of dependencies, etc.) As long as the connector pane, typedefs on the connector pane, and the icon of a subVI are loaded, that should be enough information for a visual diff of the top level VI.

I would like to have an XY Chart that has the same functionality as the Waveform Chart, but with x and y inputs instead of just the y.  The XY Graph is not efficient to be used inside of a loop, mainly because it redraws the plots each iteration, and I've had a hard time trying to make a buffer that is as efficient as the waveform chart.  The Waveform Chart does not allow you to define the x-axis as anything that is not an interval.  For example, I might want to plot pressure vs. flow rate.  Many customers also request the ability to change the sampling rate during an experiment.  this would be much easier to handle with an XY Chart.

It would also be nice to have the buffer size included in a property node.

It would also be nice to have the ability to change the size of the graph palette.

It would also be nice to have the nearest plot coordinates (x and y values), or interpolated values, to mouse movements over the plot area as a "visible item" in the shortcut menu (this should show a dot over the plot's trace)...  I've done this with an X Control, but I'd like the ability built into the new XY Chart on a lower level to improve effiecency.

 

Currently, if you use the stock one and two button dialog VIs in your code, they will block the root loop while being displayed.

For those of you who don't know what the 'root loop' is, this is the core process of LabVIEW that many UI functions must execute under.  One of the key functions that executes in the root loop is VI Server calls to open a new dynamic VI.  So, if your code has multiple threads all performing operations that involve dynamic calls to other 'plug-in' VIs and one part of your code calls one of these stock dialog VIs, then all the other threads will be blocked until the user clears the dialog.

As a result of this, I have had to write my own 'root loop safe' versions of these dialogs to prevent this from happening.

 

As a side note, dropping down a menu and leaving it down without selecting anything also blocks the root loop.  It would be great if they could fix this too!

 

 

 

This should work!! I know there are workarounds and I have used them but it would be much easier.  

atsrefdsfads.png

 

On Windows, you can define environment variables that auto expand to known directories. There are some variables that are already defined by the system. For example, %TEMP% automatically expands to c:\Users\<username>\AppData\Local\Temp OR WHEREVER THE USER MOVED TEMP DURING INSTALLATION. That's the important part .That makes it possible to write %TEMP%\abc as a symbolic path that works regardless of how the system gets reconfigured.

 

Users can define their own environment variables, and those get expanded when used in a path in the command line or Windows Explorer (the text entry region at the top of an Explorer window). On Linux and Mac, it is the equivalent of using $VARIABLENAME/abc, where VARIABLENAME is some user-chosen name.

 

[admin edit] Added background information on environment variables, and updated title to use the word "Environment" instead of "Environmental".

In the Context Help for the Prompt User for Input Express VI (Functions palette » Programming » Dialog & User Interface), it says that you can use the VI to prompt the user for a password.  However, there is not an option for a "password" data type when configuring the VI, and thus any curious onlooker would be able to read your password if this VI was used!  Why not add a "password" type to the configuration options (see picture)?  Sure, you can build your own VI to do this already, no problem, but it still kind of makes sense to have the password data type as an option.

 

passwordinputdatatype.png

This is sort of two features bundled together, but they make sense to do them at the same time.

 

First, add an easy way to temporarily disable the "Allow debugging" VI property across an entire project.  This would be step 1 in making an easy "Release Mode" option.

 

Second, add some conditional disable symbols to all projects.  If the project is in debug mode, add "DEBUG_MODE" to the project, and if it's in release mode, add "RELEASE_MODE".  While it is possible to do this manually now, each user could choose a different name for their symbol.  If LabVIEW does this for everyone, then it allows better library interoperability.  The main use case for these symbols is to add debugging traces and breakpoints that are undesirable in shipping code.