Structuring a large application with classes, FGV's etc.

[Ben]

---

@MaxJoseph wrote:

.... Submodules communicate via events. In this case, every module will receive every message sent by every module, but each submodule gets to decide whether it responds. ...

Please ask me any questions!

---

I cringed when reading that since I have had to step into applications that used what I termed "a bus architecture". It only takes a half dozen of those sub-modules to get to a point where it becomes cumbersome to figure out which module responds to which messages.

What can help is if there is clear documentation indicating who sends what when and who responds to what... then that approach can be expedient to use that approach ... but at that point you may has well replace the bus with direct connection via events queues etc.

Just my 2 cents,

Ben

[Mark_Yedinak]

---

@Ben wrote:

---

@MaxJoseph wrote:

.... Submodules communicate via events. In this case, every module will receive every message sent by every module, but each submodule gets to decide whether it responds. ...

Please ask me any questions!

---

I cringed when reading that since I have had to step into applications that used what I termed "a bus architecture". It only takes a half dozen of those sub-modules to get to a point where it becomes cumbersome to figure out which module responds to which messages.

What can help is if there is clear documentation indicating who sends what when and who responds to what... then that approach can be expedient to use that approach ... but at that point you may has well replace the bus with direct connection via events queues etc.

Just my 2 cents,

Ben

---

I too don't like that. It is just a hair better than passing every component the uber cluster. We use a publish/subscribe model for our system messaging. Components only register for messages that they require. Our messaging system is TCP based so it works across applications and machines. This also allows us to broadcast messages to multiple receivers. In a single application user events can accomplish the same thing. Each module should only register for messages it needs.

[irPaul]

Thanks for all the input - blog posts, schematics, VI's! It is truly helpful. I will need some time to let it sink in and (re)design my architecture.

[MaxJoseph]

Hi Mark and Ben,

I agree there are big drawbacks with the Core QMH model, I use it to make simple applications and for training new programmers. It is a lot simpler than a publish/subscribe model, in my opinion.

I like to include module name in the message to know where messages are coming from.

For larger applications I use Actor Framework, which scripts the messaging and manages the queues internally. I find Core is a good stepping stone to Actors when training people; the Actor Core is just the MHL.

[irPaul]

Right, I've been reading up on the articles suggested and I think I've got some ideas now. Bear with me please..

First off, I've made an overview of my system and hardware, see attached. Not too complicated I'd say.

As for the structure, the Continuous Measurement & Logging examples look pretty much exactly like what I am trying to achieve. Essentially 5 parallel loops with queues and message handlers. I especially like the idea of the message handling. My initial setup was already a bit into this direction with the parallel loops, but still a long way from it.

As I see it I need a few modifications to this architecture:

1) Data acquisition is both a camera frame and analog input;

2) There is a sixth parallel loop for Data Processing, between Acquisition and Logging;

3) Several loops require access to the hardware (not shared though).

Furthermore I need to convert some of my code in Libraries. For example the image analysis that I do would be great as a library, and the same for the Logging (it's now collected in a folder as a "library").

See attached my proposed modified architecture. First question of course, do you agree with this architecture?

My main concern is with the hardware connections. I always open all hardware connections and push the settings ("initialization"), as is good practice I read.

The Acquisition-loop needs to access the Analog In and the Camera. The Processing-loop needs to set the Digital and Analog Output.

>> Should I initialize these all in the Data Acquisition-loop and send the Tasks over the queue, or better initialize them in the Processing-loop?

Secondly, the digital input should act as an interrupt, so to say. It should trigger a state change for the State Machine (upon the first iteration again, of course).

>> Where should I poll this interrupt? The Acquisition-loop runs at 10 Hz, so too risky to miss a trigger of 30-50 ms there. The Event Generator is logical, but where/how open I initialise the hardware channel then, and how do I poll it from there? Using a seventh parallel loops seems superfluous.

Thanks in advance for any input on this!

[irPaul]

So I've given this a bit more thought and I think I've come up with a strategy for it.

The Acquisition-loop needs to access the Analog In and the Camera. The Processing-loop needs to set the Digital and Analog Output.

>> Should I initialize these all in the Data Acquisition-loop and send the Tasks over the queue, or better initialize them in the Processing-loop?

Solution: initialize all hardware "in-place", where it's used: Analog In and Camera in Acquisition, Digital and Analog Out in the Processing-loop. Both loops are connected to the Event Handler with a message queue, and can send any errors back to the Event Handler.

>> Where should I poll this interrupt? The Acquisition-loop runs at 10 Hz, so too risky to miss a trigger of 30-50 ms there. The Event Generator is logical, but where/how open I initialise the hardware channel then, and how do I poll it from there? Using a seventh parallel loops seems superfluous.

The USB-6008 unfortunately does not support hardware interrupts or Signal Events. It does, however, have a counter! I tested and the counter registers triggers independent of the software polling. I can check for a counter increment in the Acqusition-loop, and send this with the other data as a boolean flag for the Processing-loop to act on. Since the triggers are in a handshake set-up, I do not have to worry about missing double triggers.

Any comments or remarks on my architecture? Happy to hear some feedback!