LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

It would be nice if the programmer could rearrange the variable names in the unbundle by name by dragging and dropping the variable names in the order you won't when your assigning the values from the block diagram. This should not affect the actual cluster order. I hope this makes sense.

 

the decorations in the front panel have properties, these properties you can to modify in execution time, but the order off these decorations is created automaticaly, and the newer decoration object, it's the first, and other existing decorations your order number is changed automaticaly.
Proposed solutions 
- the automatic order number should be generated, in the same order to are created the decorations, in the same way of controls
- create a new function to modifying the order number, the same way to modify the tab order of the controls.

 

 

When implementing a multiplexer the obvious solution is to use build array and then index array.

 

current.PNG

 

Proposed Alternative. Add an index to build array. If it is wired you get the selected element. If it is not wired it behaves as normal and you get the built array.

proposed.PNG

 

Or maybe there is a right click option for build array to change to the "multiplexer" style.

On the Block Diagram page of the Options dialog box, please change the default value for Place front panel terminals as icon to false(unchecked). Similar to previous idea.

 

Hi all,

 

Sometimes, I use the index array node for getting elements 0-8 from an array, for example.  If I need to use the 6th elements from the output of the index array multiple of time during coding, I find myself counting every time to make sure that I am using the 7th element.  It will be nice if there is a very small number on the index array node to indicate which output is which element of the array.  I think it will be clearer.

 

Yik

Hi,

 

it would be a great idea to choose an option to put a LV icon on the taskbar when LV is minimized (when running a program), also try to eliminate the 2 windows when open an running a "vi", with one is too enought ...

 

Thanks !!!

Whenever we create an executable file for example, abcd.exe from abcd.vi that can be run on a computer having the runtime engine of the corresponding labview version, it has certain default data control set at the time of creating the .exe file. I propose that there be an option to set the values default after creating the executable file.

I propose a property node to tell if a control was wired when This VI was called as a subVI.

 

Wired.png

 

Sometimes it is practical to be able to distinguish if the value in a control was wired to it (data arrived via dataflow), or if the control was unwired and the value hence the control's default value. Even comparison with the known default value of the control isn't enough, as the program logic may depend on the value source.

 

Consider an FG that stores two data elements:

 

FG.png

 

You'll have to have two Set functions for this, one for Data 1 ("Set data 1"), and one for Data 2 ("Set data 2"). If you have only one Set function, you add the constraint that both data sets have to be present (wired) every time you set any of the two data sets, or else the unwired set will get overwritten in the FG with the default value of the unwired control. If the FG could decide programmatically if the value was wired to the control, or if it was merely the default value of the unwired control, it could decide whether to overwrite its stored copy or not. The data values could be the same in the two cases, but the actions very different. This is just a simple example, but I have many much more complex cases, that would get much simpler if I could tell where the control value came from. In the above example you could even dispose of the Function input alltogether, if I could tell if any data inputs were wired.

 

A polymorphic VI will remedy some of these issues, but not all, and in other cases a polymorphic VI is a drastic solution to a simple problem. It's also not an issue in a Top-level VI, as such run only once (only subVIs get called again and again, while depending on prior runs).

Quite often I find myself using a combination of Array Size + Index Array with a constant to know just one size of a multidimensional array. Wouldn't it be easier, if Array size would behave in a similar way as other array functions - depending on how many dimensions the array has, so many outputs show up. The example shows 2 dimensions, but could be expanded to more

This post is intended to present a solution to a problem that I was struggling with using LV2 global variables in my applications.

I don't claim that this is a unique or elegant solution or even the first of its kind, but I'd be curious to hear comments and suggestions about it.

Since it might be a long post, I will split it into 3 parts.

Part 1 (below) will discuss the intended functionalities.

Part 2 will present my current implementation.

Finally, I will try to summarize all this into Part 3, opening the discussion.

 

So you may want to wait until that part is published before posting your comments (if any).

 

Part 1: What do I mean by Generalized Functional Global (or GFG)?

 

The LV2 global variable (or functional global, FG in short) is a well known structure (see for instance the beginning of this thread). It is a subVI which can store data locally in between calls. Usually it comes with a "Write" (or "Set") action and a "Read" (or "Get") action and a few inputs (and the same number of outputs). The inputs are the variables you want to update and the outputs, their corresponding values.

The advantage of this design over the standard LV global is that there is only one copy of your variables in memory. If you are only using scalars or string, etc., using LV globals might not necessarily be a big problem, but if you start storing arrays of large data structure, it could result in a significant performance penalty.

Note that there are other ways to pass data from VIs to VIs (queues and notifiers). Here, I am concerned with long term storage available from many parts of an architecture (e.g. subVIs or dynamically launched Vis).

To begin with, there are two major limitations with any design based on FG (at least that I am not happy with):

 

1) First, as emphasized above, due to the limited connectivity of a VI's connector pane, a FG cannot store a large number of variables. You can use clusters, but that is not always very practical.

 

2) Second, if you try to cramp as many variables in a single FG, you will probably run into the issue that you don't necessarily want to reset all variables at once, but maybe just one or two. That calls for a more sophisticated set of actions (Write Variable 1, Write Variable 2, etc, and possibly Write All, Clear All, etc).

In practice, if you use a lot of those FG, you will encounter a third problem:

 

3) In which FG did I store this @$%&! variable?

 

Some of my applications contain many of these FGs and I figured that this had become impractical to handle when I started duplicating them, having forgotten that I was handling variable "X" in an existing FG.

 

The obvious solution (apart from NOT using FGs) is to have a single FG that is designed such as to handle an unlimited number of variables of ANY type that can be modified at ANY TIME from ANYWHERE.

 

I first looked at the WORM (Write Once Read Many) design of tbob (you’ve got to go to the end of the thread to download the final version of the WORM VI). It is a very clever and compact solution to store different types of variables within a single variant.

Two of the limitations I saw in this design are that you need to know:

 

1) the NAME of the variable you want to access.

 

2) the TYPE of the variable that you are WRITING or READING.

 

Let me clarify those two points.

 

It seems obvious that you HAVE TO know the name of the variable you are interested in. Well, that’s maybe true when you are designing your application. But after a month or more doing other things, it is not obvious anymore whether you’ve stored the number of components as “# Components” or “Component #” in that other part of the program that…where did I save it, BTW? You get my point…

 

The second point is apparently taken care of by tbob’s solution of outputting the variable (as a variant) as well as its type. The problem is that this “type” provides a very limited description. For instance, what do you do with a “cluster” type?

 

Finally, since I want to be able to modify any variable at any time, the “Write Once” feature is not cutting it for me. This is could be easily modified, but considering the previous comments, I decided to change the architecture some more.

 

I will describe my solution in the next part.

 

Hello, I'm searching about this topic in the forums, but I find no ideas about this, if I repeat the idea please tell me.

 

I'm working with LabVIEW from time ago, but I've noticed that when you have a large Project is complicated to work with it. I will explain myself:Example.jpg

 

Here it is my last project (right), you can see that it have a lot of directories and a lot of classified data, controls, vi's and some more stuff. I hope you are familiar with it. Well, you will work with it for a lot of time, but when you want to go fast you need to access to some controls or global variables files a few times, don't you?. This is annoying with the actual interface, because of the nesting in the virtual directories. Some kind of favorite system is needed, but instead of that I have another proposal:

 

Copy list.

 

Let me explain this idea. You can have in the project explorer, for example, integrated another tab called copy list that can be like this.

 

Copy List.jpg

Ok, every time you do a copy action the object that you copied is added to this list classified as you can see. Now you are able to drag and drop items very fast without searching on the project explorer, you can center on the work (I've noted that I expend a lot of time searching on the project explorer tree my next control or vi to use).Well, let's see the really advantages that I think can be helpful.

If you stop the cursor on a element you could see all the related information easily:

 

Copy list Help Tag1.jpg

   But this is not the only shortcut to access your "most used" stuff, I do another image to show you the options:

 

Copy list Contextual.jpg

 

Now this is the real advantages:

  • You can copy to the clipboard elements easily (as property node or invoke node) and without searching the control or terminal
  • If a control is used a lot of times you can fix it on the copy list and you can put it in order. (The fixed elements can be marked in bold and can be in the firsts positions of the list)
  • Of course you can remove a element that you don't use.
  • If you must to go home you can save the copy list to get it easily tomorrow.
  • An extended help is useful in this list.
  • I think that a rename option is helpful too.

You can define the length of the list to achieve some memory optimization (but with the actual development computers I think that this is not a problem).

But for this price I think that this can be a great tool to work fastest on LV.


What do you think?

Often times, I have a set of code in a for loop that takes a while to complete, so I put in a progress bar on the UI.  The problem is the progress bar defaults to 0-100 range, and my for loop normally does not have 100 iterations. 

So.... I can either rescale the progress bar to the number of elements, or I can use the "N" and "i" to calculate the percent complete and use that.

 

Since I like to keep my progress bars as 0-100 (since that works nicely to also show a percent complete) and % complete is useful elsewhere, I generally always end up calculating % complete of my for loops.

 

Well, why can't NI calculate this for me automatically???  Something like expanding the "i" iteration counter in the loop also have a "%" box right next to it.

 

Example shown below should probably wire as a double instead of an int, but you get the idea!

 

ForLoopProgress.jpg

When I save a vi for a previous version then the next time I open that vi and close it LabVIEW prompts me to save it because it was converted from a previous version. I should be able to open it, make changes, and save it again with LabVIEW remembering what version I wanted it saved for. Maybe the version could be a vi property?

From early on in labview i've had issues with larger VI's not being completely visible on the screen, making it more difficult to 'wire up'. Other suggestions have been for resizing the front panel, but resising the diagram would also be a very helpful feature.

Similar to the "view / zoom" window in IE8 or word to view more or less information on your screen at once. Hopefully this would come with a hotkey option as well to quickly increase and decrease the zoom level during code writing.

It would be great to have a feature similar to the Microsoft 'Format Painter'.

 

Sometimes in a project you need to change an amount of indicators from one data type to another (U8 to U16 for example) or, you want to change the number of digits of precision, string indicators from Normal to Hex etc, etc.

 

A Format Painter would be great, highlight the format tool, click on the master object and then click all of the controls/indicators that have to be the same. The painter could work on front panel objects or block diagram terminals.

It would great if we could set the time of the CRIO controller via MAX as we select the time zone.....

In many of my programs, it is frequent that I have to issue a command, then wait for a period of time before reading a response. Usually, if there is a timing delay in code, it is usual to end up with something like this:

 

timing2.png

 

To do this more neatly, I created a timing subVI with errors wired in and out, and a number wired to it, to instruct the program to stay in that subVI for that period of time. It takes up much less space.

 

timing3.png

 

By doing this, I can easily control timing and execution. However, it's be nice to rework the 'milliseconds to wait' diagram so we could wire errors through it, as this would make the block diagrams so much neater...

 

If i am creating a new control of the same type as the first one, for the second time, the name automatically changes by concatinating "space 1 ". that is fine. but simultaneously i have option of having the same name as the first control by editing.  When i am creating variable it is confusing for which control i must relate it to untill unless i find the control and check.

 

I want to know (some kind of information on availability of the same name for another control) while editing the variable name of the same type is available.

 

Should it be allowed?

 

needs some clarification on this..

To improve the quality of interfaces, we need to change the color of the focus rectangle. Otherwise we do not see anything on a dark interface.

Download All