LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Searching existing VIs for content

Hi,

 

I'm used to text-based programming languages. There, if I have a problem that I know I've solved in the past and want to recal how I did it, I can run grep (or similar) in a root directory and quickly find the required files. Usually the hits come from the comments I've written. Now that I'm learning LabVIEW I'm finding this isn't so easy. I've got a bunch of directories and a bunch of VIs, with only their file names to guide me. How do I go about doing something analogous to what I'm used to with text-based languages?

 

 

Thanks

0 Kudos
Message 1 of 9
(3,059 Views)

Bookmarks, Text Searches, VI Documentation


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 9
(3,048 Views)

I read up on the terms you list, but from what I can tell these things would be most helpful if I already have the VI open. What I'm wondering, is how I can search for the one VI somewhere in my directory tree, where in the past I solved a particular problem. I can see that it would be a good idea to describe what the VI does using the Documentation property. So I could write in the docs that this VI uses foo bar to perform operation X. But then, a while later, I need to search for X and foo bar in (presumbably) the OS file manager or command prompt. Now what?

 

 

0 Kudos
Message 3 of 9
(3,036 Views)

@raacampbell wrote:

I read up on the terms you list, but from what I can tell these things would be most helpful if I already have the VI open. What I'm wondering, is how I can search for the one VI somewhere in my directory tree, where in the past I solved a particular problem. I can see that it would be a good idea to describe what the VI does using the Documentation property. So I could write in the docs that this VI uses foo bar to perform operation X. But then, a while later, I need to search for X and foo bar in (presumbably) the OS file manager or command prompt. Now what?

 

 


That's why you work with projects.  Just like other text based languages, you don't usually open the text files one at a time you open the project and then drill into the files you want.  In the same way if you work with a project in LabVIEW you have all VIs in memory and can perform a string search (CTRL + F) and find all the comments you left on your code.

 

A new thing in 2013 is bookmarks which can be found using the # symbol in a comment.  This again works best with a project because all the files are already in memory.

 

If you insist on not using a project you can still open a VI reference and do the search your self, finding all the places a comment contains the string you left, or in the VI documentation.  Also the VI Documentation is actually stored in plain text within the VI file so searching can be done with conventional search methods if you force it to treat the VI file like text, or write your own searching method.

Message 4 of 9
(3,017 Views)

Likely I'd work with projects a lot of the time, but a) I would have multiple projects and would eventually want to search across them and b) some VIs will inevitably be one-off, solitary, creatures that won't lend themselves to being part of a project. So it's desirable to have some content-searching system that doesn't require opening stuff in LabVIEW first.

 

I experimented with typing a unique term into the Documentation of a VI, then searching for it using the Windows Explorer search. Even with "search file names and contents" enabled, it's unable locate the file that contains the string. Is there some way to pursuade Windows to search these things or am I going to have to do something more drastic, like write a Perl script to do it?

 

0 Kudos
Message 5 of 9
(3,002 Views)

Sounds like you need to work on making subVIs.  A given task should be a single subVI.  You can then copy that VI into another project.  Or, even better, would be to create a central reuse library that all of your projects can access.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 9
(2,994 Views)

Yes! That's exactly what I'm getting at: lots of loosely-related sub-VIs that I can reuse in future code or pillage to produce yet more sub-VIs. This is how I work now in other languages. But there, if I don't touch a function for some timeI find myself needing to grep to rememer the file name. What would be the canonical way of doing this in LabVIEW, given that the VIs don't seem to lend themselves to being searched from the Windows Explorer? How could I best produce a reuse library?

0 Kudos
Message 7 of 9
(2,984 Views)

Hello raacampbell,

 

My recommendation would be to place VIs you intend to use across projects in user.lib and add them directly to the custom palettes

 

If you do that, they'll be searchable from the IDE, you can reference the documentation with a quick mouse-over, and at worst you'll have to remember the palette/folder you placed them in.  I find this kind of structure also encourages me to place things in a logical heirarchy, create decent icons, and add documentation to my reuse functions. 

 

Regards,

Tom L.
Message 8 of 9
(2,959 Views)

I would highly recommend using VI Package Manager from JKI.  The idea is that you create packages of code.  Each package should be for a specific group of functions (for example: Arrays).  You can then install these packages on each LabVIEW version you have installed.  Even better, you can configure a package to edit your palettes.  So now your reuse code is directly in your palettes, hopefully very easy to search.

 

 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 9
(2,952 Views)