LabVIEW
Analysing a rats-nest
Solved!
@skol45uk wrote:1) I'd like to find out where all instances of a built-in VI are actually being made e.g. UDP Read - Its not in dependencies and not in the project, so how can I perform a Right-Click > Find > Callers?
Those are functions.
Select one, CTRL+F. This will find the instances of the function in the VIs that are in memory.
@skol45uk wrote:3) Are their any tools which would reverse engineer a UML diagram? Though I'm not sure how event/notifier passing of info actually is represented in UML?! But something that could even just reveal class instance relationships would be useful.
I think OpenGDS, but it's not AF specific.
There are probably a few initiatives, but I don't use AF so I can't really advice.
@skol45uk wrote:4) Are their any tools/features to LabVIEW that can provide complexity figures?
Do you mean metrics?
VIs have a metric properties. The Metrics.Advanced property is only available with hidden scripting options on, but it provides a lot:
Search LabVIEW like a graph! 
One thing to keep in mind with Actor Framework is that it's intended to be used as the ONLY communication method between actors. Inside an actor, you can communicate however you want.
If the programmer of this decided to circumvent the actor tree, it's going to be MUCH harder to debug. If they followed the "only use AF enqueuers to talk to other actors" then you can likely ignore most of your user events and notifiers.
User events and notifiers should, in a properly done AF system, only be used between helper loops inside a single actor. For example, you might have user events signaling between a helper loop in Actor Core and certain methods. A method may use a User Event to send a signal back to the UI loop in Actor Core to do some work.
Being able to ignore those would let you "black box" an Actor and just assume it works unless something gets sent to its Enqueuer. When you have multiple communication paths to an Actor it gets really hairy and you get to deal with a bunch of race conditions. Hopefully the notifiers and user events are just used internally with the Actors that use them (since that's a very common use case) and not between actors (which is a bad practice 99.9% of the time).
The general idea is that Actors communicate via the actor tree. In other words, only to their caller and to the ones they specifically call.
The Caller enqueuer is obtained with "Read caller enqueuer", then you can send messages up the chain. Nested actors do require you to store the Enqueuers when you launch them, then send them messages later on.
Figuring out if the Notifiers are going up or down is more architectural than "ctrl-F"-able. Find where the Notifier is created, and see if there are any methods that send that Notification reference to someone else. Maybe it's created and added to the object before being launched, letting the previous programmer leak that notifier reference. Otherwise, it'd have to be sent along a regular Actor message. Or, maybe the calling parent creates a Notifier reference and sends it to a callee actor. Basically you just have to trace where the Notifier references (and UE's) get routed.
Typically if you have Parent actor that launches Child A which launches Child B, and you want Child B to give info to the Parent, then B should send a message to A which sends a message to Parent. This does result in "message forwarding" code that just receives a message and resends it, but it's the proper way to do things.
(As an aside- a better way to look at it is that each "forwarding" step should recontextualize the data. For instance, B might be an analog input actor that just sends voltage data to A. A might scale that data and send "pressure" data to Parent. Yes, it's just forwarding the same underlying info, but each Actor has a different responsibility and "understands" the data differently. The exception to this is logging actors, which generally just need "forward the data straight through" methods.)
Are you operating within a Project? Ctrl F, then select Objects, and select "Generate User Event" with Search Scope to All VI's in Instance should find everything.
And clicking View- VI Hierarchy should get you a list of subVI's. If you're using a lot of PPL's or something then I could see it being a pain, but I'm not sure why you're having such trouble with your Find tools. Maybe something isn't loaded into memory that should be (because it only searches in memory).
