LabVIEW Idea Exchange

The Attached code calculates the square root free Cholesky factorization (LDL'), it is very useful to decompose matrices and in my specific case, to make observability analysis within electrical distribution networks. I'm publishing it because LV counts with other kind of decompositions like the LU decomposition, very useful but for my case, the values delivered by LDL' are more accurate and easier to calculate.

Best regards

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:

-Carl Wecker

It would be great if LabVIEW supported the Python language, including any of its various packages such as numpy. Such computations would be much more transparent and easier to support than calling code in DLLs. They would also be much more open and flexible than the existing built-in computational solutions in LabVIEW, e.g., expression/formula nodes. Currently, I have to call Python scripts via System Exec.vi, which complicates data exchange. (NOTE: I am using an older version of LabVIEW: 2009 SP1.)

Add field witch shows the size of the array.

So simple but so helpful

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.

Many of the Mathematics and SIgnal Processing VIs retain state, rendering them unusable inside reentrant VIs: http://digital.ni.com/public.nsf/allkb/543589DF37BA48CF8625744A00543FF3

Many of the VIs in this list (all those in my current application, unfortunately) can only work with single-channel data. When manipulating multi-channel data, you can work around that fact by running the channels serially through the VI you need, but that (1) takes much longer for large data sets or several channels, and (2) is not an option when performing live manipulation of streaming data block-by-block.

I ran into this problem while developing code in the Actor Framework, where Do.vi and Actor Core.vi (the two main framework methods) are both Shared Reentrant. Now that AF is a native feature in LV, I expect that more people will run into problems with these VIs.

We need stateless versions of these VIs so we can use multiple copies in on a multichannel data set. You can probably keep backward compatibility by pushing the core logic to a new stateless subVI and keeping the shift register or feedback node on the main VI's diagram.

It is time to put a dent in the floating point "problems" encountered by many in LV.  Due to the (not so?) well-known limitations of floating point representations, comparisons can often lead to surprising results.  I propose a new configuration for the comparison functions when floats are involved, call it "Compare Floats" or otherwise.  When selected, I suggest that Equals? becomes "Almost Equal?" and the icon changes to the approximately equal sign.  EqualToZero could be AlmostEqualToZero, again with appropriate icon changes.  GreaterThanorAlmostEqual, etc.

I do not think these need to be new functions on the palette, just a configuration option (Comparison Mode).  They should expose a couple of terminals for options so we can control what close means (# of sig figs, # digits, absolute difference, etc.) with reasonable defaults so most cases we do not have to worry about it.  We get all of the ease and polymorphism that comes with the built-in functions.

There are many ways to do this, I won't be so bold as to specify which way to go.  I am confident that any reasonable method would be a vast improvement over the current method which is hope that you are never bitten by Equals?.

The lack of 64-bit Labview support has been fustrating. Having the availability of Labview 64-bit for so long now but still limited by the features that are not supported (slow to recieve toolkit support, mathscript, etc.)

I am in need of accessing common data types such as HDF5 and EDF. Discovering that these formats are avaialble in dataplugins was exciting, however to find that they dont work in 64-bit Labview was dissapointing.,

Regards,

Brian

Hi,

for a complete validation of a software, it is mandatory to perform tests. When testing, we differ between two major tasks:

- static code analysis

- dynamic code analysis

For static code analysis, we got the VI Analyzer toolkit. It automates the task of looking into the sources (front panel and block diagram) and compare the current layout against recommended layout (style guide). Additionally, it detects known sources of issues for lack in performance or even crashes and misbehavior during runtime.

So it makes perfect sense, to define requirements that static code analysis has to be performed before proceeding to dynamic (runtime) code analysis.

Yet, VI Analyzer tasks have no option for creating such a link as a field "comment" or "description" is missing for the configuration!

I suggest to add such a field in the cfg-file level (exported VI Analyzer configuration) where we can add strings like [Covers: <req_ID>] as we are used to in LV code.

Norbert

The Timing palatte is looking bad with all thes gaps.  A simple fix would be to fill these holes with useful functions. I'm proposing 3 and attaching 2 from my re-use code. (I may re-create the third later)

Time to XL.vi (Attached): and its inverse, XL to Time.vi

12:00:00.0 AM Jan 0, 1900 is a pretty common epoch (Base Date) for external programs and converting from LabVIEW epoch shows up several times a year on the forums. and Time to excel has a few solutions to threads under its belt.   Moreover for analisys against external data from other enviornments you are often using Access, Excel, Lotus... All share the same epoch (and Leap year bug) in their date/time formats.  These vi.s have been pretty useful to me although the names may change to avoid (tm) infringements

Time to Time of Day.vi (Attached) has also been in my arsenal and proves both valuable and get on a few threads per year on the forum.

The gaps in the palatte make it a perfect fit

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.

When you or two numeric numbers it does a bitwise or.  The same should happen when using Or Array Elements, but it is not supported for numeric arrays. I see no reason why it shouldn't work just the same?

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

LabVIEW  has a somewhat hidden feature built into the variant attributes functionality that easily allows the implementation of high performance associative arrays. As discussed elsewhere, it is implemented as a red-black tree.

I wonder if this functionality could be exposed with a more intuitive set of tools that does not require dummy variants and somewhat obscure VIs hidden deeply in the variant palette (who would ever look there!).

Also, the key is currently restricted to strings (Of course we can flatten anything to strings to make a "name" for a more generalized use of all this).

I imagine a set of associative array tools:

• Create associative array (key datatype, element datatype)
• insert key/element pair (replace if key exists)
• lookup key (index key) to get element
• read all keys
• delete key/element
• delete all keys/elements
• dump associative array to disk
• restore associative array from disk
• destroy associative array
• ... (I probably forgot a few more)

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.

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

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++.

Being in line with the expansion of LabVIEW and its products worldwide where ever we have more users, it is necessary to enable a space dedicated to present ideas for other supported languages.

I use fixed point values quite a bit, and i do find myself splitting and joining them quite often when I have to roll my own low-level, optimized operations. 

The fixed point type is (generally) treated as an arithmetic type (e.g. floating point) rather than a logical type (e.g. integers). The (default) configuration should maintain this behavior.

What I would have found most useful is having Split cut the value in half and return the two properly configured fixed point values. Join would take two adjacent fixed point types and glue them together into one value. This definition would actually make Join equivalent to adding the two values.

Split could take an optional split location which dictates the binary point at which the values are split apart. I suggest defining the value as the location of the lsb (least significant bit) of the high part. In the example, the value would be 0 to get the equivalent behavior. This terminal would require a (immediately computable) constant wired to it since the fixed point output types can't be computed until this value is known.