Questions about AF

[Ironman_]

Hi,

I am new to AF. I got that there is a Root Actor, I launch it, then it can spawn for example 2 nested actors.

1. FIRST QUESTION: COMMUNICATION

The communication happens in hierarchy way through the "tree" : Root <-> Nested-Actor1, and Root <-> Nested-Actor2 (2-way communication via actor's queue, where I send Message objects).
I read that it is possibile to create a "graph" communication, that is for example Nested-Actor1 <-> Nested-Actor2, but must be managed manually.

I am afraid to do this, expectially as regard the lifespan of objects (I am not confident of my knowledge), because I am sure that glitches will happen when I send Stop, some VI will go out of memory and some messages will hang/not processed, etc...

So first I want to know why NI chose the hierarchy way, and if there are use case for the "graph" way. Or if any software can be made "hierarchical", so can I always reduce my architectute to a communication that goes only via parents-child way.

2. SECOND QUESTION: DEBUG

Then I would like to know how to debug AF projects, because I can't debug VI clones, I can't follow data and events are more complex than simple QMH. I have LV2015SP1.

Thanks

[justACS]

Ironman_ wrote:

I am afraid to do this, expectially as regard the lifespan of objects (I am not confident of my knowledge), because I am sure that glitches will happen when I send Stop, some VI will go out of memory and some messages will hang/not processed, etc...

So first I want to know why NI chose the hierarchy way, and if there are use case for the "graph" way. Or if any software can be made "hierarchical", so can I always reduce my architectute to a communication that goes only via parents-child way.

There are many reasons.  Here are a few.

It's easier to understand how data moves through the tree hierarchy, as opposed to the more typical open topology.  This is especially true when you get past two or three actors.

The tree makes it easier to avoid some of the messaging bugs we see in open topologies.  One such example is an echo effect, where all actors respond to a certain message by forwarding the message to another actor.  In an open topology, it is harder to avoid eventually routuing that message back to the originator, and thus kicking off the message chain again.

A tree hierarchy makes it much easer to define (and hopefully reuse) subsystems.  Any branch of the tree can be considered a subsystem, with the "root" of that branch defining the interface.  If any actor can talk to any other actor, you can't really claim to have subsystems.

There are use cases for peer-to-peer communication between actors.  One example would be an actor that manages communication with a box instrument.  If several actors need data from that box instrument, it may make sense to allow those actors to register for updates with the instrument actor.  Another common one is an actor that manages a TCP/IP connection with actors on another computing platform  That connection is peer-to-peer, although the peers are separated by a network connection.

You can do peer-to-peer, and it sometimes makes sense, but we make you do a little extra work to do it.  That seems to be enough of a barrier to make you think about whether it's really necessary.

2. SECOND QUESTION: DEBUG

Then I would like to know how to debug AF projects, because I can't debug VI clones, I can't follow data and events are more complex than simple QMH. I have LV2015SP1.

Thanks

Debugging is a pain point, for sure.  I have some recommendations.

First, are you aware of the DETT support included in Actor Framework?  You can set a conditional disable flag for your project, and get trace data for messages moving around your system.  Get the details here: 

I can't overemphasize how useful this is.  With DETT tracing enabled, you can watch every message rout through your system.

Second, test your actors indepently.  Write a little test harness for each actor that launches the actor, lets you send it messages, and catches any messages it sends to its callers.  It's a lot easier to look at an individual actor in isolation, especially when you need to see what's happening in a reentrant VI.  (You can put a breakpoint in a reentrant VI, and the clone will open when you hit the breakpoint.)

If all your actors pass unit testing, most of the bugs you get when you put it all together we be the result of sending a message to the wrong actor.  DETT will help you with that.  BTW, getting Error 1556 from an instance of Enqueuer.vi means the enqueuer is bad - the recipient shut down or never launched.  Error 1448 from a Do.vi is a bad cast, meaning you sent the wrong message to an actor.

Sticking to a tree hierarchy helps with keeping your unit testing simple and understandable.

One more tip:  provide some useful overrides for your actors' Handle Error VI.  At a minimum, display the error in a dialog box (you can strip this feature out later).  The default response for actors to an error is to shut down without notice - and when an actor stops, it passes the error to its caller.  Your whole heirarchy will disappear and you won't know why.  (And if you turn off the autostop feature, you'll get a few orphan actors while you're at it.)

These and other questions are answered in the official AF course:  Actor-Oriented Design in LabVIEW  I don't know where you are physically, but talk to your local field sales engineer about setting one up in your area.

[Ironman_]

thanks for the detailed reply.

That is exactly my case.

I use labview to develop functional tests. I guess the majority of labview's users do that... So we have at least one communication going on (in my case I have to use 1 serial port and 1 USB port connected to a cDAQ-9178).

Until today I used producer-consumer and no OOP.

But now I must face new problems (many models, variations, more "threads, etc...), so I have to "improve", and introducing OOP, and other framework. I think AF should fit to my case. There are other interesting frameworks like QBus, but they cover only one aspect (queues communications).

So I think it is pretty common to have an actor that will have "shared funcitonality", for example the access/management to the HW to get data.

If you ask customers to think by "modules", one of the first module to think of is "the module that manages HW I/O".

It's a pity you didn't include this in the framework.

[justACS]

Ironman_ wrote:

So I think it is pretty common to have an actor that will have "shared funcitonality", for example the access/management to the HW to get data.

If you ask customers to think by "modules", one of the first module to think of is "the module that manages HW I/O".

It's a pity you didn't include this in the framework.

There are far too many variables in available hardware and how it is used for such a general purpose module to exist.  And having such centralized I/O handling is not the best solution in a lot of cases, anyway.

Most of our customers are very hardware-centric, with good reason.  But I think it leads to people paying too little attention to their overall software architecture.  I believe you are better off ignoring the hardware for a bit and taking some time to decide what tasks your software needs to perform, and designing software that does those tasks well.  Then map the hardware to those tasks.  You may still end up with a single I/O module, but you'll get a better design than if you start there.