LVOOP - Classes and Queues

[James_W]

I have a nice big project, it is old (6years+) and contains many different daemon VIs which talk to each other.
It could be defined as a giant state machine - but performance requirements dictate that this is not that case.
It has evolved over the years with many different developers and so the coding style is not common or easy to understand.

I'm trying to bring a sense of control to it.

Haven't done much OOP, but there are a few classes in here and I've created a few more.
There is a giant dataset cluster which is passed everywhere but not updated correctly - so needs to go.
I have 50+different modules with their own unique queues which are spawned on program load.

Currently, all communication is done via named queues with action engines holding the references to the queue names.
This does not allow me to know which modules are loaded, which are running, and what their states are from the main controller module - as each module opens and releases it's own queue.

I'm trying to move to a global control to pass into all modules - 1 type def cluster. (unless there is a better option)
Wondering if I am better having queues in a class or a cluster when I pass them around.

I can't seem to find any info / examples of how to deal with queues and classes (but maybe I'm not meant to as they are 2 different design patterns?)

Help please?

OOP / Advanced architechures doesn't really cover this and NI Tech support are still remote and therefore slow to respond.

Thanks

James

[crossrulz]

You might want to have a look at the Actor Framework.  There are examples in LabVIEW for how to use it.

[James_W]

Nope - i definitely do NOT want to look at the actor framework😂
it's a horrible beast and I don't want to make the complicated code even mode complicated.

I've yet to find more than 1 person (outside NI) saying anything good about actor framework (and maybe only 2 inside NI!).

Lets trying and keep things simpler please. Not everyone is of Knight quality and wants to slay Dragons Mr Crossrulz 😜

[crossrulz]

---

@James_W wrote:

I've yet to find more than 1 person (outside NI) saying anything good about actor framework (and maybe only 2 inside NI!).

Lets trying and keep things simpler please. Not everyone is of Knight quality and wants to slay Dragons Mr Crossrulz 😜

---

Oh, I'm not a fan of the Actor Framework either.  But there are a lot of good concepts in there you can borrow from.

[Mark_Yedinak]

---

@James_W wrote:

I have a nice big project, it is old (6years+) and contains many different daemon VIs which talk to each other.
It could be defined as a giant state machine - but performance requirements dictate that this is not that case.
It has evolved over the years with many different developers and so the coding style is not common or easy to understand.

I'm trying to bring a sense of control to it.

Haven't done much OOP, but there are a few classes in here and I've created a few more.
There is a giant dataset cluster which is passed everywhere but not updated correctly - so needs to go.
I have 50+different modules with their own unique queues which are spawned on program load.

Currently, all communication is done via named queues with action engines holding the references to the queue names.
This does not allow me to know which modules are loaded, which are running, and what their states are from the main controller module - as each module opens and releases it's own queue.

I'm trying to move to a global control to pass into all modules - 1 type def cluster. (unless there is a better option)
Wondering if I am better having queues in a class or a cluster when I pass them around.

I can't seem to find any info / examples of how to deal with queues and classes (but maybe I'm not meant to as they are 2 different design patterns?)

Help please?

OOP / Advanced architechures doesn't really cover this and NI Tech support are still remote and therefore slow to respond.

Thanks

James

---

The above statement scares me. If this is the route you are going I would be concerned that your system is not designed very well and will have too much coupling and dependencies between your modules. There is a discussion regarding the DQMH that is worth looking at. It discusses actor (not actor frame) architectures. Your modules should effectively be stand along entities that use messages to communicate state to the external modules and message/events to trigger actions within the module/actor. some type of publish/subscribe messaging architecture works well for this. But I get nervous when the solution to a problem is to pass global state information to all parts of your system. Each module/object should only contain the bare minimum of what it needs and the data/messages passed in should only be the bare minimum. Global uber-clusters are something to be avoid at all costs.