Is QMH obsolete? Am I wasteing my time?

[styrum]

There is no your text in your reply, only a quote of my entire previous comment

[billko]

---

@styrum wrote:

There is no your text in your reply, only a quote of my entire previous comment

---

Sorry, it was inside the quote itself.

[rolfk]

---

@styrum wrote:

The framework looks abandoned by NI: no dedicated web page, only the forum is left.

---

It isn't really abandoned but simply put into the Open Source as a community tool. And in general that means a few will use it, but most won't and nobody will give feedback or even actively participate. That said, the NI System Engineering Group who created this, either got disabandoned or is now likely busy doing NI's own turn key solution business inside NI.

And yes its design is very much dictated by the fact that it was meant to run on the real-time targets. That excluded very involved class hierarchies for a very long time, since the targets both had not enough resources for that nor was the LabVIEW runtime quite able to handle complex class hierarchies that had even the slightest form of circular dependencies in it. While under Windows you can run such a program, albeit with horrendous load and start times, the real-time executable simply died whenever it encountered such an executable.

Also DCAF (or more exactly its predecessor CVT) predates most things like QMH and Active Framework quite a bit and in fact also LabVIEW classes.

[Taggart]

---

@styrum wrote:

I did look at DCAF recently, maybe not very thoroughly though. 

The very first shock: no primary project provider for its own configuration files in such elaborate framework - you can't just double-click on such a file to open it in the editor, you must open the editor first and then open a particular config from within it!

"Modules" are still "dead"/"passive" and animated by external "engines" instead of making each module an actor/"engine".

Using the "tag bus" for communications between modules instead of buffered (queued) asynchronous messaging may lead to the same dreaded mutable state sharing.

The configuration files don't abstract or store the behavior information for the modules themselves (no mapping of possible events and states combinations to (re)actions and next states in any form). It is still completely left to the programmer how to do the "processing" part between reading the inputs and writing to the outputs within each module.

Justifying it by RT needs they resort to continuous (timed) polling everywhere and suggest to implement any event-driven processing desired (like blocking reads from event queues) somewhere "in parallel" to the framework.

The framework looks abandoned by NI: no dedicated web page, only the forum is left.

---

I think he simply meant, try drinking less caffiene.

[billko]

---

@Taggart wrote:

---

@styrum wrote:

I did look at DCAF recently, maybe not very thoroughly though. 

The very first shock: no primary project provider for its own configuration files in such elaborate framework - you can't just double-click on such a file to open it in the editor, you must open the editor first and then open a particular config from within it!

"Modules" are still "dead"/"passive" and animated by external "engines" instead of making each module an actor/"engine".

Using the "tag bus" for communications between modules instead of buffered (queued) asynchronous messaging may lead to the same dreaded mutable state sharing.

The configuration files don't abstract or store the behavior information for the modules themselves (no mapping of possible events and states combinations to (re)actions and next states in any form). It is still completely left to the programmer how to do the "processing" part between reading the inputs and writing to the outputs within each module.

Justifying it by RT needs they resort to continuous (timed) polling everywhere and suggest to implement any event-driven processing desired (like blocking reads from event queues) somewhere "in parallel" to the framework.

The framework looks abandoned by NI: no dedicated web page, only the forum is left.

---

I think he simply meant, try drinking less caffiene.

---

He gave as good as he got.  I appreciate that.  😄

[styrum]

I got the joke. Yes, maybe I am too worked up about these things, so I should drink something to calm me down.

But I am not joking about DCAF framework. It could have been a pure (pun intended) coincidence but I really did look into it literally just several days ago.

All the materials about it I saw are dated 2016. I understand it could have been in development for quite while before that, but how can it possibly predate LVOOP if it uses those classes (and not GOOP classes, for example)? AF is what, 2012? The only thing DCAF can predate is DQMH (not QMH).

[ConnerP]

---

@drjdpowell wrote:

---

@joerg.hampel wrote:

---

But I will say this: Another great thing about DQMH is that you can actually implement these things if you'd like! 

---

An experiment, modifying the "Settings Editor" you showed.  Tested with your Tester, and works.

---

 James, would you mind back-saving this to 2017 or earlier?

[drjdpowell]

Backsave to 2017

[drjdpowell]

---

@drjdpowell wrote:

Notes on my experiment:

• This require Messenger Library, but only for the "Action Stack" I am using for the subactions (handled at right).  One could easily copy these, as they are a very small pair of subVIs, breaking any Messenger Library dependance.  

---

Note from a few months later: I've moved the "Action Stack" subVIs out of Messenger Library and into the small package "JDP Science Common Utilities" (version 1.3.0.14, available on VIPM), so that people have the option to use them without needing to install the (much larger) Messenger Library package.