LabVIEW Idea Exchange

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

Hello,                    (sorry for my english, i will try to do my best)

 

I think the management of Breakpoints and  Probes is not logical and not enough powerful.


I propose a new approach. 

 

LabVIEV would need a real debugging environment, much more powerful, like this :

 

 

1st  :  Probe management is not logical

           Why ?  A probe is only to watch a value on a wire (not to stop the code)

 

anciennes conditions.png

 

2nd : To stop the code, the Breakpoint, with ou without condition(s) ... (conditional or unconditional Breakpoint)

3rd  : Conditional Breakpoint:


  •   A conditional Breakpoint stops the code on a wire, according condition(s) on this wire itself;

       or / and  according condition()s on other wires. (very powerful feature)

  •  The breakpoint condition use binary operators (C language), like a Formula Node
  •  To Use a Numeric value or a boolean value into a Condition, you must first place a Probe

      (Normal, before using a value, we must first take it.)


  •   The Conditional Breakpoints are only available with Numeric and Boolean values.

      (As the current version of LV)

 

VI_with_probes.png

 

The breakpoint Manager highlights the Breakpoint on which the right click has been made.

Inside the Breakpoint Manager, we can see the corresponding Breakpoint via "Find on Diagram".

 

 

total_1.png

 

 

 

 

The Report Generation Toolkit provides functions to set various Format aspects of Excel "areas", and Excel Graphs, but doesn't provide the complementary "Get" functions to return the current values.  For example, I wrote a LabVIEW function that will set the Font Color of a row of a WorkSheet to Red (using Excel Set Cell Font), but if I want to find the row with the Red font, there is no "Excel Get Cell Font" that can return the property to me.  Of course, I could cobble something together using ActiveX calls, perhaps, but these are poorly documented, and since NI is already doing the "heavy lifting" to provide the Set functions, it would seem "relatively simple" for them to also add the corresponding Get functions, as well.

 

Bob Schor  (using Excel as a "controller" for some experiments controlled by a LabVIEW Real-Time system)

It will be good to have a option like "Close all but this" in File Menu; which will be very useful to close all the sub Vis after debugging and just run the main Vi with all sub vis closed. i feel it would be very good to have this feature.

 

This is similar to the one in Notepad++.

Currently, we have to use Unbundle By Name from Cluster and select an element for Case Section

 

1.png

 

It would be great if we could just wire the Cluster Directly and have a Right-Click Option at Case selector to select an element (one element only).

 

2.png

 

P.S. If it is a reasonable suggestion and gets enough Kudos to get R & D team’s attention for feasibility of this idea, then we ask for more logical operators support that would be useful. Also multiple elements and/or more statement node i.e. (type == Array and # elements <= 2)!!!

Only sometime I miss “if statement” support in LabVIEW. 

 

 

Message Edited by Support on 07-16-2009 11:56 AM

I use the following shortcuts in Quick Drop:

"+" - shortcut for "add"

"-" - shortcut for "subtract"

"*" - shortcut for "multiply"

"/" - shortcut for "divide"

 

And that got me thinking that what I would really like is to be able to type simple math equations and have Quick Drop generate said equations.

So if we typed "(*3+2)/(4+5.68)", Quick Drop would spit out the following:

simple math.png

 

-Carl Wecker

The menu "tools...profile...find parallelizable loops" is a great tool to indentify loops that can be parallelized and it gives detailed advice and warnings in questionable cases.

 

There is however an important scenarios that is ignored in the analysis:

 

The case is if the parallelizable loop is contained inside a larger loop that is already parallelized. As a general rule, it is typically most efficient to parallelize the outermost loop only. A parallel loop inside a parallel loop only creates more overhead and will not gain much if the outer loop already causes 100% use of all CPU cores. It is possible that the LabVIEW compiler sorts things out automatically, but I think the "find parallelizable loops" tool should consider if an outer, already parallelized loop exists and should tone down the recommendation to a question mark instead of a check mark in this case.

 

Here is a typical analysis (yes, the subVI is very simple and inlined, so the outer loop parallelization is sound ;))

 

 

The description could read "This loop can be safely parallelized, but it is already contained inside a parallel loop and thus parallelization would not give any significant advantage" or similar.

 

Idea summary: The result window of "find parallelizable loops" should warn if a parallelizable loop is contained inside a parallel loop.

There needs to be a LabVIEW API for Requirements Gateway.  API functions would be

 

1. Open/Create Requirements Gateway Project

2. Add/Remove Requirement Document

3. Add/Remove LabVIEW VI 

4. Get Code coverage

5. Create Report

etc

 

I think this would be extremely useful with trying to dynamically get code coverage, and really extend functionality

Outside of comparisons, Triangles are becoming an endangered species on my Block Diagrams.  The Compound Arithmetic Node is a very handy tool, and armed with my (function preserving) RCF plugin/QD shortcut they are replacing all math triangles.  I use them a lot, and so should you.

 

One final hurdle to reaching total happiness: the process of inverting inputs and outputs is a bit awkward at best.  Right-Click, scroll down, find Invert (right in the center of the menu of course) and try not to have the muscle spasm that results in 'Remove Input'.  I would really like some type of shortcut (double-click, shift-click, ctrl-click, anything) to quickly toggle the inversion of a terminal. 

 

(I would also like to enlarge those Inversion circles while we are at it...)

 

(Ironic that the LV logo is a combination of the Add primitive and the Sequence Structure....)

 

 

I am still hoping that NI will bring back the Standard Report type in the future and I know that there are many others sharing my feeling. Whatever the reason for discontinuing it, there might be another or even better way to implement good looking reports internally in LabVIEW without having to buy and rely on third party vendors.

The idea is to enable read access to the "Error List" programmatically (scripting) in LabVIEW.

We have cloud computing, virtual Machines, CPU virtualization etc. - There are numerous ways of achieving parallel and distributed computing, available at different architectural levels. The inherent parallel nature of the LabVIEW graphical programming means we can often achieve parallel computing without thinking.  

 

-But in cases where the programmer actually needs to make a decision we now have the Loop Iteration Parallelism option.
If an action is to repeated multiple times and the execution of each run takes longer than the overhead of communicating the input data, execution code and/or output data across to multiple targets, parallelization can reduce the total execution time, and/or reduce the load on each target. Now, in some cases the execution time can justify parallelization even across slow communication channels. 


What if we expanded the user-friendly loop iteration parallelization mechanism to also support remote processors?

 

  • On the targets we want to offer as execution hosts we will need to install a host service. This service might offer us the choice of offering all, or just a subset of the available cores.  Perhaps even decide this based on the current load on the target, or time of day(!). The targets can be of different platforms as long as the code is possible to recompile for it.

 

So how would this look like to the programmer? Well, we simply extend the for loop parallelization function dialog to something like this:

 

For Loop Iteration Parallelism Across Targets.png

 

  • The loops should also allow this setup to be changed at run-time. You could have a general VI to define the default targets and establish a link to them, and each for loop could have input terminals to specify the parallelism options to be used at the time of execution.

  • Another fun consequence of this functionality would be that you can really distribute *any* part of you code across multiple targets simply by wrapping it in a 1-iteration only loop.

 

With this functionality in place getting 10 machines to work on a heavy problem instead of just one would really be as simple as drawing a for loop...Smiley Very Happy

It seems like it shouldn't be too much to ask for a proper Smith chart (with markers and everything!).  Seems like it's already hiding somewhere...

While the Image datatype is very useful for working with images, there are many functions that are not available (e.g. Square Root, or the Wavelet Transforms).  In order to achieve this, it is necessary to convert the Image to an Array, thereby duplicating the memory required, and then convert back again.  (IMAQ GetImagePixelPtr/IMAQ MemPeek also duplicates data).  I would like to be able to directly access the Image data as a LabVIEW Array.  Perhaps the In Memory structure could be used to achieve this, e.g.

ImageInPlace.png

 

One potential problem is the extra information (border pixels) which are part of Images - for most use cases it would probably be ok to retain these (i.e. the array is larger than the image, though perhaps there could be an option as to whether they are mirrored or zero etc. RGB images would provide an array of U32/64, but even better might be a cluster of arrays for each colour plane.

 

Bonus points for the ability to access an Array of Images as a 3D Array!

 

Many advanced funtions in the optimization and fitting palettes allow the use of a "VI model" given as a strictly typed VI reference to be defined by the user. A great feature!

 

LabVIEW provides various templates containing the correct connector pattern. Here is a list of the templates I found:

 

in labview\vi.lib\gmath\NumericalOptimization:

  • ucno_objective function template.vit

  • cno_objective function template.vit

  • LM model function and gradient.vit

in labview\vi.lib\gmath

  • Zero Finder f(x) 1D.vit

  • Zero Finder f(x) nD.vit

  • 1D Evolutionary PDE Func Template.vit

  • 2D Evolutionary PDE Func Template.vit

  • 2D Stationary PDE Func Template.vit

  • ODE rhs.vit

  • Global Optimization_Objective Function.vit

  • DAE Radau 5th Order Func Template.vit

  • function_and_derivative_template.vit

  • function_template.vit

As you can see, the naming is quite inconsistent:

  • all files are templates as is immediately obvious from the file extension! (*.vit )
  • some containing the word "_template" (undescore/lowercase t)
  • some containing the word " template" (space/lowercase t)
  • some contain the word " Template") (space/uppercase T)
  • some don't contain the word template in any form (good! :D)

 Since the extension fully defines them as templates, maybe the word "template" could be scrubbed from all the filenames, making things more uniform and consistent.

 

Idea Summary: remove the word "template" from all model template names that contain it.

Following Robbob's advice from the end of this http://forums.ni.com/t5/LabVIEW/LV-2009-error-bar-plots-suggestions/m-p/987381/highlight/true#M441998 thread, I'd like to "bump", and extend, X.'s idea posted there:

 

A true, built-in, native (not x-control) error bar option on a standard fully-fledged X-Y graph- perhaps implemented simply as a different bundling of arrays to the graph indicator- eg bundle(Xvals, Xerrs, Yvals, Yerrs) or bundle(Xvals,SD(X), Yvals, SD(Y)). In the latter case, the depiction of each data "point" as a gaussian intensity "blob" would be the answer to a years-old dream of mine...!

 

Thanks for considering....

For the most part coersions can be broken down into two classes: lossy (e.g. 64L to I8) and safe (e.g. U8 to U16). Why is there only one color option for coersion dots?  Could the vi analizer have seperate settings for max allowable safe and unsafe  coersions?

I had the need in the past to draw isosurfaces from 3D volume data. My workaround was to export the data in xplor format (see also), then display the isosurfaces using molecular graphics software (such as UCSF Chimera). This is too indirect.

 

The code to do this directly in LabVIEW exists already in the NI Biomedical Startup Kit 3.0. Look under the section "source code":

 

  • Create isosurface from 3D volume data
  • Draw isosurface for 3D picture control
While the full biomedical startup kit requires quite a few extra toolkits to work, these two isosorface tools can work in plain LabVIEW.
My suggestion is to add these two tools (and maybe others?) to the standard 3D picture control palette of LabVIEW.

They are of general interest. 😄

We really need the LabVIEW Statechart Module to run in LabVIEW 64-bit! Many of our projects are large vision projects requiring lots of processing and hence LabVIEW 64-bit.

 

Please make Statechart Module available in LabVIEW 64-bit!

There are many array functions that don't need to depend on the dimensionality of the array - for example most of those in the "Probability & Statistics" menu (Mean, Median, Std Deviation etc) and some in the Signal Operation (like Scale, Normalize).  But if I want to use one on a 3D array, I must first make a copy by reshaping to a 1D array, which can be very memory-expensive.  I'd like a node on the "In Place Element Structure" which accepts an array of any dimension, and makes the data available as a 1D array of that type.

 

I've suggested a similar idea before here, but perhaps I made it too complicated to receive any comments!  I keep running into this problem, so lets try again.  Smiley Happy

 

These function names create undue confusion. Every semester, new students to LabVIEW post questions on the NI and LAVA forums asking how to use these functions to open, edit or load data from an Excel file (.xls).

 

Unfortunately, the name spreadsheet file has become synonymous with Excel. Even experienced computer users have an expectation of some sort of intelligent file when reading the title "Read from Spreadsheet File".

 

These functions should really be renamed to 'Read from' and 'Write to' DSV file...

 

Delimiter Separator Values  (wikipedia link)