Any diagrams for Evaporative Cooler project?

[DMurrayIRL]

Somewhat related to this thread, are there any diagrams for the Evaporative Cooler project that ships with LV2014? Thanks...

[AristosQueue (NI)]

The boxes show inheritance -- each level of inheritance is a separate running Actor Core.vi. The red lines show caller-nested actor relationships.

[DMurrayIRL]

Thank you. At some point is there a chance of getting other diagrams for this project, like sequence diagrams, or something else that shows the messaging relationships? I don't mean right away, but they would certainly be a 'nice-to-have'.

Also, a question: technically I would say that there are five distinct actors here (as in five separate entities that have some work to do in this system), but you say that each level of inheritance is a separate running Actor Core.vi. So for the Simulated Evaporative Cooler actor (for example), you actually use six Actor Core.vi's? Is that what you're saying? So there are six asynchronous loops running just for one actor?

[AristosQueue (NI)]

DMurrayIRL wrote:

Thank you. At some point is there a chance of getting other diagrams for this project, like sequence diagrams, or something else that shows the messaging relationships? I don't mean right away, but they would certainly be a 'nice-to-have'.

Assuming all goes as planned, you should be able to use LV 2015 to generate such diagrams yourself come August. We have been working on improving the diagnostics for AF. The raw data will appear in the Desktop Execution Trace Toolkit. It should then be possible to log that data and extract it to generate better charts. If my memory serves, there's a charting tool that someone wrote already on these forums, just needs better data to be useful.

DMurrayIRL wrote:

Also, a question: technically I would say that there are five distinct actors here (as in five separate entities that have some work to do in this system), but you say that each level of inheritance is a separate running Actor Core.vi. So for the Simulated Evaporative Cooler actor (for example), you actually use six Actor Core.vi's? Is that what you're saying? So there are six asynchronous loops running just for one actor?

Potentially 6, but practically not. Each class that overrides Actor Core is capable of adding another asynch loop but probably only a few actually do. For example:

• Cooler.lvclass does not override Actor Core.vi at all.
• Evaporative Cooler.lvclass does override but does not add an additionl asynch loop.

The ones that add an asynch loop are:

• Actor
• Timed Loop Actor
• Simulated Water Level
• Simulated Evaporative Cooler
• Live User Controller
• Programmatic Controller
• Air Cooler Application

So for Simulated Water Level, there are three asynch loops running -- the simulation while loop in Simulated Water Level, the status update in Timed Loop Actor, and the message handling loop in Actor.

There is something about the Actor Framework that makes these massive parallel systems easier to write than most other frameworks attempted in LabVIEW... opinions vary about what exactly we did that is different. In my opinion, this ability to spin up parallel while loops each with its own task but still bottleneck the communications with those loops through interactions with "the actor" is key. All those parallel loops are hidden to the rest of the application and look to the caller actor as if it is a single actor doing one job.

[AristosQueue (NI)]

I updated the image from last night to include notation about which classes are adding asynch loops.

[DMurrayIRL]

One last question- I also meant to ask about the "Start Asynchronous Call" primitive VI, as well as the asynchronous loops that the user adds. The "Start Asynchronous Call" VIs are just called during the launch process for each actor, right? So this means that even with all the levels of inheritance, each distinct actor just has one process thread (or something along those lines)? So, something like the process that is spawned in Erlang, or the threads that Scala/Akka actors use?

[AristosQueue (NI)]

DMurrayIRL wrote:

The "Start Asynchronous Call" VIs are just called during the launch process for each actor, right?

Yes. Unless you call Start ACBR for some other reason in your own code.

DMurrayIRL wrote:

So, something like the process that is spawned in Erlang, or the threads that Scala/Akka actors use?

Nothing like any of that. 🙂

LabVIEW has a pool of threads.

Every VI is broken into a bunch of "clumps".

Every clump has a "fire count", that is, how many clumps upstream of it have to complete before this one can run.

You hit the run button.

All the clumps with a fire count of zero go into the execution queue.

Each thread comes by and grabs an element from the queue and executes it.

When the execution is done, the thread decrements the fire count of all the connected downstream clumps.

Any clump that hits zero goes into the queue.

The thread goes around to get the next clump.

If the execution hits a subVI node, the subVI's zero-count clumps get added to the execution queue.

The Asynch Call By Ref node just adds a VI's zero-count clumps to the execution queue.

[DMurrayIRL]

Okay - I think I asked for too much too soon. 🙂 The last paragraph is beyond me for now. But thanks for your replies, they are most helpful.

[AristosQueue (NI)]

Your welcome.

[komorbela]

Hi AQ,

This image is a nice representation for showing the caller - calle hierarchy. It combines the class hierarchy with the "nested hierarchy" in a compact way.

Do you have anything in mind that could be added to the same image to show the defined messages? Also the planned routes for messages?

That would make this illustration even more descriptive.