LabVIEW Idea Exchange

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

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

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

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

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

 

Hello,

 

Burst random signal is commonly used for vibration test with shaker. LabVIEW has some random signal generator in original functions, time series analysis toolkit, but not burst random signal. If LabVEIW does not feature burst random signal, it is difficult to suggest shaker vibration testing with LabVIEW.

Now we have to compete with other NVH vendors such as LMS, B&K, however lacking of basic functions might be kind of obstacle for DSA business. Even Ono Sokki and A&D who are automotive testing supplier in Japan can offer it, NI should do to meet customer's expectations.

 

Saku Kakibe

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

Currently, when converting a longer integer type (e.g. u32) to a shorter integer type (e.g. u8), the output value wraps.

 

By contrast, when converting a floating point type (e.g. dbl) to an integer type (e.g. u8), the output clips.

 

conversion.png

 

It would be great to be able to specify the output mode for conversion to integer: Wrap or Clip!

How could a user know if a block he is using is slow or fast?

For example, Variant attribute is organiazed in a red balck tree, thus, a search is O(log(n)) while a regular array search is much slower O(n).

At the moment there are two options:

 

1. Benchmark each code section.

2. Read about tricks on the forums.

 

Instead, if NI added efficiency alanisys to each function with a simple automatic tool then we could easily find what we are searching for.

 

Using the Distortion Meter and Spectrum Analyser for measuring signal distortion will give a definitive numerical value, but what does the distortion

look like? In the case of a sinusoidal waveform, is it clipping or crossover distortion for example. This needs to be known so one knows which part

of the circuit design needs closer inspection.

 

One can, as I often do, use a resistive network to sum an output signal to a reversed polarity input signal. However, it is a real pain adjusting the

two signals to balance to a null at the resistor centre point. Ah, you might say, use the differential  inputs of the Oscilloscope to subtract the signals

and view the error. This has two gotchas. One being there is no variable Y gain on the Oscilloscope to finely null the two signals, the other problem

is there will more than likely a time/phase difference between the inputs, thus preventing complete cancellation.

 

For the above reasons, if the Distortion Analyser had an output which showed the residual signal upon which it’s distortion figure is measured,

I would be a very happy bunny.

 

Ooh, whilst I am here, if an NI MultiSim developer happens to have nothing to do for a day or two, could a variable gain be added the Y input attenuator

of the Oscilloscope?  🙂

 

Thanks,

Keith   

For those measuring differential signals, having balanced inputs on both the Spectrum Analyser and the Distortion Meter would be an invaluable asset.

The Oscilloscope has this mind boggling feature, would so useful if it were added to the afore said instruments.

 

Thanks,

 

Keith 

This proposed new VI would expand upon the Clear Errors VI, and keep a history of the error codes that have been cleared. Ideally, it would have a History Length input (not shown) that, when not wired, would default to 1024 errors.

 

ClearErrors+History.png

 

 

I was wondering if anyone else would like to see some bootstrapping and permutation test functionality added to labview.  I find myself having to use MatLab's statistical toolbox which has a solid amount of statistical resampling methods.

In the series "Intended versus expected" (or blue versus orange), this is a discussion of a not very helpful feature of the Ramp Pattern VI:

 

ScreenHunter_001.jpg

 

If you ask for a single sample (samples = 1) from the Ramp Pattern AND do not set "exclude end?" to True, the VI returns an error -20006: "Analysis:  The number of samples must be >= 2."

The Help specifies that: " If samples is 1 and exclude end? is TRUE, the VI returns an array with one element of start."

It doesn't say anything about the situation I described previously, but most likely the error comes from the likely following definitions of the array {xi} of values (in the linear case):

 

1) exclude end? xi = xs + i*(xe-xs)/N, where i = 0,..., N-1 and (xs, xe) are the start and end points respectively

2) do not exclude end: xi = xs + i*(xe-xs)/(N-1).

 

In the second case, N = 1 results in a division by zero, hence an error.

 

So far so good, but here is the catch: Suppose I want to build a curve with equidistant abscissa (number N), comprised between a start and end points xs and xe (both included). It seems like the Ramp Pattern has been designed for me, right?

 

Wrong. If I set xs = xe and N = 1, I would expect a single point, equal to xs = xe. Instead, I get an error. So my first contention is that this should be a detected case: xe = xs AND N = 1, should result in a single element array equal to xe = xs.

 

Now, what I would suggest is that if xs != xe AND N = 1, then the Ramp Pattern could return a single element equal to (xs + xe)/2 (and a similar definition for a logarithmic ramp).

LabVIEW should ship with a Set Operations palette item, including the common operations such as Union, Intersection, Complement, and Cartesian Product, as well as more advanced operations that I don't know about. These operations would act on 1D arrays of almost anything. Floating point numbers and those would have to have some kind of "error in value" input that defaults to the machine epsilon or equality checking. Output would be a 1D array on the input datatype with the values, and perhaps an output for matched indices.

 

Yes, these are quite easy to make yourself (loop+search), but I think that it would be beneficial for the community for NI to provide it. The VIs found at http://zone.ni.com/devzone/cda/epd/p/id/3929  are... Interesting, to say the least. NI might be able to provide better performance, too.

I don't know much about the AVI format, so I am unsure if this is even possible.  But I would love to have the following additional functions in NI Vision's AVI aubVIs:

 

 

  • Delete AVI frame
  • Insert AVI frame

I need the IMAQ Correlate function

 

imaq correlate.PNG

 

to work on a sub-pixel (super resolution) basis. For sub-pixel resolution capability, you will have to change the internal mathematics of this function for floating point calculations.

 

This function, as I am recommending for all of the Vision functions, should be made compatible with U16 image type as well.  (Currently, it is only compatible with U8 image type.)

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

 

 

 

 

I've posted an idea, but didn't add any pic to explain:
http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/16975/tab/rich

 

 

I've attached an image with this idea. Sorry for the duplicate posts.

These are simple examples but can get more complicated. For example, usage 2 can have more input (e.g. 4) it will have 16 possibilities which have different simplified code.

 

USAGE 1: User wires some input on the block diagram, when the simplify button is used, it simplifies the complicated code to a simple one ( noting that it is not the unique solution as shown in USAGE 3)

USAGE 2: If for the application, the user changes the value of the input and he gets different output; this table can get the simplified; or the "best fit" for the number of data present.

 

In http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/16975/tab/rich, I wanted to compare that  Partial fraction expansion vi is not widely used except for certain applications yet it is important and beneficial.

Same goes for this idea.

 

Best


 

There are alot of applications that require the use of Booleans, and when the boolean expression gets complicated or large it will be a headache on the programmer.

LabVIEW should try having a De Morgan law "function" or at least a way to simplify complicated Boolean expressions. Although it won't be used as much, it will be a handy tool for any electronics/programming course.

For instance, Partial fraction expansion isn't used regularly but when it's used it helps save time.

 

These are simple examples but can get more complicated. For example, usage 2 can have more input (e.g. 4) it will have 16 possibilities which have different simplified code.

 

USAGE 1: User wires some input on the block diagram, when the simplify button is used, it simplifies the complicated code to a simple one ( noting that it is not the unique solution as shown in USAGE 3)

USAGE 2: If for the application, the user changes the value of the input and he gets different output; this table can get the simplified; or the "best fit" for the number of data present.

 

In http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/16975/tab/rich, I wanted to compare that  Partial fraction expansion vi is not widely used except for certain applications yet it is important and beneficial.

Same goes for this idea.

 

Simplifying Boolean.png

We have the VI reporting Palette and it works very nicely for putting together documentation about VIs that we are using.

But what happens if we want to make a report that details ALL of the files in a project? We have to take a very convoluted route to get the list of files (Project>File information only lists the NI filetypes used in the project and not *.doc;*.jpg etc - these may be neccassary for the project when deployed)

It is possible to programmatically create this list using Property nodes, etc and create the list of dependencies if you start getting fancy.

 

But try documenting how a build specification was setup so someone else can ensure they do exaclty the same in 6 months time if the project file has been changed or corrupted...

The XML tags in the lvproj file change all the time and there is no documentation on these

 

From NI tech support:

"We do not have any documentation (internal OR external) that provides the information about all the XML tags; it simply doesn't exist.  R&D would certainly like this information to be available, and they suggested you post this idea at the Idea Exchange.  If this idea gets enough customer interaction, then we would definitely consider developing this in a future version of LabVIEW."

 

http://lavag.org/topic/11673-programmatically-build-new-project-problem/page__p__70683#entry70683

 

 

In short:

Documenting the Build specifications, the list of Project files and the list of dependencies with the Reporting palette would be a massive feature. to have to run on any project and would allow the ability to create build reports containing lists of VIs and their revision numbers for each release.

(Very important for some of my clients)

 

Just documentation on the XML tags would allow us to do more stuff like this:

http://forums.ni.com/t5/LabVIEW/How-can-I-set-a-build-specificaiton-s-target-filename-and/m-p/1812480#M623328

LabVIEW should support loop unrolling...

 

For those who do not know what loop unrolling is (from wikipedia http://en.wikipedia.org/wiki/Loop_unwinding)

Loop unwinding, also known as loop unrolling, is a loop transformation technique that attempts to optimize a program's execution speed at the expense of its binary size (space-time tradeoff). The transformation can be undertaken manually by the programmer or by an optimizing compiler.

 

The goal of loop unwinding is to increase a program's speed by reducing (or eliminating) instructions that control the loop, such as pointer arithmetic and "end of loop" tests on each iteration;[1] reducing branch penalties; as well as "hiding latencies, in particular, the delay in reading data from memory".[2] Loops can be re-written instead as a repeated sequence of similar independent statements eliminating this overhead.[3]

 

Example with textual programming language:

 

int x;
for (x = 0; x < 100; x++)
{
   delete(x);
}

 

Becomes:

 

int x;
for (x = 0; x < 100; x+=5)
{
   delete(x);
   delete(x+1);
   delete(x+2);
   delete(x+3);
   delete(x+4);
}

 

Who is with me 😉

It would be nice if there was a IMAQLinearSums to compliment IMAQ LinearAverages.  Here the sums across rows and/or columns would be calculated.

Using the 3D Surface Plot in LV2011 it is possible to switch on or off either "Surface", Mesh" or "Normal".

Being in the need of the surface normal angle for some calculation I was told that this data is not accessible through property nodes.

 

I would really prefer accessing this data instead of calculating it twice!!!

 

 

And by the way: Displaying large data arrays in 3D Plots takes computing power running on one core only. Wouldn't it be possible to have a parallelizing option here...