LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Problem:

When you want to have the organization of your files within the project file different from the folder hierarchy on disk you are not able to connect to a vi dynamically through vi server because you simply do not know the path which the builder has created within the executable.

To rebuild and maintain the folder structure of the disk in the project file is time consuming and error prone.

Solution:

A small tool which extracts the actual paths within the executable so you can copy the correct path to your vi-server call would do the job.

View All (3)

I miss the ability to wire a cluster reference to (un)bundle by name nodes. If I have some parallel processes that share a common configuration bundle for my project, I'd really like to be able to only have one copy of the bundle in memory. This is possible if I use a reference to a cluster. However if I do that it gets really complicated to get access to the content of the bundle. If I use 'property node --> value --> unbundle' I load the bundle into memory anyway in an extremely inefficient way before extracting the control of interest. If I use 'property node --> controls --> index --> variant to data, everything is suddenly very fragile to cluster changes, not to say needlessly complicated.

If you could (un)bundle a control directly from the cluster reference you would have easy and very efficient access.

What should then happen for non control references? I'd say the same as 'property node --> value' with the name of the control displayed. It could even be possible to access variant data by using the variant --> cluster -->variant functions.

Of course this method is subject to race conditions, but that is always the case when you use references anyway.

I'm currently working on a project where I have 9-11 active parallel processes where each process needs access to the configuration cluster. Thus I have 9-11 copies of all my configuration data in memory all the time. I'd really love to reduce that number to one.

This is my first post here. I did check for similar ideas, but I didn't find one.

-Henrik, Denmark

As a LabVIEW user, I would like to see who has called the current VIs when a breakpoint is placed on it.

From the stack view, when a vi is double clicked, the corresponding vi block diagram should open highlighting the block diagram area from where the call is made to the next vi.

If posssible the stack view can show the inputs and outputs of all the VIs in the stack view.

An example screen is provided as an attachment.

View All (1)

XControl / dataflow

Will be great if exists a function to convert any numeric type to byte array or any numeric type array to byte array

like Array to String Function and fast like.

Now we can use typecast function to do this, but is very slow, compared with string to byte array function.

Split or Join numbers function are not pratic if we splitting u64 numbers from to u8 numbers and generate local

copies of numbers.

u32--------------DD---------------[u8]

u64--------------DD---------------[u8]

[u32]------------DD---------------[u8]

[u8]--------------DD---------------[u32]

[u8]--------------DD---------------[u64]

View All (4)

Make locals good again

I fear this may be an old-school post, but unless I've missed a recent update, it's my understanding that fundamental LabVIEW teaching is that Locals duplicate memory and should be sparingly used. I've always known it, and I've ALWAYS disobeyed it. I love locals and I think they make code cleaner and encourage their use.

So my idea is, if Locals waste memory, please make them NOT waste memory. A local should be the functional equivalent of updating a Value Property Node in LabVIEW, and of stating VarName = 1234 in any other programming language in which I can set the value of a variable as often as i want anywhere I want, and it doesn't waste memory. So if we can make Locals good again, all the more harmony.

Here's hoping this is a good/novel idea, yet if it's already fixed then Kudos to NI. I'd hate to think they have structures in LabVIEW with a note that says "PS... don't use this" in the training material.

If I'm wrong about their fundamental behavior now or earlier, let me know.

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)

View All (2)

A programmatic eevent can be generated using val(signal). The problem is that every time val(signal) is called it generates an event, (even when it is a non [false] event). Just like keyboard events that only occur when a key is pressed (and/or released), can val(signal) be modified to respond in the same way. In other words, if val(signal) is given the value "False", it should not generate an event, only generating an event when val(signal) is "True". This would make code writing so much easier and stop the possiblity of potential race conditions.

I have a multiple step ATP systems that Operators would like to see Gray for Not tested, Red for Fail and Green For Pass. Currently I overlay two boolean indicator Enable the correct one and set it to true. It would be great to have a single boolean indicator with tri color output.

The second element in the ROI cluster is an array of Contours yet many sub vis will only act on the first contour in the array. Both the required contour descriptors(line and annulus) are available in the example image, but since the first element is a line, the circular edge find - which wants the annulus - throws an error.

All it would take would be a simple index and logical test to fix this issue.

All the simple Numeric operators (add, subtract and multiply) do not show red dots when you wire, say, two integers. "Divide" does, but should not! The Divide operator coerces everything to a double!...

In all other languages, if you use the divider operator (the slash /) it conforms to the operands passed: divide a double by a double and you get a double; divide integer by integer and you get an integer.

Please make the Divide operator not upcast to a double!

NI smartcams + VBAI provide a really neat and fast way to get results in image processing - however, predicting their performance is close to impossible. Information like "DSP coprocessor" is nice, but it's not adding any information that I can use.

I have benchmarked the devices that went through my hands with some standard resolutions+ROIs and algorithms, so I have some idea, but most of the time I just wonder "Would this work on a 1774?" "Would it work on something slower?" I usually call an engineer and try a loan device, but this takes time and rather static concepts.

I know that algorithm runtimes (especially the more complex ones) strongly depend on the sample data, so it's not just a matter of scaling, but even an estimate (like 8-12ms) would improve my experience rapid prototyping.So, I'd just use Profile->Performance Meter -> Profile for NI 1772..

View All (3)

View All (5)

Adaptable Subroutine setting

Life can be a real beach when working on a load of high-performance VIs which have a bug somewhere. First spend half an hour un-setting "Subroutine" on a tree of VIs, then find the bug, spend another half an hour re-enabling sub-routine execution and then spend a further half an hour finding the last subVI you forgot because you've noticed a problem when benchmarking......

How about setting a VI to conditional subrouting meaning that it retains its subroutine status until you place a probe or breakpoint in it (It would be nice if calling VIs adapted also of course). As soon as the breakpoint / probe are removed, return as normal to subroutine execution. Man would this save a lot of time.

Shane.

View All (1)

Hello!

I hold many different revisions of my projects on my PC, and am not currently using Perforce or any other source control. As the mass compile tool stands now, if I were to mass compile a directory which contained the latest version of my project, it would search through all of the files on my hard drive and link or relink VIs to the first version of files that it finds. My project would basically link some Vis correctly and to old or outdated versions of VIs or DLLs in some cases.

I would like to suggest that the mass compile feature in LabVIEW allow the user to specify the folder or hard drive location where the desired source should be located. Currently we're only able to point towards the directory where the broken links exist. It would also be nice to have a checkbox feature to include the subdirectories below the top level desired source directory.

Cheers!

Shawn S.

View All (9)

comment icon for large comments.

I find that my code window quickly becomes filled up with comments and notes. Could we, maybe, have a small comment icon, which we can put in the code and which displays the comment when you hover your mouse pointer over it?

My present workaround is to put larger comments in the documentation window and number them, so that I just have to put a reference number in the code. Maybe these two documentation devices could be dynamically linked together somehow.

LabVIEW Idea Exchange

Building Executable - Vi Server Calls

Have (un)bundle by name accept references

Call Stack for Debugging VIs

Linked Input Tunel - Create & Wire ....

XControl / dataflow

Bullet to Convert Any Numeric Type or Numeric Array to U8 Array

"Is Member of Array?" primitive

Make locals good again

Labview Static Variables and VI Instances

Programmatic Event Generation

Tricolor Single Boolean Indicator with Gray Default, Green Pass and Ref Fail

Smart ROI selection for multiple functions

Numeric "divide" operator should not upcast to a double

Tunnel Concatenating ... only with array, doesn't work with string !

Change the data content on a wire dynamically in the case of a breakpoint via a probe in order to continue to debug an application.

Profiling estimates/Emulator for Smart Cameras in VBAI

Set Default VI Properties Globally

Adaptable Subroutine setting

Mass Compile Improvement: Broken Directory and Source Directory

comment icon for large comments.