Architecture question

[jfalesi]

Hi all. I'm refactoring an ad-hoc design and wondering what kind of architecture I should use. Our application is a variation on continuous measurement and logging, with a state-based feedback control loop. I've attached a draft diagram of our modules and messages. In short, we collect data from gyroscopes that someone wears on their ankles, use the data to determine what phase of walking gait they're in, and send commands to a stimulator (to stimulate particular muscles) based on the detected phase. We refer to transitions between walking phases as "events", hence the "Event Detection" module.

Regardless of gait phase or detected events, whether or not stimulation is actually delivered is controlled by a timer, which is implemented as a polling loop (see here). We also want a manual option, so we can start/stop event detection and stimulation delivery manually when the timer isn't running.

I'm thinking a queued state machine based on the continuous measurement and logging example is appropriate. My main question is how to implement stimulation and event detection control. I've already added queues to control logging but so far stim and event detection control uses only local variables/propery nodes. I'm wondering if it's worth creating a whole message passing architecture (similar to the Delacor QMH, which we don't have) and state machines just to implement start/stop, or if we should just use notifiers or something else. I'm reluctant to go full state-driven QMH due to the added complexity.

Any advice is appreciated.

Thanks,

-Jamie

[Bob_Schor]

---

@jfalesi wrote:

(similar to the Delacor QMH, which we don't have)

---

What you didn't say is what version of LabVIEW you will be using.  The Good News is you (probably) can easily remedy the lack of the Delacor QMH by opening VIPM and installing it in your LabVIEW system -- just scroll down until you get to the D's in the alphabetic listing. 

Bob Schor

[jfalesi]

2018. Thanks, installing Delacor packages now. Still wondering if QMHs are the best solution.

[wiebe@CARYA]

---

@jfalesi wrote:

2018. Thanks, installing Delacor packages now. Still wondering if QMHs are the best solution.

---

1) The 'best' is ambiguous. Best for what? Development time? Processing speed? Durability? Documentation? Support? Etc.

2) The 'best' is dangerous. Go for 'good' ('good enough' has a negative vibe, but often it's not). Perfection can cost a lot.

3) This is a debate that can go on for ever. And it probably will... It depends more on your (team's) experience, then on technical capabilities of framework X, Y or Z.

Turn the discussion around. Will DQMH work for us? It probably will. Same for AF. Same for, as I like to do, a OO Analysis, make an OO Design, and then make the program. You don't need to use a framework.

Either go for something that feels good, or make a pro\con's breakdown of everything you feel good about and pick one.

[Yamaeda]

---

wiebe@CARYA wrote:

2) The 'best' is dangerous. Go for 'good' ('good enough' has a negative vibe, but often it's not). Perfection can cost a lot.

---

"Never perfect. Perfection goal that changes. Never stops moving. Can chase, cannot catch." - Abathur

[wiebe@CARYA]

---

@Yamaeda wrote:

---

wiebe@CARYA wrote:

2) The 'best' is dangerous. Go for 'good' ('good enough' has a negative vibe, but often it's not). Perfection can cost a lot.

---

"Never perfect. Perfection goal that changes. Never stops moving. Can chase, cannot catch." - Abathur

---

Good one!

"Don't be afraid of perfection. You'll never attain it. - Salvador Dalí

Although that kind of defies my intention (to not try to attain perfection).

[jfalesi]

Thanks for the input. I would say our top requirements are simplicity and short development time. I want to leverage as much of the existing architecture as possible. Speed is important for the critical path (the modules with red borders) - we have to detect events and send stimulation within maybe 10 ms. We're running non-real-time at the moment, so we may not always meet the timing requirement, but we plan to eventually port to a real-time OS. 

As far as experience, the "team" consists of me... I have experience with queues, OO and AF. DQMH will definitely work - I was mainly wondering if it's worth creating messages and states when the only real issue I'm having with the current architecture is race conditions b/c we're using local vars and property nodes to handle shutdown.

[Yamaeda]

---

wiebe@CARYA wrote:

Good one!

---

Yeah, who expected to get some life wisdom from StarCraft 2. 😉

/Y

[wiebe@CARYA]

---

@Yamaeda wrote:

---

wiebe@CARYA wrote:

Good one!

---

Yeah, who expected to get some life wisdom from StarCraft 2. 😉

/Y

---

https://www.youtube.com/watch?v=ucZ-NehMggM&feature=youtu.be&t=21

[Yamaeda]

That's the one! Great game. 🙂

/Y