You can search for the "NaN" string and it will find all the NaN constants (plus all the occurrences of the "NaN" string).

You can search for all other constants (pi, machine epsilon, +/-Inf, etc.), but not for the NaN constant, which is just a numeric constant with NaN typed in it.

You can search for ALL numeric constants, but not for a specific one, say "1". Of course, you can search for all "1" strings in your code, and the constant 1 will show up among the search results, but it will be hidden in a long list of irrelevant results.

And try to search for a constant with units... You can't. What would be nice is to look for a constant irrespective of its unit, as for instance 60 s = 1 min. Did I encode that time constant as 60 s or 1 min? I need to search for 60 AND 1 to find out.

I'm trying to figure out a way to achieve something that seems a little bit tricky. In fact, the problem I'm having might be a bug. Basically, I want to use the tree control's Allow Dropping Between Item feature (a built-in drag and drop function) along with the tree's Drag Over event which allows you to programmatically enable/disable the user's ability to drop the item that they are dragging. Here is what the Allow Dropping Between Item feature looks like:

The problem is that whenever I register for the Drag Over event, the Allow Dropping Between Item feature/behavior goes away.

Here is an example of the problem:

Download File:post-17-1156820022.vi

FYI - I've tested in 8.0 and 8.2 and this behavior is the same in both versions.

Thanks :-)

i'm thinking about a solution to write a comment on each line in a config file. I know there is no explicit standard for comments in a line but there are some usual solutions.....

[info]

Project=test #[Project name....]

Date=2007_09_27 #[YYYY_MM_DD]

Is there a chance to implement comments like that in the line of each entry?

Thanks

Claude

There is a video linked in that post that pretty simple shows the behaviour. It is quite nice to use.

If you like it please add your kudo on the Idea Exchange!

Indeed, the Block Diagram... erm... the Mother of All Diagrams... does not have a Subdiagram label property. I say this is a grave injustice.

So anyhow, I wanted to share the paternity of this idea because without his enthusiasm, it would not be there:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Subdiagram-label-for-Block-Diagrams-too/idi-p/4033465

If you like it, please vote!

Actually the proposed wire is only typeless in the diagram of the VI concerned. As soon as the VI is placed somewhere as a subVI, the connections made to the VI determine the actual type of the wires inside the VI. For example, you could make a VI with a typeless input and output, place an array resize function in the VI that resizes a connected array to be able to set an element (as in picture above). It would work on any 1D array that is connected. Whether the VI is compilable or not depends on the type of wires that are connected where it is placed. The type of a typeless output terminal is also determined by these connections.

To keep the behaviour similar to normal VIs, the VI should lock like any other VI, so that only one instance can be running at a time. Extra code will be generated for the type of wires that are connected. There should not be completely different instances of code for each type, because a great part of the code can be shared between different types. The compiler can insert a branch instruction when a typeless wire is reached, to jump to the code required to execute an action for the wire of the specific type.

If you would connect a typeless wire to a shift register, each type would generate its own instance of the shift register. However, if a normal (typed) wire is connected to an another shift register in the same VI, that shift register is shared between all types. That way you could for example create a "generic" storage functional global.

To be able to do different things for different connected types, the case structure could be used to switch between the various behaviours. It would then switch based on the wired type. E.g. if you create case frames for a DBL and a Boolean, the VI is compilable for those types. The wire is available in the case frame as of this type. It would allow you to return a string for both a double and a boolean: "3.14" and "True". If a type is connected to a typeless input of the VI for which there is no case frame, the VI is not compilable.

This mechanism as an alternative to polymorphic VIs. Polymorphics require multiple VI's, with often identical diagrams, which causes code duplication. Untyped wires allow to have only a single diagram for multiple types. They are easier to manage and understand, give smaller code and don't require all the types to be known and implemented beforehand.

Something for LV9 ?

Joris

This would be a big time saver as 90% of the time when you don't want' indexing', you want 'Last Value' MUCH less cumbersome than 2 menus deep right click selections.

Same logic as older one-click True-False Slider constants.

"One Click Nodes"

That way I could get rid of these 3 transpose array functions.

I'm usually not on the cutting edge of thought... something like this hasn't been discussed before, has it?

-James

I have been reading, voting and posting to the idea exchange for awhile and just posted several new ideas/complaints that I thought of while attending NI Week. I challenge all LAVA members to visit the exchange and vote for the ideas you agree with (especially mine ). And if you don't agree, post a comment and tell me why!

Then post your own ideas so we can all vote of them too.

The more feedback we give, the better LabVIEW will be in the future.

-John

Quote

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 

I want to add to the Conditional Disable structure a new built-in symbol that toggles when the VI's "Debug Enabled" setting is toggled.
I've wanted this for a long time, but I finally got around to opening up the code to see what's possible.

Let me take care of one question right away: I have no idea what version of LabVIEW this might or might not go into. So don't get excited. :-)

Anyway... it turns out, what I'd like to do isn't straightforward. All existing conditional disable symbols are global to the application instance. The three built-in symbols -- bitness, target, and run-time engine -- are universal to the running environment. The symbols that users can define are in the project and target. In other words, if I want to know the value of any symbol, I just need the reference to the application instance, not to a particular VI. And, guess what, all the C++ code is therefore oriented around application refnums not VI refnums. *sigh*

Now, it turns out that I can see a way to add the debug-enabled flag in a sort of sideways manner, and I would just hardcode that symbol as a special case in some parts of the code.

RED FLAG! Alert! Developer has used the phrase "special case"!

One of my colleagues likes to refer to the "0, 1, Infinity Rule". That is, there are either zero cases of something, one case of something, or an infinite cases of something. There's never just 2. Or 3. Or any other finite number. Basically, as soon as you are prepping the second special case, your code needs to be architected to accept an infinite number of such special cases because otherwise, you're going to build up a huge number of unmaintainable hacks over time. If there really is just one special case, then the code generally remains maintainable. One special case isn't a hack... it's just the special case of the problem you're code is solving. The second special case is a hack.

I try to avoid hacking up the LV code base and developing more stuff that needs refactoring in the long-term, so I'm hesitating about working on this feature. With this in mind, I went to a couple of other dev and asked a question, and I want to ask the LAVA community the same question:

Besides "enable debugging," are there any other VI-specific settings that would cause you to want to change the actual code compiled into the block diagram?

I honestly cannot think of any. Reentrancy? I don't typically change the reentrancy of a VI on a regular basis. A VI is either designed to be reentrant or not... flipping that switch usually changes how the node is used entirely. Thread affinity? I can't think of any VI where I have ever wanted to sometimes have the VI in UI thread and sometimes have it in Exec System One, and where I wanted different code in those cases. No one else I've asked has been able to come up with any scenarios for that sort of thing either. Oh, the hypothetical COULD exist, but hypothetically, I could want the font on all my numeric controls to become italic whenever the VI is set to "run when opened". It ain't a real use case. :-)

One person suggested that there might not be VI-property-related settings that would want to change out code on the diagram, but maybe there is a case for user-defined symbols at the VI level? Maybe. But, honestly, the Diagram Disable structure pretty much covers the "I want to change out the behavior of this VI". Yes, we all know cases where we have code on the left half of the screen and code on the right-half of the screen, and we need a separate disable structure around those regions... but that's just as probable as having that right-side of the screen dropped into a subVI. The setting then is not a per-VI setting, but it is either a per-project setting (which we have today) or a per-library setting... and that I can easily imagine a use case for. Having a per-VI user-defined setting just seems problematic if you dropped the code into a subVI and lost the link between those two VIs. I hate adding any feature that discourages people from creating subVIs as needed! So I'm rejecting that use case. And the library use case, while a good one, is outside the scope of what I'm asking about today. Go put it on the Idea Exchange if you want to promote it. :-)

Which brings me back to the "debug enabled" setting. That setting can be programmatically toggled when doing a build (if you go into the custom per-item settings because NI doesn't have an easy single-checkbox for you) and frequently we do things while debugging that would just slow down a release build. Which means it makes sense to write code into the VI that could be either compiled in or compiled out based on the VI's debug settting, unlike any of the other settings.

So... brainstorms anyone? And please be honest. Even if you want this specific feature, and you think, "Well, if I present this valid use case, it means he won't put in his hack, so I'm cutting my own throat," trust me... for the long-haul, you'd rather LV develop as cleanly as possible, for the sake of your own trust in it!

I am new  to labview, I am trying to use 3d picture control  so i want to know  in that 3d picture  an arrow line from z-axis should come in picture  and also an angle which shows  from z axis  it should come programatically

 can any one please help me with this

I posted a new article to ExpressionFlow regarding type parameters. For me it is the one of the most missed features in LabVIEW. Check out the post.

Introduction to Type Parameters

EDIT: Seems like the links to expressionlfow still don't work from LAVA. Please copy paste from below

expressionflow.com/2009/10/23/introduction-to-type-parameters/

Tomi

This would allow for multiple build settings that could incorporate into a single project file.

I have the feeling this can be done with separate lvproj files but that feels like a workaround.

Any thoughts on this?

Ton

Currently, if you leave an input terminal unwired, you set it to Recommended and you give the control a default value. That doesn't really mean the user left the terminal unwired... they could have wired the default value. That doesn't really help when, for example, all possible integers are valid values for the input. You end up having to add a second Boolean terminal for "should pay attention to integer?" or something like that. Even when you do have a valid sentinel, you may have to add code to check "is the input value the sentinel?" in the middle of your executing code, which is a small but annoying performance hit, and one that can ooch up over time. Think of how many times we check error input terminals and how much of that code could be dead code eliminated if only subVIs generated code specific to their callers. That's a *minor* example. There are a lot more interesting algorithmic changes that are possible for an unwired terminal... some of the built-in primitives of LabVIEW have very different behavior when inputs are left unwired.

Currently, if you leave an output terminal unwired, LabVIEW doesn't care... the value of that output gets computed anyway when the subVI is called because the subVI has only one code path. This has lead me to have to have extra terminals on input for "should compute output X?". You can fix this sometimes by marking the subVI to be "inline" and then when you turn off debugging, the computation code likely gets dead code eliminated. But not always. If the computation involves a refnum, it won't get dead code eliminated. And if there are interim data structures along the way that you populate, those will still get built up if they're part of a downstream terminal that is wired. The compiler probably (IMO) will never be smart enough to analyze and do that level of elimination until the compiler is sentient. So some sort of computation here would be valuable, I think.

I've investigated this before and always hit some limits. I'm thinking I might make another run at figuring out how this could work. No promises, but there's some new ideas out there on code optimization that I might be able to leverage.

The unwired output case is pretty straightforward... I'm not too interested in unwired output cases unless you have one that is radically different from "this output is expensive to compute so I only want to do this part of this larger algorithm when that output is wired".

I am interested in unwired input use cases.

So as part of my brainstorm on this topic (and to gauge whether or not this would have benefit to users other than myself!), I'm curious to hear about any VIs y'all have written where being able to program in unwired terminal behavior would have been useful for you.

There's no deadline on this. I am just sort of musing on this topic lately. I don't know if it will lead to any LV features. I just want to explore this particular topic more.

In TestStand, when there is a step does not run because of previous condition step like "If", the status of that step will be left as empty. This returns a clear visual affect, in debugging, that this step has not run. But if I have a condition step and another step under this condition. If in the first interval this step ran and in the second interval this step didn't run, it still keep the status from the first run interval.If I just put a break point at the begin of the loop and click play instead of go through each step, I will think that these step ran in the second interval. Should it be better if there is a flag or something indicates that this step did not run at all?

Regards,

Thang Nguyen

Functional programming is often seen as an alternative to object oriented programming. One can solve similar problems of dynamic dispatching either by passing functions around or passing objects with methods around. There are of course multi-paradigm languages supporting both objects and functions like Clojure and Scala. So what would LabVIEW look like if it supported concepts of functional programming paradigm? I posted an article on this on ExpressionFlow and I am intending to study the concept on ExpressionFlow in my future posts. 

Would you use functional LabVIEW if such a language existed?

My post on how a functional programming could appear in a visual dataflow language:

Synchronous Functional Dataflow Programming & Closures of Named Functions

p.s. See Joel's quick intro to functional programming if you are unfamiliar with the concept of functional programming.

That is a very broad definition. Most users know the trivial case: you have a global variable representing some sort of counter, and you have two processes, Alpha and Beta, both wanting to increment the value. If the starting value is "1", then the ending value is expected to be "3". The race occurs here:

• Process Alpha reads the counter: value =1.
• Process Beta reads the counter: value =1.
• Alpha adds 1 to the value it read and gets 2.
• Beta adds 1 to the value it read and gets 2.
• Alpha writes to the counter: value = 2.
• Beta writes to the counter: value = 2.

Oops. But there can be much more subtle bugs. For example:

• Alpha is a Producer Loop
• Beta is a Consumer Loop
• Beta checks "Is the queue empty?" to decide whether it has finished processing all the data.
• At some point, Beta is just a bit faster than Alpha and the queue empties, so Beta decides to quit, thinking it is done with all the data.
• Alpha adds more items to the queue, but Beta never processes them.

Race conditions are notoriously hard for users to catch. They have historically been just as hard for compilers to notice in all but the most trivial conditions. As the LabVIEW compiler has gotten better at its analysis over the years, I see some potential for the compiler to recognize when a bit of memory is potentially being used by multiple execution paths in "a race condition like manner". I'm using that deliberately vague term because the definition of what exactly constitutes a race condition may be part of the conversation here.

If the LV compiler knows beyond a shadow of a doubt that some egregious behavior, such as an unprotected global VI or shared variable being used for read-modify-write in multiple execution paths, should LabVIEW break the VI? Is that a compiler error? Or is it something more like a coercion dot that should be highlighted but not ruled out? To put it another way: Are there race conditions that you have in code that are desirable conditions? Is that because it is just too hard to program the right way? Or do you have some where the correct program really is one where execution order should matter to program output? If the robot's right hand grabs the apple a microsecond before its left hand grabs the orange, are there cases where it is correct for that to affect which one it chooses to serve you for lunch?

In theory, you can have multiple event loops on the same block diagram. In practice, I've never seen anyone actually do this.

Do people do this? How bad would it hurt if we said, "Nope... you can only have one event structure per VI." ?

I am not saying we're going to make this change. There's a lot of brainstorming going on around possible new features and that aspect of events is causing some difficulties, and I want to know how much flexibility we have to play with the design.

Today I'm asking about a different problem entirely. I want to hear about (and if possible, see posted pictures of) VIs where you have multiple blocks of nearly the same code over and over. Maybe its some manual pipelining that you've done, or for some reason you manually unrolled several instances of a loop. Perhaps you have six copies of your UI on the front panel and so you have six identical event structure loops on the block diagram. These are the trivial cases that I can rattle off the top of my head.

Do you have examples of places where you had to ctrl+drag blocks of code? They can be the same block of code exactly or code that you duplicated and then tweaked each copy. Regardless, it needs to be on the same block diagram.

Why am I looking for these? There are a couple categories of code replication that R&D has identified as a priority to do "something" about to make writing and maintaining such code easier. The current proposals would address some fairly specific niches on FPGAs, but we think we can create a feature that is much more powerful with about the same amount of effort, but we need VIs as fodder for analysis.

So, if you have a VI with such replicated code and you don't mind discussing it and/or posting pictures of it, please, load 'em up in this thread.

https://github.com/munificent/vigil

"Infinitely more important than mere syntax and semantics are its addition of supreme moral vigilance. This is similar to contracts, but less legal and more medieval."

Might be going a little crazy while doing it though.

But I had an idea.

So I posted it.

Basically, when editing the icon of a dynamic dispatch VI, I'd like to automatically be able to apply an icon change to all child implementations. Not unlike how icon changes propagate through all objects when you edit a library icon, only you know, now for dynamic dispatch VIs.

You all agree?

Oh man, that last one I fixed is off by one pixel relative to its parent...

-m

What if NI were to take the top 10 or so ideas from the Idea Exchange and allow attendees to vote by show of hands, robot controlled ping-pong ball machine or stones in a pile.

The top voted idea would be assigned to a group and delivered in the next product cycle.

I feel lately that the only Idea Exchange entries that get any attention at all are the easy "low hanging fruit" ones.

Why not listen to the community more? I don't need VeriStand, a G to C Code generator or web based SilverLight tools.

I DO need things like SSL/SSH and Amish controls...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Project-Defines-or-Project-Variables/idc-p/1982619#M18012

There are times when we might want to expose a reference from inside a library (e.g. a queue or an event which will provide some data to someone), but doing so allows the non-member VI to close the reference:

In some cases this can be avoided (e.g. in the queue case you can output an object and a wrapper around the dequeue primitive, so that the caller doesn't have the queue reference and can't destroy it), but this can't be always avoided (e.g. the event reference).

For such cases I would like to propose that libraries gain a new option:

When this option is checked, any function which closes a reference (close reference, close file, release queue, etc.) will check if the reference was created in a member VI and in that case will only close the reference if it is called from a member VI. If it's called from another VI, it will not close the reference and will instead return an error. This will allow libraries to guarantee that references that they created remain valid as long as they don't close them explicitly.

A couple of comments:

1. The example shows a class, but this should probably apply to all classes. At least XControls can probably gain from this.
   
2. Named references will behave like other references, so if you open two references to the same notifier, one inside the library and one outside it, the one opened outside it can be destroyed by anyone (although I'm not sure how the Force Destroy input should behave in such a scenario. Does anyone have thoughts on this?).
   

What do people think of this?

Pause on first Error - option for debugging

http://forums.ni.com...g/idi-p/1751590

Why only 10 kudos? The page has had more views than that. When I saw this, I immediately thought of all the times I had tried after the fact to decipher a call chain or gone into a VI and deliberately deleted all my error wires just so that Automatic Error Handling would trap my error on the spot. If this worked like an Execution Highlighting button on the button bar, I think it would be great. Thus, I'm posting this idea here on LAVA to give it a second chance at exposure.

Allow Remote Asynchronous Calls

Allow Asynchronous Call By Reference with Strict, Static VI Reference

Add Asynchronous Call By Reference to Call Setup Dialog

Typeless Call By Reference and Asynchronous Call By Reference

[/url]

Add Timeout Input to Wait On Asynchronous Call Node

Integrate Asynchronous Call By Reference with Event Structure

Please kudos as you see fit...

In the screeenshot below, I chose d: as my installation destination.

Mike

If I use XControls I have no direct access over the contents of the Variant data that is stored inside the VI.

If the XControl developer has exported all the possible changes and properties of all it's sub-types as XControl Properties, I could save and reload.

It would be nice if there was an XControl method that would export the local data to a variant thould could be stored to disc. This could be prohibited by a setting in the .xctl file.

Any thougths?

Ton

I'd also like to see some programmatic support as well. Via a scripting property. Copy and paste properties. It should be smart so that it ignores incompatible properties instead of failing.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Format-Painter-for-FP-and-BD-objects-think-Word-Excel-format/idi-p/1001995

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/indevelopment/tab/most-kudoed

This will pull up a list of ideas filtered to those with status set to "In Development". The list is short this year -- please remember what NI folks have said since the NI Week keynote: LV 2011 is going to be a stability and performance focused release. Even though only a few new features are going in, the ones that made the cut are going to put a smile on a few faces. I know that I'm already enjoying that on my development box I can -- wait for it -- save and then undo! Applause for the pair of really bright developers who figured out that little trick. Anyway, take a look -- there's something in there for everyone.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-type-def-from-block-diagram-constant/idc-p/1256064#M7875

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Let-VI-Analyzer-ignore-paths-matching-patterns/idc-p/1251344#M7775

Darren is known for writing useful VI plug-ins for LabVIEW. I've had a history of creating hooks in the C++ code for calling plug-in VIs. He and I both dislike the current behavior of the Create SubVI From Selection feature. It doesn't know about the config token for preferred connector panes, it doesn't put error terminals at the bottom and class/refnum terminals at the top, it sometimes names a control "error out" and an indicator "error in", and the panel isn't laid out as clean as we might like. These are all things that could be fixed in the C++ code, but spare developers are always hard to come by, and Darren already has some G code for doing this work. Thus it made sense for the two of us to work out an interface from C++ to G to improve Create SubVI From Selection. In our spare time, we've found the right place in the C++ code to hook, figured out the data that needs to go across the interface, and gotten the code pretty close to finished. Once we knew it was going to work, we asked for permission to add it as a feature in 2011.

That's where we hit a problem we cannot solve alone.

As many of you have heard, LabVIEW 2011 is focusing on being a stabilization and performance release. Very few new features are being let in the door. The one gate that new features have is the Idea Exchange. The feature has to be limited in the amount of code it has to touch. It has to avoid performance degradation. And it has to be something customers clearly want. We can show two of those three requirements, but not the third. Without the third, the feature does not meet the goals for LV 2011, so even though Darren and I have the new callback hooks largely ready to go, the code cannot go in.

This makes us sad. I mean, it makes perfect sense -- we have to have standards, and limiting the features for this release is important -- but it still makes us sad.

"Create SubVI" is an area of LabVIEW that many of you have asked me about over the years, hoping that LV could do a better job. Darren and I really want to see this feature go into LV 2010, and we're pretty sure that there are enough of you out there that would like to see it too. If we could get the Kudos on the idea up so that the idea is in the top 15, we will be able to make the argument that this is a feature that users strongly want. Now, not every idea with high kudos is automatically blessed in the 2011 release, but with enough Kudos, we think we can get permission to proceed.

There are 3 ideas on the idea exchange that are all affected by this idea, but let's focus on the one that has the highest kudos already:

Create a proper connector pane when doing Edit -> Create subVI

As of right now, that's got 79 kudos. To make it into the top 15, we need 160 kudos, or almost exactly double what it has right now. I think this is an idea whose time has come. If you agree, please contact your friends. Make peace with your enemies. Call your mother. Encourage them all to take a moment to go vote for this idea.

If you're super ambitious, there are two other related ideas that would also be aided by our feature. You could go vote for them too. But focus on the big one first!

Provide a way to define the default connector pane

Edit >> Create SubVI: Tweaks

Help make Mercer and Nattinger unsad! Help improve Create SubVI! Vote now!

This results in a painful development process. I must disconnect my VPN all the time so I can use the IDE. But then I must reconnect so I can commit changes, etc, then disconnect, reconnect, disconnect, ad nauseum.

I mean really? Who stores information like that in the document root anyways? Why can't I put LabVIEW Data somewhere off my user root, like I don't know, in the LOCAL applications settings, which is where it should be anyways?

Cross-posted from here, per Michael's suggestion.

http://forums.ni.com/t5/LabVIEW/24-Great-Ideas-from-Idea-Exchange-for-you-to-Kudos/m-p/1154123#U1154123

Idea Exchange Link: Subprojects/Cross project builds

My text:

Introduce subprojects or packages as hierarchical elements in projects

Please introduce the ability to incorporate a project as a subproject or package within another project. This functionality is critical for effective code reuse and maintainability.

As an example of why this is important, I offer the following:

We have created a class ComponentData and a number of associated classes and other files. We neatly package these in a file structure on disk and in virtual folders in a LabVIEW project. [Note that we use virtual folders since in principle, at least, we can use a given class in different ways in different projects.]

Now ComponentData and its associated classes are common classes that we created precisely for reuse between components, each of which we define in its own project. We encounter an issue when we attempt to reuse ComponentData and its associated elements, however.

We can create a project (call it Component.lvproj) and attempt to incorporate this project into a new project for a particular component. This, however, is not useful, since it merely creates a link to Component.lvproj and does not import any of the elements of Component.lvproj into the larger project.

Alternatively, we can copy the virtual folder hierarchy containing ComponentData and its associated classes and other files into the new project. This does explicitly import the elements, but simply copying virtual folders in this manner does not support maintenance needs. While it is true that if we edit the class definition in one project it will update in all callers (each class correctly has a single definition), unfortunately other changes (moving or renaming virtual folders, moving elements between folders, and so on) we make in one project will not reflect in other projects. This approach is wrong in principle as well as in practice because we end up with multiple independent definitions of the same thing. (The definition should exist in only one place.)

What should happen is that we should be able to define a subproject or package and import it into a project, such that:

1) the package elements are now accessible in the larger project (portable)

2) any changes to the subproject or package will appear in all referencing projects (single definition)

3) any part of a particular package may itself become a subpackage itself (hierarchical)

[Note: As I write I realize that using autopopulating folders (which are inappropriate for the reason mentioned above) can satisfy 1 and 2 to some extent but not 3.]

A wonderful example of what I propose exists in a UML design tool we use called Enterprise Architect (and almost certainly within many UML tools). Within a given project we define a hierarchical layer of packages. (In UML each package, like a LabVIEW project, has an XML definition.) At whichever level we choose, we can choose to add a package to version control. (In our case the tool interfaces to the CollabNet client to a Subversion repository. The CollabNet client is open-source, free, and certified, by the way, and is a much better client than the horrible PushOK client currently available for Subversion connections from LabVIEW). When we want to reuse a package in another project, we simply pick the package we want from version control. (We can select a lower-level package if we don’t want the entire hierarchy.) To make sure the package is up to date we simply invoke a command to update the package from the pop-up menu. This works quite well.

Summary: The ability to import subprojects or packages in a hierarchical manner is critical for effective code reuse and maintenance. We consider this a quite essential feature of any project paradigm in any software development environment. The benefits to users (and therefore to NI) are many and the drawbacks are, well, none. Please ensure this becomes a feature of a version of LabVIEW in the very near future.

_____

I am curious to hear what others think.

In particular, I think this functionality is critical and essential, and very definitely belong natively in a LabVIEW project.

I suggest that autopopulating folders are not the solution.

I suggest that the LabVIEW project must support this functionality--natively! (As I write I wonder if VIPM does this. It very well may, but at least the part I am asking for I think obviously belongs in the project itself).

In any case, please comment on the thread at NI Ideas (rather than here)!

Thanks!

Paul

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-Insensitive-Comparison-Mode-for-String-Equality-Comparison/idi-p/1121574#A5477

Thanks for checking this out.

Here's what I mean. Below you can see a simple VI with a typical assortment of wires attached. This a simple example of the best case scenario - few wires.

If I then click and drag the VI to a different position on the diagram, I get multiple overlapping wires.

Yes, this is normal behavior but I think it can be done better. The next image is the proffered reaction to my move.

As you can see the wires have wrapped themselves to the proper position. Of course this would happen in real time. As you move the VI, you would see the wires wrapping and moving as you drag the mouse. I could best demonstrate with an animation but I am not a computer animator. Also, in combination with this feature, it would be nice if each object (VI, function etc.) had a no-fly zone. What I mean by this is shown in the next image.

The red border designates an area where the wires must come straight out of the VI. This means that no other wires can go behind the object or pass near the object's no-fly zone. This would force clean diagrams since it would be impossible to have objects overlapping wires. The next image shows an extreme object movement and how the wires would auto-wrap into position.

Also note that the terminal is also an object so would have a no-fly zone as well.

Yes, I'm dreaming... I can only hope. :thumbup:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Saved-Searches-and-Results/idi-p/1068144

Thanks!

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-for-Additional-3rd-Party-Installers-when-building-an/idi-p/1065737#A4036

Thanks!

A good example of this would be where you want to time a given task. The "Get Time/Date In Seconds" VI only has a single output, the time. So in order to time a task we generally have to place a flat sequence frame down with the Get Time in the first and third frames and our task in the second one. This generally takes up quite a bit of diagram space. However if we could attach an arbitrary connector to any subVI we choose, we could impart the sequencing required to accomplish our task where no true data flow exists. The digram would be far less cluttered than the one with the bulky sequence frame as well. This would be useful in cases where no data dependencies exist and the value of creating a warpper subVI or enclosing sequence frame (which just looks ugly) or creating a separate state in a state machine just isn't warranted. This sequence wire would not require an actual connector on the connector pane as it could be arbitrayily atteached to a subVI.

Effectively this is the same as the flat sequence frame but much less obtrusive on the block diagram.

I would be interested in hearing what others think about this concept.

Ideas marked In-Development

New Ideas

Completed Ideas

IDEALLY, I would want to set up a virtual channel with the Min and Max value in RAW voltage, rather than the min and max values that are dependent on the scaled value.

I usually know the voltage range/gain settings I am expecting on each channel, but sometimes add the custom scale later. This is a pain to go back and change the min and max values accordingly.

For example, say I have 3 voltage channels with an expected range of -1V to 1V. (I set these up in virtual channels). Now, assuming each channel has a unique custom scale, I have to go and select the scale and THEN I have to go back and modify each channel's min and max value. Before I knew better, I would forget this step and some of my scaled measurements would appear to be saturated at the raw voltage measurement. Also, a change in this custom scale doesn't propagate these min and max values through any channels that is using this scale!

The wish lists for the last 2 NIWEEK shows have been attached. We will compile a new list to submit to this years NIweek 2003. I would like you to review the previous lists and submit any suggestions to this thread. This way we can avoid duplication.

The previous wish lists were a collection of enhancements recommended by the Northern California LAVA group. This time, it would be great to update this list and remove the items already included in LV7. It would also be good to have all 3 LAVA groups collaborate on this new document. Please review the lists and submit any comments you have here.

Download File:post-14-1073112163.zip

I think it is a good idea to develop an idea here and then submit the idea to the NI site, so we can all vote on it. Use the mass of LAVA to provide NI with valuable feedback!

Perhaps an Idea of the month/quarter contest is a good form?

Ton

Why does a numeric constant in the BD default to I32, while a control/indicator on the FP defaults to a double?

Thank you to whomever changed the Compound Arithmetic so that it defaults to a logical operation when selected from the Boolean palette, and an arithmetic operation when selected from the Numeric palette.

Even better would be to be able to:

• Select a group of front panel controls (or blog diagram terminals).
  
• Right-click on one of the group
  
• Perform any of the actions on the create menu.
  
• For example:
  Create Reference would create one reference for each selected control
  Create Property Visible would create one Visible property for each selected control
  

I have been requesting to extend this to user.lib as well for ages.

I even filed a bug report once .

Do we need this feature?

I am in need of this feature because I like the option to include all dependencies when adding a single file to SCC, however it also tries to add all the user.lib (which shouldn't be in SCC IMHO), this can't be added since it is outside the SCC scope and results in error messages.

Is it that much work to extent this feature (or even make an option to exclude a whole custom folder).

Ton

I want a similar key combination to navigate to the next error in the Error list.

Currently my process is:

• Click broken run arrow (or ctrl+L)
  
• Scroll the Items with errors list to the top item in the list.
  
• Highlight the first VI in the Items with errors list
  
• Doubleclick the first item in the Block Diagram Errors list.
  
• Fix the error in my code
  
• press ctrl+L to bring the list frontmost
  
• Doubleclick the next item in the Block Diagram Errors list.
  
• Fix the error in my code
  
• press ctrl+L to bring the list frontmost
  
• Repeat process until errors are fixed in the first VI in the list
  
• Continue doubleclicking in the errors and warning list until I'm done.
  

I would like to see a shortcut key that would iterate through the errors in the errors list.

Edit: I'd like to add that LabVIEW needs to be smart so that it wouldn't jump to the next error if it doesn't exist anymore due to a previous fix. However, I don't see this as a big problem since the Error list dialog already performs that checking in real-time anyway.

One way to expose this would be to right-click on a VI Icon (on the diagram or top-right corner icon) and select "Locate in Project" from the menu. This would open the project tree and highlight the VI in the tree.

Say for example a *.vbait file type that works like a template in MS Word, Excel or even like a *.vit in LabVIEW.

For people who do do alot of vision and have their well structured basic inspection it is a real pain not be able to define our own template and just double clic it from the OS, start editing the application specific part of the inspection and save straight away.

That is really a functionality that would make us save a lot of time !

(submitted as feature request to NI)

Having recently read Peter Blume's Labview style book, one of the big conventions seems to be that error clusters should wire in an out of the bottom of subvis... So why do we have to wire errors in and out of the top of property nodes? I like my code to have a nice continuous error line somewhere near the bottom, but as soon as you start dealing with a few properties from one node, you can't do that neatly anymore. Wouldn't it make sense for the base part of the propery node (i.e. the class label) to be at the bottom with the error, and then you could open the properties terminals upwards...

Anyways, I probably just have too much time on my hands!

Paul

If I have a password protected VI that uses a typedef, I want to be able to protect the typedef from modifications, otherwise that can break my password protected VIs

Allow me to introduce myself into this community. My name is John Pasquarette and I am responsible for NI's Software business (I am in Software Marketing and work closely with Software R&D managers). I am sure I have met many of you over the years, but one of my 2009 New Year's Resolutions is to get more active in the LabVIEW community. I would like to capture more user input and better inform our most active users about various topics coming out of the LabVIEW team here at NI. One of the ways I am trying to do this is with a new blog called Inside LabVIEW. I have been quietly blogging for the past few months (mainly to prove to myself that I will stick with it), and I am now coming out of hiding with my "2009 LabVIEW New Year's Resolutions" blog post. I want to formally invite you guys to take a look periodically at my blog and weigh in on the topics there.

We are constantly talking about strategy, policy, and technology ideas here at NI, and I am hoping that the blog may provide a more nimble, "Web 2.0" approach to tapping into your thoughts on these discussions. The LAVA forums and the info-LV forums will have great discussions periodically on these kinds of topics - in fact, the discussion that pushed me over the hump into action was an info-lv post by David Moore entitled "Will LabVIEW Survive" that many people joined in on. I found that the thread meandered through lots of different topics, many of which are key focus areas or concerns here as well. I hope that the blog will be a more direct way to engage in some of these topics going forward. We'll see how it goes. I hope to cover topics like:

- new ideas we are working on

- background behind feature decisions and release strategies

- new technology areas we are moving into

- policies and practices around support, upgrading, documentation, bug fixing, etc...

- cool applications I see from our LV users

Take a look at some of the things I hope to move forward in 2009. I would love to hear your comments about any of these or other issues that you want to see out of NI. Hopefully, we will both find some value in this in 2009.

Thanks

John Pasquarette

VP, Product Marketing - Software

NI

There is a very interesting and useful class of applications that would greatly benefit

from the use of typedef'd combo box constants that autoupdate. Consider the use of Current Valve Tables

in distributed systems. The CVT's are actually a form of keyed memory that is used to

store data values that can be dynamically created, updated and read. NI's System Group has a

version of the CVT that uses block diagram strings as variable names. This approach is cumbersome

in that if a name is changed you have to find all instances on the diagram and change

them manually. Also you have to cut and paste them in the first place. Another possibility is typedef'd enum's which will autoupdate

on the diagram, but unfortunately the enum datatype cannot be passed into subvi's without converting to a variant or string. It is also rather inefficient if your CVT is large

and you have 100's of variable names that would have to be passed around inside of the enum constant attributes.

An alternative and elegant solution is the use of typedef'd combobox constants that will autoupdate. I would like to argue that the change in behavior is really only a

development environment change, not really a fundamental change to the underlying wire type characteristics as it has been argued by NI.

The constant itself already has an attribute that links it to the typedef, so why inhibit the autoupdating?

Any Comments?

It may not be straight-forward to allow programmatic access of the array index - if so, it would be sufficient to have a popup menu to choose which index is used, and some visual indication of the usage, as in the lowest example.

The same method could also be used to determine how an array is built out of a For-loop.

Let floating point numeric probes by default display all digits of precision for that particular data type.

In a recent project I've spend hours and hours looking for a bug of which it wasn't directly obvious to me that it was caused by the floating point lsb rounding errors because these are basically masked by the default setting of 6 significant digits. I think this is a good default for FP-controls, but not for probes which are used for debugging purposes. In my case it would have saved me tons of time.

Now, I imagine it is not always wanted behavior to have full precision in a probe, so best thing would probably be to have a control on the probe FP to set the nr of digits of precision at runtime. I can create a custom probe for that, so my problem is solved, but it would be nice to have this available on the default probe. I imagine more people are caught by this 'problem'.

QUOTE

I usually use Bundle By Name rather than the plain Bundle for clusters, and certainly for all typedef clusters. The only time not to use it is when you need to do a multi-key sort, since that works really well, and the cluster data structure is just temporary. 99% of the time my clusters are typedefs, and using Bundle By Name always makes the code clearer and easier to debug by inspection.

However there is a disadvantage in that if I add something to my cluster, then existing bundle by name nodes will just use the default value for the new item, and it's not always easy to find all the associated bundling nodes. This often leads to bugs.

In contrast, I use enums a fair amount, and I disable the use of "Default" in the case structures, so when I add an item, my application breaks in a bunch of places, and so I am forced to go fix them all and in the process most of the potential bugs are eliminated right away.

My suggestion is to add a right-click checkable property to the bundle by name node, requiring it to have all elements explicitly wired in. Then if I turned this on for a given node, the VI would break whenever I add an element (just like it does when I remove an element).

It would also be helpful to have this on the unbundle by name node though I realize it's not very labview-like to be forced to wire a nodes outputs.

What do you guys think?

I do a lot of system recessed frames inside of invisible clusters for the nice effect that it gives.

and sometimes I have things that their 'bounds' don't quite have the same gutters.

Or you want the same things on multiple tabs to be aligned in the same spots

so the net effect is that in these and other situations, IT"S A BITCH TO GET SHIT TO ALIGN.

So, I propose that NI allows Rulers and Guides similar to photoshop and the like to help us setup our FP easier as to make more professional looking FP.

Thoughts?! before I submit to ni on suggestion page of course

Alternatively a word (public, private or protected) in the title bar (possibly activate through an ini key) will be good as well.

PJM

It's really a pity, that you cannot combine them by setting splitter bars on the pages of tab controls.

My typical use case for this is a tab control with "Fit Control to Pane".

On a page of this tab control there might be a tree control that should use the entire height of the tab page an keep a constant width.

On the right side of this tree cotrol there might be a graph that should use all the rest of the space available.

I know how to programm this manually. I know how to get this effect by using a sub-panel and simulating a tab control.

But I would really appreciate beeing able to use the "natural" way of setting splitter bars on tab pages.

As far as I understad the logic of splitter bars, they can only be used on panes.

So the tab control would need to be redesigned in a way that it's pages are real panes.

(or maybe there could be a new additional "Pane Tab Control" or something?)

I have no idea how much effort this wold take NI R&D, but it would really be a great feature for building professional user interfaces that are not bound to a fixed screen resolution!

What do others think?

Is this a good idea?

Would you use this feature in you own applications, if it was available?

Based on recent discussion (1, 2), I felt there are some things missing to make the project the super-duper LabVIEW IDE enhancement.

The things that are currently lacking (IMHO)

• Set a description for a virtual folder
  This allows you to group VIs under a folder that has a better description than the name of the folder
  
• Setting 'Conditional Disable settings' in the build-properties
  
• Better Build-tools
  • The possibility to set the version of an executable and an installer in one location
    
  • Have dynamic built location (builds\executable\%version%)
    
  • Have the possibility to edit the GUID of an installer
    

  [*]Update the SCC settings when they are edited from within LabVIEW code

  [*]Allow extending of the context menu-items of project items

  [*]Copy build settings from one project to another

Share your thoughts, fill in the poll and respond, make the project perfect.

Ton

Queues appear to be implemented as a circular in-memory buffer. There is no way to define the "when full" behaviour of a queue. The current solution from the producer side is to to enqueue -> timeout -> dequeue element -> enqueue element; or get Queue Status, dequeue element if full, enqueue element.

Specifically, I've been finding fairly frequent need for a behavior more like lossy circular buffering. I'd like to fix the size of the circular buffer, and then the freshest data keeps circularly overwriting the oldest data. The UI thread could then asynchronously perform analysis on the most recent N samples, acting like a sliding window. (Kevin P.)

If you wire a DDT directly onto another DDT wire, LabVIEW automatically inserts the Merge Signals function instead of producing a broken wire. Pretty cool.

It would be even cooler if LabVIEW would do the same if you wire two error wires together. LabVIEW could insert a Merge Errors function that actually scales to the number of error wires to be merged. It's very common to have parallel operations that both have error outputs that need to be merged. This would provide a very easy way to do so. It also seems possible since the error wire is a specific data type that LabVIEW recognizes.

I know that we can do this in windows through but anyone who has done this knows that there are severe limitations behind it.

Thus it would make much more sense to make this ability work the way most of us thought it would work when we saw the option available.

comments?

Of course the same can be done with a for loop, but doesn't feel so clean.

Saludos,

Aitor

-Chroma

in some project the run time is long, and therefore debug time is exponential: why not allow code change while program is in 'pause mode': i discover a bug - dont want to restart the whole process - pause, change the wire, structure or element - and then continue running.

It is possible in VB for example. works perfectly there.

Why not in Labview?

I'll bet you can imagine why we need this feature

With this option it is possible to have preferences files that can be added in the installer.

Ton

Take a close look at the loop exit.

greetings from

martin

1. create constant

2. create control

3. create indicator

You would have to put the wire tool over a connector/terminal so that labview would know what the data type should be. In other words the data type of the item created would match whatever the wiring tool is pointing to.

right click -> context menu -> click on item is okay -- but could be faster.

Anyone concur?

After all, NI's Digital Waveform Editor has that provision...

Something like a control-sized icon specifically for constants or typedefs would be fabulous.

And what about the ability to programmatically place the pictures / text decorations on the panel. This would be very helpful to people who need help with source code control, or ability to put the warning text on a whole library full of files at a time.

dhuff

Right now I have to select the portion I'm interested in, and create a new VI out of it (or a subVI, with the drawback that I can't easily undo the changes to the original VI)

Would be nice to just be able to select a section of the block diagram of interest, interactively initialize the inputs or optionally use the default values, and run it.

I have the habit of always labeling my shiftregs on the left hand side of the loop they're on. I use free labels for that, but it would be nice if the labels where (optionaly) automatically created (like with objects on the FP). They would be attached to the shiftreg, moving with it when the shiftreg is moved up or down.

besides being a handy feature for myself, it would probably also encourage others who don't label their shiftregs now to do it anyway, because it would be the next logical (more or less forced) step after creating the register.

What do you guys think?

I'd love to see some way to combine the Compound Arithmatic node (in boolean mode) combined with the Stop/Continue node. That would be especially useful if it could be used in conjunction with error clusters as well, rather than having to unbundle the status element first. You can already wire up the error cluster directly to the Stop node, but often that's not quite enough.

Something like this:

E.g. (449,29 / 21 elements)

However, when I create a constant on the block diagram I almost always want to change the label. So the label text should be selected to allow text entry as the constant is created. This avoids double clicking to change the label and mimics the behavior of controls created on the front panel.

David

When wiring error into a loop, the most common use case is to have a shift register to pass the error from iteration to iteration. Hence shift registers should be the default terminal type for error clusters when wired to a loop.

And refnums, too

Wouldn't it be nice to be able to be able to use it in LabVIEW to copy all the "format and precision" properties of a numeric to another one ?