Using LVOOP for Continuous Acquisition and Logging

[Nathan_S]

I'm designing my first real application using LVOOP.  I have the following processes that need to operate concurrently and independently:  Data Acquisition, Image Acquisition, Data Logging, Image Logging.  I'm using a Producer Consumer (Events) type architecture with each process having QSM's. 

I have looked at using the LVOOP architecture where there is one basic App Command class that has children with a Create Action and Do method (if anyone has looked at the TLC with Classes project from the NI LVOOP training).  Each class performs its own Do method and just overrides the Do method of the common parent, App Command.  This seems to be great for smaller applications, but I think I will end up with like 50 classes total (e.g., the Data Logging "module" will need to have an Init class, a Start class etc.).  Each Module mentioned above will need to consist of a ton of classes.

So I tried looking into using individual methods and use those like typical "modules" (like Core 3) where the biggest reason for LVOOP is the data encapsulation.  I am confused as to how to approach many independent processes requiring communication with a main handler and still using LVOOP. 

I understand that this question is a bit vague.  I guess in summary, are there any examples online that you could provide that use LVOOP with continuous applications, not just single measurements or user interface type handling?  Or any advice as to how to proceed?  Thanks in advance for any help.

[Nathan_S]

Bueler.  Bueler.

(Hopefully someone gets the reference )

[tst]

a) Yes, you would get a lot of people who get the reference (although presumably most would be at least 30).

b) For many processes, you would probably want to look into actor oriented design, which is exactly about having parallel processes and communicating between them. There are various implementations and one is NI's actor framework (which ships with 2012 and is available online for 2011) and there have been some lively discussions about this. I would suggest you go look at the actor framework group in the communities area, as well as the large apps group. If you're using 2012, LV also has one or two shipping template projects which demonstrate one way of doing this in the create project wizard.

[Nathan_S]

Thanks for the help.  I am using LV 2012 and have looked extensively at the Actor Framework (read the template documentation and the whitepaper).  I'm just worried that I don't fully understand it due to the immense complexity of the framework and wouldn't be able to tweak or poke as needed for my specific application.

I use the Continuous Measurement and Logging (DAQmx) template that ships with LV 2012 for most of the projects that I do.  I'm just not sure how to switch from sending a string/variant cluster over to sending a class instead (probably by value for now as that seems a bit easier).  I'm also unsure of how to integrate the methods into the Case Structure of each process' While Loop (or whether a Case Structure is needed anymore due to Dynamic Dispatching).  Functional programming is no problem, but right now LVOOP is throwing me a curve ball, I just figure that it's worth the effort now as this seems to be the way NI (and most of the software world) is going for the latest programs.

[tst]

It's certainly true that LVOOP and the command pattern used by the AF offer a very different way of writing code which can be harder to read. I wouldn't force myself to do it just because that's what a lot of other people do. If it doesn't suit your way of thinking it won't make anyone happy. I would suggest trying to read some books on the topic and starting with a small application so that you see if you get it. The groups I mentioned earlier probably have some links in the discussions to reference material.

As for how to send and process, you basically create a class which inherits from the message class and has two methods - send takes your data and builds the message object and do is called on the actor when the message is received and contains the actual code. This replaces the case structure. The message maker automates some of this boilerplate code creation.