NI TestStand Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Levic

Drag and drop from LabVIEW function palette

Status: New

For simple operations would be nice to have possibility to drag and drop functions from LV functions palette directly (default step type can be Action)

 

Match pattern insert.jpg

6 Comments
crelf
Trusted Enthusiast

Hmmm - I wonder if we could have an option to have just the LabVIEW palette open when working with TestStand...





Copyright © 2004-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.
Raydur
Member

This would be very nice. Many times I just want to call a simple VI that is already built into LabVIEW, but instead have to create a wrapper VI just to bring it outside of LabVIEW to call within TestStand. Seems very redundant, and creates additional file management that would otherwise not be needed.

RayFarmer
Trusted Enthusiast

 Raydur, if you already have a VI built whether it's in the Labview vi.llb folder or one of your own then all you need to do is browse for it with the 'Browse for VI' button.

There is no need to create a wrapper.

 

But I do like the idea of having access to the LabVIEW palettes from TestStand it would make it a lot easier.

Regards

Ray Farmer

Regards
Ray Farmer
Raydur
Member

RayFarmer - for VI's I've built this is relatively simple. For VI's built into LabVIEW I find it difficult to actually locate where these are. Is there an easy way to do this? Using the example of the OP, if I wanted to call the VI from the LabVIEW String pallete "Match Pattern" - where would I browse to find this VI, or more generally how would I know where to find this? If I browse to vi.lib/string there isn't anything pertinent there. Is there a way to tell where the library is that contains a built-in VI? Is there some logic behind the pallete groupings and where the actual VI is located on disk?

 

Thanks

warren_scott
Active Participant

It sounds like we are trying to create a crutch to add needed functionality to the TS language -- If there's features native to LV that we are needing to call, shouldn't these be added to the TS language itself rather than adding the overhead of calling to the LV engine, LV executing the code, and then returning data back?

Am I missing something here?

Levic
Member

warren_scott - you are right that it's overhead, but LV is far in front of TS, so a lot of functions in TS language are missing; the intension is to use what we have in LV already