Should I use AF for this?

[cbutcher]

---

@Shiv0921 wrote:

I'm pretty much comparing it to the continuous measurement and logging template, which is what I’ve based other programs on and would be similar to what I'd use if I didn't go with AF. But my last one got quite large and I ran into a lot of feelings of everything being tightly coupled and not very extensible which made additions unpleasant. 

---

This is almost exactly how I started using Actor Framework. A brief point that I failed to grasp when initially starting out - modular means more than just a bunch of libraries.

Maybe this is obvious to you, but it wasn't to me - if you have a collection of things (sensors, camera, controller, etc) and they all "know about" each other, then you don't have a 'modular' solution, and you haven't reduced coupling. At the time I was working on this, things like the Low-Coupled or Zero-Coupled message were a sensible solution, but now you have a much better option with Interfaces (if you can use LabVIEW 2020). See Allen's presentation 🙂

Regarding the queue configuration on RT - RT has a separate (additional, not replacement) Queue system with more deterministic properties (I guess, or at least, more favourable properties for use in a low-jitter setup). See Real-Time FIFO Frequently Asked Questions, RT FIFO Functions.

When you create one of these, you can choose options relating to polling/blocking behaviour, and then set 0/non-zero timeouts on the Read function. Depending on the combinations of those things, you can create a system that basically consumes 100% of a CPU for very little benefit (even without the obvious timeout=0, no message, fast spinning loop). The goal is to allow a low-latency read system, but if you use it for things that don't require this, and misconfigure your choices, you can be left wondering why your cRIO is running at high CPU %s all the time...

[BertMcMahan]

---

@Shiv0921 wrote:

BertMcMahan, 

I'm pretty much comparing it to the continuous measurement and logging template, which is what I’ve based other programs on and would be similar to what I'd use if I didn't go with AF. But my last one got quite large and I ran into a lot of feelings of everything being tightly coupled and not very extensible which made additions unpleasant.

---

Take a look at this video by DrJDPowell here on the boards:

https://youtu.be/pZ8w1AhDApE

That template isn't terrible, but it uses a lot of "send a message to myself" which is a bad design paradigm to use.

[Shiv0921]

Thanks cbutcher, yes I'm now realising the modularity will be quite important, so I'm very glad of the timing of this project with respect to labview interfaces having been released. Thanks for the notes on the RT FIFOs, I'll be sure to bear that in mind in places I include them 

[Shiv0921]

justACS, thank you for the link to your talk, it was very informative. I’ve found out today that a customer related to this project wants to be able to use individual chunks of the program as black boxes, so I’m thinking now that interfaces will be essential to making this work, so thank you for for that link! I see you have another talk on interfaces with AristosQueue so I'll give that a look too.

You mentioned about test driven development, do you have any good resources for approaching this? At the moment my thinking is, ‘test that everything works in chunks’, but I’m not sure if there’s a particular strategy to follow. I have a labview book which has a chapter on it that I’ll go through, but thought I’d ask in case you knew of any good content. I’d like to get plans in place up front to try to avoid any nasty surprises down the line.