LabVIEW Idea Exchange

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

Languages like 'R', 'Python', and MatLab (yes I use the old name) have these.  They are useful.

 

One of the key ideas in LabVIEW is that the user needs minimal interventions to code a useful result.  As more information is encoded in a data type there is more opportunity to make "hands free" code that "just works".  I think these two data types can do that.

 

Data Frame:

  • Primary data type in R
  • It is Array-like, but NOT an array
    • each column contains one measurement (row) on one variable
    • It acts like a list of vectors, but the vectors have the same number of rows, and indexing allows a return of all or subset from all columns
    • column types are heterogenous - they can be different
    • column types can be set.  A column of 0 vs. 1 can be set as factors/binomial values or as continuous.

There are functions that data analysis folks do every day that are informed by variable type, so the function operating on the inputs doesn't need type specified because it is interior to the table.  This means you can say "plot(mydata)" and if your data is set up well, the graph parameters are already specified and useful.

 

Some references:

 

Data table:

This is from Hadley Wickham, a very famous person in 'R'.  He does great work, and his name has high brand value in data-analysis.

 

It:

  • Uses the "data.table" package
  • is able to be screaming-fast (think roller-coaster) especially when used with the "split-apply-combine" approach to data analysis, and SQL-like operations.
  • is built for handling huge data (100GB tables) quickly and efficiently.

In many applications the same operation is not possible due to memory constraint or viable due to processor overhead can execute adequately (aka wonderfully) by using this data type on the same hardware.

 

References:

 

 

 

 

I would like to encourage NI developers to produce an Advanced Signal Processing Toolkit (with the wavelets functionality like the one for WINDOWS) for MAC OSX.  I have been using Labview for some time now but i really dislike having to change OS platforms just when i use wavelets.  I am sure I am not alone here as there are many using Labview in the OSX environment.  

I suggest to add the following tools to the Number/string conversion palette:

 

Number to Roman Numerals

Roman Numerals to Number

 

Here's how they could look like on the block diagram. A simple draft of these function can be found here.

 

 

 

Idea Summary: Add conversion tools for roman numerals to LabVIEW

Direct to PDF reporting is an extremely important feature to provide customers.  It cannot be relied upon that the customer has MS Word or the like installed.

There are a couple of LV PDF toolkits supplied by developers.  However, the problems with these include that they are (a) not updated or well-supported (b) buggy (c) have out-dated dependencies such as .Net 2.0 (d) restrictive licencing for deployment.

Good reporting tools are essential and NI should develop and support a direct to PDF toolkit.

Most fitting VIs have a mandatory input for X that is required to be the same sizes as the Y input. If left unwired, an error results, even though the x input is not designated a a required input for some reason.

 

Many times we want to fit a plain 1D array where the X value for each Y is simply the corresponding array index. In this case, the data and best fit arrays can be graphed on a waveform graph and we can ignore x entirely. This is now much cleaner and simpler than to construct the data for a multiplot xy graph.

 

Here is an example of a polynomial fit to a sine function, showing what we currently need to do. This idea would eliminate the need for the small FOR loop and associated wires:

 

 

 

My Idea is that most fitting VIs should assume a simple ramp if X is unwired.


(Applies to all fit function that have an X input and generate an error if it is left unwired: linear fit, polynominal fit, etc. )

 

 

Exceptions:

Fitting VIs that currently don't have a mandatory x input, e.g. "Nonlinear Fit" don't need to change, because it is up to the model to make assumptions about x. We already have full flexibility.

 

 

 

After looking at the problem encountered here, it turns out that LabVIEW seems to make some insane choices when mixing a waveform with simple datatypes. Some behavior is good and intuitive. For example multiplying a waveform with a scalar applies the multiplication to the Y component only, because it would not make sense to e.g. also multiply the t0 or dt values.

 

It is less clear what should happen if multiplying a waveform with an array. Intuitively, one would expect something similar to the above, where the Y component is multiplied with the array. Unfortunately, LabVIEW chooses something else: It creates a huge array of waveforms, one for each element in the array. (as if wrapping a FOR loop around it, see image). If the waveform and the array both have thousands of elements, we can easily blow the lid off all available memory as in the quoted case. Pop! 😄 But the code looks so innocent!

 

 

I suggest that operations mixing waveform and simple datatypes (scalars, arrays) simply act on the Y component as shown.

 

(not sure how much existing code this would break, but it actually might fix some existing code!!! :D)

While the intrinsic Math functions all support EXT, DBL and SGL, few of the remaining Math (or Signal Processing etc) functions support anything except DBL.  For many cases, using SGLs is sufficiently accurate, while using less memory and often being faster to compute.  While some functions are implemented solely in G (and therefore it is easy to create an SGL copy, though not so easy to integrate in a "polymorphic" way into the existing menus), most functions call a DLL routine.

 

I suggest that SGL (and CSG where appropriate) be supported for all Mathematics functions, including Signal Processing, and the Advanced Signal Processing Toolkit.  Is there anyone else who would make use of these if available?

 

Note: two "addons" have been released by NI which begin to address this.

 

Single-Precision Basic Linear Algebra Subroutines (BLAS)

The Logical Shift, Rotate, Boolean Array to number and Number to Boolean Array primatives should work with 64 bit values. Currently they are restricted to 32 bit values.

Currently, the only representation for array indices is I32.  Given that indices can only be positive, and that modern systems are 64-bit, it would seem sensible to make this U64.

Analagous to replacing wire connections with a Shift Register on a While Loop, it would be nice to replace the connector where a wire enters an In Place structure with one of the appropriate accessor functions (Unbundle/Index etc).  In the same way, it should prompt for the location on the other side of the structure, either to replace a wire connection, or to create a new element.

I would love an update to the signal processing VI's contained in NI_MAPro.lvlib to support waveforms with a SGL Y-value representation. The library is locked and most VI's call dll's that are not able to be modified anyways (by me that is, I am not all that strong in traditional text based languages). It would be nice to also support SGL waveforms within the .llb's contained in vi.lib/measure; although these are mostly unlocked and able to be modified.

 

Working with a cRIO, the FPGA to host DMA channels encourage the use of SGL data type so I went with it and kept it as SGL throughout my application. For some functions I turn my SGL array into a waveform with SGL Y-value representation. I was disappointed to learn that most of the signal processing waveform tools contained in NI_MAPro.lvlib do not support the SGL Y-values.

 

 The predessesor application was done on the usb cDAQ line that i was using DBL representation Y-values. I want to re-use a lot of code and was hoping the waveform signal processing VI's would accept SGL Y-values. For now I am stuck converting my data type for the sole purpose of re-using code; at 50kHz on 36 channels this can become a performance issue.

There is no way to get to the GObject property of "Position" in the dialog box. Its only available via property nodes, but if you want to statically set the control position, this is a pain.

 

I run into this when I have multiple, similar VIs that i insert and remove into a subpanel. in order to set the controls to be in the same position across the VIs, i have to use the property node for a 1 time use. 

 

When a folder under source control is added to the VI analyzer the subfolder for version control is inserted too. Lets get around this by allowing patterns for folders (or files too) which should be ignored. So adding ".svn" would solve the problem of files of subversion being checked.

I see three possibilities to save the patterns:

- for each top level folder

- in the configuration file

- globally (not preferred, other users do not get the setting)

 

(There is a discussion about VI Analyzer and SVN under http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=290839#M290839)

 

Greetings,

shb

 

It is a little know feature that "interpolate 1D array" also accepts arrays of xy points. (Here's an example from this post)

 

 

However, these days I mostly do xy graphs using complex data (RE=x, IM=y), and it would be useful if "interpolate array" would also accept complex arrays the same way, interpolating IM based on RE, in this case.

 

Here's similar code (fragment) using complex, but now it's not possible to interpolate the xy data directly because complex is currently not a valid input.

 

 

Suggestion:


Similar to xy graphs, interpolate array should accept complex arrays and it would act the same as when an array of xy points is wired to it instead.

 

The current set of Bessel functions supplied in LabVIEW Core only allow for real arguments and outputs. This limits the usefulness of LabVIEW in certain areas of science where complex Bessel functions are required for calculations (i.e.. acoustic modeling). The Mathscript RT module has Bessel function calls that support complex arguments so it's not like the coding doesn't exist. This is one area where LabVIEW is deficient as compared to Mathematica and Matlab and can be easily corrected without forcing the user to buy the Mathscript RT Module.  

I would like to see the array palette to be extended.

 

For instance, a function that is similar to the 'find' command in Matlab. So basically an extentson of the current 'search 1D array':

1. to more dimensions (one can easily define a search order).

2. the function should return all indices where the requested value was found, not only the first one.

 

A further extension would be a 'find and replace' functionality.

 

Steven

 

 

Random Number (0-1) Function from Numeric palette is widely used, but it misses such important feature as Seed to initialize a pseudorandom number generator.

Seed is present in TestStand's Random() function for instance and described there as: "An optional number the function uses to determine where in the virtual sequence of random numbers the function obtains its random numbers. When you seed the Random function with the same value, subsequent calls to Random return the same sequence of numbers. If you pass a seed value of 0.0, the function generates a seed value based on the current time. If you do not pass a seed value, the function returns the next number in the current sequence of random numbers."

Working in an GxP environment in the pharma industry, any initiative to make NI software products more compliant with the FDA guidelines would be most welcome. One such relatively simple measure would be to enable "sealing" of TDM files, such that any tampering with the data is either impossible or logged.

 

I believe I have passed this idea on to NI several years ago and I apologize if it has been implemented already.

 

Yours

 

Sebbe

Cygnus Data, Göteborg, Sweden

Many languages have that, why not LabVIEW?

 

See here for implementation details.

 

This would help me out loads to solve Project Euler's problem faster, at this moment LabVIEW is ranked 53, it would be nice if we had tools that help us improve that.

The PID Autotune would be much more useful if it were refactored so it could run on RT targets.  I would suggest replacing the embedded calls to viserver to open up wizard panels

with a MVC architecture that would allow a better separation of the core PID logic and the HMI components.