LabVIEW Idea Exchange

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

Using a modern control (see the attached slider, as an example) it's possible to change the frame color with "Customize control" window.

But during runtime execution this color can't be changed (see this discussion)

 

I suggest a new property "Frame color" that can be written during runtime.

as an example, the Ctrl Val.Set method could be shown as follows, if the VI reference is static:

CtrlValSet.PNG

 

There are a lot of VIs of mine, where I could spare wires for Control Name.

Not sure if this is already implemented and I just can't find it, but making it so I can jump between entries in an array constant would save me maybe five minutes right now. I'm making and populating a 6X12 array constant and right now it seems like I have to click into every cell individually which you can imagine is frustrating.

I often need to make single test on specific function before placing them in a block diagram.

 

We could have a test zone you could access in a right click and place in to block diagram

 

This test zone would be a standalone "vi" that could be run to test the way a function work.

This would replace :

- either the need to open a new vi, place simple code to test in it and then crash it after tests are performed

- or the need to configurate your complex vi in order to check the way a string format specifier works

 

If tests are successfull, you would have the option to "keep it on block diagram".

Normally in a multidimensional array, to obtain the number of elements in the corresponding dimension we need to use two array functions namely the array size as well as index array functions. Instead if a single function is provided like the one shown below would be more useful. The new function can be a replacement to the existing array size function with an additional feature which eliminates the use of index array function to get individual dimension values.  

This may not be the case with all, but as a beginner I used to get confused many times which element of 1D array generated from array size function corresponds to rows/columns.  So a function similar to the cluster function (unbundle by name) would be very easy for a developer to use and there will be no chance of confusion.

Based on the dimension of the input array connected to this, the function should automatically add/remove the unnecessary items.

Example: If the input array is a 2D array, then ‘No of Pages’ item should not appear. If the input array is a 1D array, then only ‘Array Dimension’ should appear. The developer can also be provided with option to select their item of interest (drag/reduce) in case of a multidimensional array.

 

The last item ‘Array Dimension’ is to retain the existing functionality and provide an array of dimensions.

 

ArrayNode.png

A state's Static Rxns are executed in the listed order.

 

Currently, to move a Rxn to the bottom of the list, I need to:

1. Create a new Static Rxn

2. Copy + paste the code from the old Rxn to the new Rxn

3. Re-connect all the broken input/output wires

4. Delete the old Rxn

 

Proposal: Let users rearrange the Static Rxn list!

As a LabVIEW user, I would like to see who has called the current VIs when a breakpoint is placed on it.

 

From the stack view, when a vi is double clicked, the corresponding vi block diagram should open highlighting the block diagram area from where the call is made to the next vi.

 

If posssible the stack view can show the inputs and outputs of all the VIs in the stack view.

 

An example screen is provided as an attachment.

Hi,

 

A small point, the force/exp window help description, for example, in the SVFA Frequency Reposnse vi reads a little ambiguous:

 

force-exp.png

 

For example, what is unclear to me is where the exp decay starts from, I believe it is after the force window but it is not too clear.  Please can we get a diagram to help show exactly how this works in the help?

 

Can we also have these vi's also output the windowed waveform as well (i.e. what it actually perfoms the FFT on), so we can easily plot the transformed signal?

 

Thanks,

 

-

James

When working with VI hierarchies with several different passwords, editing can be a real pain in the derriere.

 

Even double clicking on an icon to chenge it only works AFTER you have entered apassword and I find myself trying first to edit, then realising I haven't entered the password yet and having to click, click, click and enter the password.  This gets really tedious when it's happening multiple times every day.

 

How about an option to create password lists which can be unlocked automatically using a master password within the LV IDE.  I currently have written a small VI which adds the passwords required to my IDE when starting (I launch the VI which launches LV and then adds the passwords and exits, leaving LV open with the passwords in cache).

 

Problem is when I double-click on a project from explorer and LV previously wasn't open, then I don't have the passwords entered and I land in the trap mentioned earlier.  Things wouldn't be so bad if LV wouldn't crash so often i.e. the IDE would just stay open the whole day.

 

So instead of just having an option to clear the password cache in the IDE, give us also the option to pre-set some passwords please.  For security reasons (blind hacking attempts) we could limit the number of passwords to 32 or something.

 

Shane.

When I'm writing sub-vi's and dropping controls and indicators on the front panel, I nearly always will drop the things that will be controls on the left and indicators on the right side of the front panel. It would handy if LabVIEW followed the same convention and by default set all controls dropped in the left half of the front panel to be controls and all controls dropped on the right to be indicators. It would still allow you to change between the two in the current fashion, just the default would be determined by the drop location, rather than any intrinsic property of the control.

If you edit a loop you can click to a tunnel and replace it by a shift register and reverse. But why is nothing like this for stacked sequences and the local sequence variables?

 

Here some pictures to illustrate what I'm thinking about:

Loop Replace by Shift Register.pngReplace Tunnel by Shift Register

 

Seq Replace by Tunnel.pngchange tunnel to a Sequence Variable

 

 

 

 

Loop Replace by Tunnel.pngReplace Shift Register by a tunnelSeq Replace by Tunnel.pngChange Sequence Variable to a tunnel

 

 

 

Remarks: I'm using LabView 2011SP1 German

I propose that after selecting Visible Items -> Label the label always becomes editable.  That is to say, give it key focus (and highlight what's already there).  Today, the label is only automatically editable if it is empty.  This of course makes changing the label a tedious multi-click process.

 

I don't think always making a populated label editable will affect existing workflows at all.  The only thing that would be troublesome is if you started typing after making the label visible, and within LabVIEW there is rarely (never?) a reason to do that.

When we create polymiorphic menus (or apparently accessor VIs for classes which are usable as property nodes) we can create submenus several items deep in order to organise and unclutter the choice of which element is being searched for by inserting a colon ":" in the name of the items.

 

I suggest that global variables should adhere to the same scheme.  If I name items on my global variable Input:Channel 1, Input:Channel 2, Input:Channel 3 and Output:Channel 1, Output:Channel 2 and Output:Channel 3 it would be nice if (when clicking on thew global variable on the BD that first menu "Input" and "Output" are displayed, and then the sub-items once selected as below

 

Polymorphic selector example.png

 

This would enable more structured ordering and more logical presentation of values within a global variable.

 

I think the full name should be shown when the actual element is chosen (i.e. Input:Channel 1) on the BD but during selection I would like to have the menu option.

 

be able to swap inputs even if one of both is unwired!

SR.png

Closing reference nodes take up too much space on the block diagram.  It would be nice if there is an option called "close reference when Vi complete", and that option is available fro all referene individually on the block diagram.  When the option is selected for a particular reference, the reference would close when the subvi is done executing, and there would be a star next to the reference name indicating that the reference will close automatically.  

Currently there is No DELETE option to delete unnecessary Code/Function/VI/Object from Block Diagram & Front Panel. We need to first select code then press delete key on keyboard to delete it.

221.png222.png

There is the option of selecting a structure to be excluded from code clean-up but having an option to select an area of code to be excluded from code clean-up would be great. For exampl, if there are multiple loops in the block diagram and you don't want to change the location or the wiring around a particular loop, I don't see there is any to do it. Event though you exclude the loop from code cleanup the surroundings and/or the location still change.

I was researching the best way to do continuous data acquisition and found the following article:

 

Acquiring Records Larger than Available Memory

NI High-Speed Digitizers Help

Edition Date: February 2013

Part Number: 370592V-01

»View Product Info

The standard use of continuous acquisition is to fetch a record that is larger than the available memory on the digitizer. Because the data is fetched as it is acquired, the digitizer memory can be overwritten. At slow sampling rates, you can fetch data forever by setting up an acquisition that is never triggered and is repeatedly fetching. At faster sampling rates, the host computer may not be able to fetch as fast as the digitizer samples data. If the data that is being fetched is overwritten, NI-SCOPE returns an error message from the Fetch function. Look at the Fetch in Chunks example to see how a waveform can be reconstructed with the data from multiple fetch calls. Look at the Fetch Forever example to benchmark how much data you can acquire at a given sampling rate before the data is overwritten.

To fetch a record that is larger than memory, set the Fetch Relative To attribute to Read Pointer. This positions the beginning of the fetch operation at the start of the record when you initiate a new acquisition. After every fetch, the read pointer is incremented to be the sample after the last sample retrieved. Therefore, you can repeatedly fetch relative to the read pointer, with a retrieval offset of zero, to acquire a single, infinite record.

If you specify a positive timeout with a Fetch function, it waits for the requested number of samples. Alternatively, specifying a timeout of zero acquires the number of samples currently available (up to a maximum of the numSamples parameter). The waveform info structure returns the actual number of samples fetched. Using a timeout of zero achieves slightly better performance because the status of the digitizer is queried less often.

A separate read pointer is stored for each channel, so you can alternate fetching different channels. The read pointer is also reset to zero when you fetch from a different record.

 

 

 

Your Feedback! poor Poor | Excellent excellent   Yes No
Document Quality?
Answered Your Question?
Add Comments 1 2 3 4 5

 

I had planned to simply note that providing a hot-link to the examples mentioned would be helpful. Instead, the Add Comments link sends me to a page that asks for new product ideas and then sends me to this forum after noting that NI does not accept new product ideas for LabVIEW. I think you should either remove the Add Comments link or else direct it to something that actually does what one would expect.

 

In general I find the help function in LabVIEW to be well organized and usually helpful. It is a shocking contrast that the on-line search function most often returns chaotic (in the mathematical sense) results and is often of no help at all. A confusing structure as noted above just makes the experience worse.

Since Labview suffers from "Not enough memory to complete operation" if one is not carefull I though its time to propose an idea to solution. 

 

Problems:

1. when initializing new array user does not now if the function succeded or not until is too late (window with Not enough memory pops up).

2. If out of memory happens in a loop then user is left with no choice but to kill the aplication (there is no STOP button on the out of memory message!).

3. If user clicks OK memory gets released but the function (say Initialize array) still throws Not enough memory if its called in a loop.

 

 

Proposed solution

1. Provide an error terminal on all blocks that operate on memory (initialize array, Insert into array, build array...). this terminal would indicate if the function succeded or not (without pop up message!) 

2. Get rid of pop-up "Not enough memory to complete operation" window. Instead the out of memory should be thrown on error terminal where it happend (initialize array, insert into array, etc....).

3.If the "not enough memory..." window must pop up by some strange reasoning, then at leas provide a STOP button.

 

 

Key Benefits:

1. Easier and cleaner code. Say that I want a 2D m by n U32 array sizeof(max_free_mem). In proposed solution I could do that in a loop. If I get an error at alocation I could reduce the size untill I get alocated largest free memory block size m-x by n-y and store that block in a "data value reference". Then I would repeat the process to alocate smaller and smaller blocks until I get to the desired size. I would end up with an array of clusters of 1D data value reference arrays. 

2. No calls to external dll to get memory information would result in less overhead.

3. Posibility to alocate all free memory (the goal)

4. No more annoying pop up window

..and more

 

I really wish to see this in next release if not sooner as a patch 😉

 

regards 

Dejan

 

Well, I've seen the discussion about 'removal of Tile windows' and I agree that it helps (at least for me) while debugging, to be able to see both, FP and BD in SloMo at the same time.

BUT: I'd really appreciate a

'Ctr + Shift +T'-option to tile windows not beside but on top of each other, i.e. tiled verticall instead of horizontally.

 

Seems like a small feat to add this.

Michael