Picking Correct Method for Multiyear Application Development

[Chase_H]

Hello All,

I may be frequently active on the forum starting soon. Im totally new to labview and AF other than Core 1&2 (core 3 and OOD scheduled). At this time, Id just like to have a very high level discussion to ensure that AF is the correct architecture for our use. And yes, Im very aware that Im upjumping myself into a category that is beyond my training. oh well... there is a need 😕

The High Level: Im historically a Test Engineer working in reactor and other nuclear/electromagnetics fields. The group Im currently in has been supported by a single senior engineer developing labview software for the past 25 years. However, we are unfortunately loosing him later this year to retirement. Myself and one other engineer are attempting to bring ourselves up to speed to develop a whole new suite for the group over the next few years. I believe AF is probably the right choice of Architecture, but it is certainly not what the previous application was built on as that was being developed as far back as the late 90's.

The day to day need: I need to have 5 or 6 exe's (we believe splitting into separate exe's is a best method to prevent a similar situation with the existing code that it has become a behemoth and has problems with updates to one app/UI system affecting other app/UI systems) that perform different tasks with different UI's. The application UI's need to be simple but relay significant data to the users: my coworkers. The UI's also need to be succinct in that if they want to perform a specific measurement, it doesnt require them to open 4 windows. Just one. This unfortunately creates a fairly big top level UI code 

However all of these exe tasks will need to be able to communicate with the same list/driver sets of network analyzers, DMM's, amplifiers, power meters, oscilloscopes, etc myriad of external devices... primarily through scpi/visa/tcpip (or gpib for the older units). The exe's will also all need to be able to save header data about instruments, channels, ports, etc as well as the raw measurement data to a TDMS file.

Given all of this, I just want to make sure that AF (asynchronous mostly) is the correct type of code to pursue. There are a fair number of repeated driver type tasks (with small differences) performed from external device to external device, and all codes would use the same ending TDMS file structure for saves which is why I believe AF is a good option rather than copying sections of code across multiple builds. The argument against AF is that with constant communication to an external device, perhaps a synchronous type of conventional coding like producer/consumer is perhaps the better option as communication to and from the device commonly has to be very serial in nature.

Thanks in advance for your support. If the consensus is that AF is probably the route to go then Ill of course have tons more questions about how to architecture it for good data sharing, efficiency, etc.

Thanks,

Chase

[AristosQueue (NI)]

I only have time right now for a very brief reply. I hope someone else can later give more details. What I can tell you is that I designed AF for people in your situation -- minimal experience and a corporate directive to do what has never been done before on a short time frame, often with a "surely testing is easy" comment. 🙂 

Yes, I do assume you have OO knowledge enough to follow the vocabulary, but a lot of AF is very much "fill in the blanks" type of coding: it's meant to give you a framework for the hard communications and synchronization pieces where you fill in the business logic. Many folks with not a lot of deep experience have successfully used the AF for this sort of work.

I may have time to write more later, but no promises.

[BertMcMahan]

I quite like AF myself for medium to large applications. Very small applications I don't always bother with it, but once you get used to it it's not a lot of overhead.

I don't typically use actors to talk to my devices. I just make a hardware abstraction layer (HAL) object and use that within an actor. Normally I don't need to have a dedicated message handler always running to, say, talk to a power supply. You could do an actor if you need multiple things to be talking to a single device at once, but even then the actor will be a wrapper around the standard object interface layer. And for that case I'd consider just using a by-ref object and again not use an actor.

Ask yourself- do you NEED asynchronous communication? If not, just have your actor talk directly to the HAL object.

A common tendency is to try to make everything an actor, and in reality not everything needs to be one. Think of an actor as replacing a message handler/state machine, not as replacing an object. If you need to do a specific measurement, implement that as a message to an actor, not as a whole actor in and of itself.

TDMS streaming could go either way. Generally, I'd say not to make it an actor, since the streaming functionality is handled in the TDMS functions themselves.

One place I use an actor is for ongoing measurements. For example, a DAQmx acquisition loop needs something to service the Read requests and buffer the signals, so I use an actor for that. The actor reads the signals and then sends the data as a message to a receiver. Once the receiver is done reading, you just stop and kill the actor. When you need more data read, start up the actor again. That's the other thing I've had to learn about Actors. When I used to use subVI message handler loops like in the LV examples, they had to start once, and be able to start, stop, and restart any number of times. With AF, I can just kill it and restart it, rather than having to maintain some kind of "idle state". It's a really helpful feature.

[Taggart]

More than architecture, I would be studying refactoring.

This course isn't in LabVIEW (it's in java) but the ideas translate. 

https://refactoring.guru/refactoring

I'm sure you can find a bunch of refactoring courses on Udemy.

There are also some good books:

https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599/ref=sr_...

https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?keywords...

and my personal favorite in that category:

https://understandlegacycode.com/first-aid-kit/

Also dropping actors into existing code is easy, until you try to get data back from the actors...

You might take a look at DQMH, I find it easier to integrate into existing code. I know this is the AF forum and I'll probably get flamed for that, but that has been my experience.

And whichever way you go, I %100 agree with Bert, if you don't need something to be asynchronous, don't make it into an asynchronous  actor/module. If you do, you are only complicating your life for no reason.

[AristosQueue (NI)]

> And whichever way you go, I %100 agree with Bert, if you don't need something to be

> asynchronous, don't make it into an asynchronous  actor/module. If you do, you are only

> complicating your life for no reason.

I largely agree with this. I would restate it as "if you don't have lots of stuff running in parallel that needs to communicate back and forth, then don't use the AF". It's the bidirectional communication among parallel tasks that trips people up that the AF really addresses. The asynch stuff is a biproduct of that. But if you can do it with a simple linear program or a simple producer/consumer cascade, do it. Definitely don't make life more complex than it has to be. The AF is there for those days when life is that complex!

Having said that -- if you have any UI whatsoever that governs a project that controls hardware... that's two parallel tasks that need bidirectional communication. 🙂

[drjdpowell]

You might want to get a feel for a few different frameworks.  In addition to AF, I would suggest DQMH, my own "Messenger Library", or "Workers" (all publically available with documentation resources).  See which one seems more intuitive to you, as they can be quite different.  All involve a significant learning curve, so you want to make a good choice.

[Taggart]

When it comes to picking a framework, here is a good starting point.

https://www.youtube.com/watch?v=4-dzdyYIPLU

It only covers the DQMH and AF, but as Dr. Powell pointed out, don't limit yourself to that. Checkout some of the other ones as well. A lot of new ones have popped up since that presentation was made.

On large multi-year project, spending a week or two at the beginning evaluating various frameworks would be time well-spent.

[AristosQueue (NI)]

> You might want to get a feel for a few different frameworks. In addition to AF, I would suggest DQMH, my own

> "Messenger Library", or "Workers" (all publically available with documentation resources). See which one seems

> more intuitive to you, as they can be quite different. All involve a significant learning curve, so you want to make

> a good choice.

Agreed! I built AF as an enabler not a straightjacket. 🙂

[Chase_H]

Thank you all for your replies!

I obviously still have some homework to do reviewing some of your links and generally trying to specify some of the different task needs more discretely; since there were several comments about some items being actors and some not.

As someone pointed out, Im definitely getting fire hosed up front but it is better to take the time to pick the right fire hose rather than go down the path of learning one architecture and realizing another would be better 6mo from now.

Thanks and will be reaching out again soon Im sure!

[Taggart]

---

@AristosQueue (NI) wrote:

Definitely don't make life more complex than it has to be. 🙂

---

This right here.

Start with the simplest thing that might possibly work.

If it does work, great! If not, then start adding complexity a little bit at a time.

It's always easier to add complexity than remove it.