Actor framework vs DQMH

[Konan__]

Hi,

I wanted to discuss differences among AF and DQMH, and I also wanted to know the roadmap of DQMH.

I have a moderate knowledge of both framework, but never used in actual project.

As far as I have understood the situation is this:

1) AF enforces a "tree structure" of actors - subactors, while DQMH is kind of "graph" with potential deadlocks and mess.

2) DQMH comes with more tooling, like the tester. AF has no tester, I found only a "monitored actor" subactor plugin but it's not on-par with DQMH.

3) on your presentation you put AF high on a x-y chart , while DQMH can be "mastered" also by "lower-tier developers". Why? I saw that AF generate tons of files, while DQMH is much more "compact", and generally mess much less when I "rename" or move files on HD.

4) the DQMH is much more relaxed than AF. AF actually is the implementation of "the actor model" which is a developing model (see akka.net for explanation).

5) many years ago I found a nice blog that is now offline (notatamelion), where the OP presented an alternative "loop structure" where the state machine was inside the timeout case + manipulation of the timeout integer (switching it to -1 or 0). With this trick, he could use the loop to both do a state machine AND receiving external custom events.

Now I finally see the completion of this idea with DQMH, where some issue about sync and closing and "wait for reply" are already solved.

That is a big thing that made me push to use the DQMH.

6) If I have a library that interface to HW (with serial port for example), is it ok to develop a normal LVLIB in a project AND another DQMH that uses that LVLIB? In this way I have the best of both "world" that is: if I dont need a "module" I just use the "direct access HW interface" of my LVLIB (calling subvis, or class methods directly) AND I can also use it "as a module", if I wish to use it as DQMH, where I have the requests/broadcasts (that will inside call the HW interface).

7) AF messages are requests in DQMH

😎 AF abstract messages are the broadcast messages?? that is where DQMH is much simpler, without enforcing class derivation, and zero coupling.

9) I like that I can use DQMH from raw VIs. Can't be done in AF, you need to get the queue, and it's complicated to have the reply from an actor, if you are not in parent actor. 

Actor-to-Actor is discouraged and is a mess (there is a polish dev here in NI that illustrated how to do that), but sometimes it's needed and it's simpler. This is where I dont like AF, it forces complications.

10) AF seems stale, while DQMH is 4.0. Do you have a roadmap of DQMH? can NI integrate it better and deeper officially into LV? 

These are my 2 cents about AF and DQMH

greetings

PS: having G package manager, VI package manager and the new NI packages (that works with the autoupdate server, etc.) is SO WRONG. It should be listed on "how to create bad software". First of all it's 3 APIs, 3 products, 3 configuration..... nobody cares. The packages are many and it's already difficult to find useful things.... atm I already saw a potential interesting packages that "lives" on "G package manager".... I dont care, I dont want to mess with another package manager.

So I suggest to stick with 1 technology only, preferable NI official supported.

[Taggart]

You might find these interesting

[video]

[video]

[Taggart]

also this

https://automatedenver.com/simple-dqmh-dos-donts/

[ChrisFarmerWIS]

---

6) If I have a library that interface to HW (with serial port for example), is it ok to develop a normal LVLIB in a project AND another DQMH that uses that LVLIB? In this way I have the best of both "world" that is: if I dont need a "module" I just use the "direct access HW interface" of my LVLIB (calling subvis, or class methods directly) AND I can also use it "as a module", if I wish to use it as DQMH, where I have the requests/broadcasts (that will inside call the HW interface).

We do this a lot at Wired-in Software, for the exact same reason.  We have non-DQMH lvlib files (ie. usually they are libraries that have come from the IDNet). We just place them in a sub-folder of the library.

[Taggart]

as to package managers, look up GCentral.

[Konan__]

thanks ,

so what's the strength of AF compared to DQMH? 

also, I have a problem with sequences. I do Tests for End-of-line manufactoring, and almost always a state machine is a good gramework because from one state, you go to the next, up to the "exit case". The other chance to exit is via "error case". 

Both with AF and DQMH I found myself with auto-enqueueing in the MHL.

How can I implement "state machine sequences" ? 

I found myself with the need to flush queue also.... that's bad design.

Another note:

Imagine a test sequence made of 10 steps.

if I want to "abort" the test, I should be able to send a "abort message" to a loop ready to "listen and enqueue it" to a MHL....

I don't see alternatives to this:

1) send a "start test" message

2) inside MHL, the MHL auto enqueue the next step. if any error, it enqueues "error message" passing the error cluster (this is done inside "error handler" of MHL)

3) repeat this for all cases up to the end.

In this way I can sneak in an abort message anytime

[drjdpowell]

Hi Konan__,

As the creator of another framework (Messenger Library), I follow both the AF and DQMH, as well as non-LabVIEW frameworks like Akka and Erlang.  Your questions about contrasting AF and DQMH are good ones, as they are quite different, yet also similar.  I'll stay out of that, though, and allow DQMH and AF people to answer.

Re your test sequence question, though, I can offer to other methods that I have used:

1) a Test Execution Actor with a special "abort notifier".  A set of tests is sent to this actor and it does them in a loop with checks on the abort notifier between each step.  The calling actor can trigger abort at any point.

2) using the timeout case to tell when the message queue is empty and you can do the next action.  This involves feeding back a timeout of zero for every case other than timeout itself.  Then you can step through tests an can still handle messages, including abort.

[Taggart]

Dr Powell's suggestion is spot on.

[FabiolaDelaCueva]

Hi Konan,

I will address your points from the initial post later. I have to run to a meeting.

Real quick regarding

---

@Konan__ wrote:

I have a problem with sequences. I do Tests for End-of-line manufactoring, and almost always a state machine is a good gramework because from one state, you go to the next, up to the "exit case". The other chance to exit is via "error case". 

Both with AF and DQMH I found myself with auto-enqueueing in the MHL.

How can I implement "state machine sequences" ? 

I found myself with the need to flush queue also.... that's bad design.

Another note:

Imagine a test sequence made of 10 steps.

if I want to "abort" the test, I should be able to send a "abort message" to a loop ready to "listen and enqueue it" to a MHL....

I don't see alternatives to this:

1) send a "start test" message

2) inside MHL, the MHL auto enqueue the next step. if any error, it enqueues "error message" passing the error cluster (this is done inside "error handler" of MHL)

3) repeat this for all cases up to the end.

In this way I can sneak in an abort message anytime

---

Check out tip 4 from this blog post http://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/

It talks about how to create state machines inside a Message Handling Loop case. You can have your State Machine outer event structure register to your Stop Module, Abort Test, Emergency Stop, etc events.

You are correct, self enqueuing is a recipe for disaster. 

Thanks for your trust on DQMH,

Fab

[joerg.hampel]

---

@FabiolaDelaCueva wrote:

Check out tip 4 from this blog post http://delacor.com/tips-and-tricks-for-a-successful-dqmh-based-project/

It talks about how to create state machines inside a Message Handling Loop case.

---

I would prefer a helper loop to a state machine inside the MHL.