LabVIEW Idea Exchange

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

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.

Labview has a way of creating the equivalent of static variables in a VI similar to static variables in OO languages or function-scoped static variables in C. This way is through the use of uninitialized shift-registers in single-iteration loops (i.e dummy loops).

If multiple instances of a VI is created and the VI contains such a static variable, the value of the static variable persists from one instance to the next. I can see why this is useful, but I think it would also be useful if there was an option to make static variables of different instances of a VI separate.

Static variables are primarily useful for VIs that have some concept of state and you don't want to explicitly create a state variable or cluster that the user has to manually feedback with outside signals. For example, if you created a VI for a PID controller or a state machine, and you wanted to use an uninitialized shift register to store that state, you can not create multiple instances of that VI with out having the two instances intefere with each other. The two instances cannot maintain independent state.

I ran into this problem while creating a VI to implement a moving window of values. (as a side not, it would be useful to have a moving window VI)

It would be nice if we could programmatically set the inclusion of the upper and lower limits in "In Range and Coerce" function by having two additional input terminals in this function. This two extra terminals should be optional. With a value connected, the context menu option should be override.

Now it's possible to do it with a case structure. We may need to have up to 4 cases to cover all possibilities.

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