Help choosing design pattern for multiple loops

[CMSys]

All, 

I am preparing to write a program for controlling an engine test using a dynamometer and here are my requirements and what I've come up with so far: 

Loops: Safety, Test Schedule, Dynamometer, Engine Control, GUI, MCC (Fans and blowers), Data Acquisition 

Loop purposes:

Safety (Highest priority) - Continuously monitor safety I/O for unsafe conditions and send events to perform several different types of shutdowns to other loops

Test Schedule (Low priority) - Runs the test sequences for the engine to pass the FAT

Dynamometer (High priority) - Communicates with the ABB dynamometer and sends it commands

Engine Control (High priority) - Controls engine throttle, fuel delivery, etc...

GUI (High priority) - User event that monitors front panel interactions and operator input

Data Acquisition (High priority) - Continuously reads data from all inputs and communicates via global variables

MCC (Low priority) - PID loops for several blowers and fans that cool the engine and provide air for engine

I also have classes for several of these loops since I am more familiar with OOP 

My plan is to use a producer consumer user event/queued state machine architecture. I am leaning in this direction because I need to prioritize safety events that occur in order to send commands to my Engine Control, Dynamometer, MCC loops to have them execute safety routines. I will also have the GUI and Test Schedule loops sending commands to the other loops having them execute routines. 

There are several dynamics going on in this program and my documentation is growing day by day. Does anybody have any input on this? I will attach the main VI for what I am working on so far.

Thanks in advance

[NIquist]

If you are familiar with OOP, I suggest you look into the Actor Framework.  I tend to keep my code to very simple procedural state machines, but I have seen consultants we hired years back do some amazing things with AF.  It's a lot to wrap your head around, but I think there are some advances these days that make it easier to use.

LabVIEW Actor Framework Basics - NI Community

There is also a neat example in my LabVIEW 2019 from MGI (Moore Good Ideas).  I think they make some of the AF toolkits you can get through the VIPM.  Delacor also offers  many helper packages.

Check it out and see if it suits your needs.

[CMSys]

Thank you for the well thought out reply. But I, like yourself, try to keep things relatively simple. Is there any direction you would push me in that I am already sort of going? 

[crossrulz · Accepted solution]

---

@NIquist wrote:

Delacor also offers  many helper packages.

---

Anything from Delacor would be for the DQMH (Delacor Queued Message Handler) framework, which mostly handles the same cases as Actor Framework.  I often hear dogmatic arguments between the two.

Back to the OP, it really sounds like you should be using something such as Actor Framework or DQMH.  Those are the two major frameworks designed for meeting the requirements you are stating.

[NIquist]

You could certainly do the same thing with a state machine and a couple of extra external while loops for the status and watchdog functions.  I usually build my state machine inside the timeout case of an event structure.  That way I can handle the quick GUI events without a lot of overhead.  

Whether you take the plunge into an established pattern like AF or DQMH, or roll your own, you will still be dealing with the details of how to implement all YOUR needed functionality.  If you have good OOP skills, creating all your classes and methods will get you started, but you will need to handle all the messaging, possible expansions to the program, unit testing, etc.  The big patterns have hooks for that already, but you have to deal with their learning curve.

Do you have the funds/authority to hire a consultant?  If this is mission critical code that may pose a health hazard, it's very justified to seek some experienced help.

[NIquist]

I remembered where I got (OK, stole) the idea for putting my state machine loop inside the event timeout case.  Check out these excellent blogs from Mike Porter:  Building a Proper LabVIEW State Machine Design Pattern – Pt 1 | Not a Tame Lion

I highly suggest you take a look at his other pages too.  He covers most of what you will need to create a complex application in LabVIEW that is logical and robust.  He has an excellent writing style that incrementally takes you through his whole thought process and really gives you an idea of WHY you are doing something, rather than just HOW to do it.

[JKSoerensen]

---

@CMSys wrote:

Loops: Safety, Test Schedule, Dynamometer, Engine Control, GUI, MCC (Fans and blowers), Data Acquisition 

Loop purposes:

Safety (Highest priority) - Continuously monitor safety I/O for unsafe conditions and send events to perform several different types of shutdowns to other loops

It would be better to separate your safety system, from the rest of your code. Preferably having a system completely separate both electrically and functionally. Then you get a redundant system and the requirements for your control system can be reduced quite a bit, as long as the safety system is not triggered. 
This would of course be something that your Risk assessment of the project covered. 

[CMSys]

I will likely be running the safety system off of a Beckhoff safety PLC

[CMSys]

DQMH is the winner, thanks!