How to find Property Nodes in other VI's

[Z4CRUZN]

I am working on an application that I have inherited from others. It has huge, and in my opinion, very complicated and difficult to follow block diagrams. Here is the essence of the problem I am facing. On the main front panel there are various controls and indicators, but on the block diagram, none of them are wired to anything. So that means that (whomever it was before me) used property nodes on these controls and indicators. However, it looks like none of the references exist anywhere within the same .vi. I have used the "Find reference" selection, but that only seems to work within the current .vi that I am already in. So I guess I have two questions... 1 Is there a way to search aross multiple VI's for a reference to a conrol or indicator? 2. To set up a program in such a way seems completely "bonkers" to me, as there is now no easy way to find where any of the controls or indicators are actually being set from. Considering there are something like 100 .VI's in this project, finding something is a bit challenging. Of course, there is not documentation of any sort. I am certainly NOT a labview expert. Perhaps there really IS a reason to set things up this way, that I am just not thinking of. Can anyone think of reasons why it might be a good idea to set things up that way? I would think that whenever possible you would want to wire directly to a control or indicator. And if you cannot do that, at least have the reference in the same .vi, and pass it into something else if needed. Thanks.... Dan

[mikeporter]

1. Not Really. You are going to have to go through the subVIs manually.
2. No, they were totally incompetent

Mike...

[Dennis_Knutson]

If there are no references in the top level VI, there are no references in the subVIs.

Some beginning programmers will use property nodes or local variables because they don't understand data flow and think a 'neat' diagram is correct programming.

[Z4CRUZN]

Ok... thanks so much for the advice. At least now I know I am thinking about it correctly. Honestly, from the way that the program is structured, I am amazed that it works at all. They are also using a Queued State Machine (QSM) architecture to talk with our Real Time PXI box. The structure is a new one for me, and VERY difficult to follow. Because of the ability to name the queue's (and being able to reference them in any vi without wire connection), program flow is completely broken. It is almost impossible to try to figure out which VI's are enquing which elements to which queues, and then dequing them out again. At the very least I would think that if you are going to brake program flow, due to no wires connecting anything, then at the very least you should have some comments letting others know which VI's to go to. Otherwise it is just random searching untll you can find what you are looking for.

One more question if that is OK. In this program they used functional global variables. I would think that you could (and should) use shared variables instead. I have been reading about it, and maybe the reason they needed functional globals vs. shared variables is because of the QSM you need clusters instead of arrays or single elements?  Thanks for the education.... and forgive my ignorance....

Dan 

[Yamaeda]

FGV/AE is an ok solution, shared variables are mainly for interprocess communication. The main problem, as you notice, is the tendancy to drop and use them everywhere. This gets extra fun as new AEs wrap old ones and both are used everywhere ... an AE is an "light object" and should be handled as such.

It seems you need to refactor stuff, the QSM isn't a bad design, and if you already to most of the work in this structure, why not add a "supercluster" with all information you need that loops around with a shift register. (Maybe you can remove some AEs this way)

/Y

[mikeporter]

This more-detailed description of the application that you inherited gives me a different view of what you are dealing with. If all the subVIs are essentially separate processes that are all running in parallel, that is a legitimate way of structuring an application. I would question the wisdom of simply dumping them all on the same block diagram as there are much better ways of getting your application running.

In terms of QSMs, they can be very useful -- if you are working with a process that truly has separate states. The problem is that many people don't understand the difference between the system going into new state and having the next thing to do.

You are dead on with your comments concerning comments. Programs should be documented -- especially when you are working with things like queues or events that can pass data around your program asynchronously.

WIth FGVs I consider them as write-once (or -rarely) and read-many type structures. For example, say you are storing setup information in a database, something I will do is create what is essentially a FGV but the first time it's called it automatically goes to the DB to read the data it needs to initialize itself.

Mike...

[crossrulz]

---

@mikeporter wrote:
WIth FGVs I consider them as write-once (or -rarely) and read-many type structures. For example, say you are storing setup information in a database, something I will do is create what is essentially a FGV but the first time it's called it automatically goes to the DB to read the data it needs to initialize itself.

---

With that setup, you might as well use an actual Global Variable.  It does the same job and has less overhead.

[JÞB]

Finding the where used cases for named queues and where obtained cases for vi server references to controls can get frustrating.  The "find" feature in LabVIEW does allow text searches with several options.

Finding the String "<QueueName>" within the application instance on BD only and ignoring hidden stuff gets you to string constants that are exact matches to the queuename:

Searching for property node to a specific FP Object throughout a hierarchy can get devistating.  Especially if the developer used the call chain to obtain a ref to the top level vi panel and pulled a rerence to a control that way

(DO NOT DO THIS) but I've seen it done:

Its "Legal" but almost garunteed to cause the guy who inherits your code to denigrate your parentage and intelligence.  HOWEVER: that same text search for the control label text will find those string constants too.

Then document that code when you find out who is messing with what and how.

Chart it out over the app and e-mail that scribbling to the original developer too!  Feel free to add a thank you note.

[mikeporter]

Except I haven't figured out how to put anything inside an actual Global Variable...

Mike...