List all write and read places of cluster elements

[Matthias_H]

If you use a big cluster connected through many SubVIs I sometimes have the situation that I would like to know were element x of the cluster will be read or written.

Example:

Now I'd like to know which SubVIs write the value "Measurement Started" (like the function to find the SubVI calles from the project explorer). In this example it should list "SubVI 1".

[SteveChandler]

I am pretty sure you can do this. Click the text radio button instead of the objects radio button and look at the options.

But if not then this is another reason to use LVOOP. You would just search for your accessors.

There are a lot of things you can do with LVOOP such as dynamic dispatch, inheritance, blah, blah, blah. But at the heart of it LVOOP is nothing but a cluster and some VIs in a library. You don't need all that fancy overriding of abstract methods and stuff to get started with LVOOP. You can use it just like a cluster.

The VIs in the class library are the only things that can access the cluster. (there are exceptions related to the fancy stuff you don't need right now) If the VIs just bundle or unbundle a value they are typically called accessors. In fact they look just like your diagram. Cluster in and out are the class in and out terminals. Again, a class is a cluster with extra features. Plus you don't even have to write the boring accessor VI. You just right click and create the unbundle or bundle accessor or both. You can even do this for multiple elements in the cluster at the same time.

If you do this then you know that your write accessor is the only place where Measurement Started is bundled. You can search for all instances of that VI.

[eric.atherton]

Why not just use the "Find" function, and search for "Measurement Started"?  The results even tell you that it found it in a Budle By Name function.

[AristosQueue (NI)]

Mathias H: As much as I wish this idea were viable, I explored it years and years ago and didn't come up with any decent UI for a user to specify what cluster they were seeking, and it is one of the things that motivated me to work on LabVIEW classes. One of the biggest problems was even knowing whether all the bundle/unbundle calls were in memory -- most larger apps do at least some work with VIs that are called using Open VI Reference, and if the VI wasn't open in memory when you did your search, you missed that call.

As for eric's proposed workaround, that sometimes works, but only if you used Bundle By Name, it won't find VIs not in memory, and it will definitely find other stuff that isn't a bundle/unbundle node, like the panel controls or diagram constants.

If you have a cluster that is so widely used that it ends up being bundled/unbundled in subVIs, it's effectivley developed its own API, and replacing it with a class is probably a good idea. If you are using a typedef, it's particularly easy: Pop up on the typedef in the project tree and choose "Convert To Class". You may have to do a bit of moving VIs around to put VIs that access the cluster in as members of the class, but it's a fairly mechanical process, and when you're done, you've got a better API and you'll be able to do the searching that you wanted.

[Matthias_H]

It would be a nice new feature, but I'm using type definitions and I didn't know "convert to class" before. Thank you very much.

I'll try it but I have to do many corrections after converting my type definition to a class.

[AristosQueue (NI)]

> I'll try it but I have to do many corrections after converting my type definition to a class.

Yes, there's a certain amount of smoothing that you have to do afterward, but, as I said, it's fairly mechanical. We thought about going further and replacing accesses to the typedef with wrapper VIs, but decided that LV couldn't do anything sufficiently intelligent, so we leave the diagrams broken and let you, the programmer, figure out how you want to resovle the problems.

[Matthias_H]

Great it work's!

It's interesting: My notebook has 4 GB RAM and with the classical type definitions I was not able to build an exe file using the Application Builder beacause it needs too much RAM and LabVIEW crashes (virtual memory is set to 3 GB). After converting the type definitions to classes the Application Builder needs much less RAM and the compiling works.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.