A Call for Better LabVIEW Design Patterns

[Elijah_K]

At the recent LabVIEW Architect Summit that took place here at NI's headquarters, I had a lot of very valuable discussions and received a lot of great feedback from some of our most passionate and active users. Today, I wanted to bring up one topic in particular that stood out for me: a need for more advanced design patterns and templates for large LabVIEW applications. 

In an effort to find and identify more advanced architectures and templates, I wanted to reach out to the community to get your ideas and any examples you have.  Since the summit, I've seen a handful of really impressive examples and heard questions that indicate a lot of very similar challenges.  Ultimately, I hope to develop a more comprehensive set of templates that we can make available to both new and advanced LabVIEW users.

To spur your brainstorming, examples that I've seen or heard of include: plug-in architectures for dialogs, communication mechanisms and configuration data storage.

So, please share your ideas and thoughts... what design patterns can you share? what templates would you like to see?

[Ben]

We could greatly benefit from an Active Object template.

The following was cut-n-pated from the wikipedia article found here.

"

The active object design pattern decouples method execution from method invocation that reside in their own thread of control.^[1] The goal is to introduce concurrency, by using asynchronous method invocation and a scheduler for handling requests.^[2]

The pattern consists of six elements:^[3]

• A proxy, which provides an interface towards clients with publicly accessible methods.
• An interface which defines the method request on an active object.
• A list of pending requests from clients
• A scheduler, which decides which request to execute next
• the implementation of the active object method.
• A callback or variable for the client to receive the result.

"

It should be completely open so we can mod it (no passwords!).

AS much as possible should be implmeented to allow us to set what class it inherits from as well as let us create classes that can inherit from the Active Object Class.

I feel a GOOD Active Object will eliminate most of the calls for "by reference" and let LVOOP take the next step up inot larger applications.

I have put together a number of thing that approach this but I can't share those or think they are ready to share. How I implemented those ideas.

"A proxy, which " A queue has an enum to spec which method. Client submit the request Active object does them and returns results via another queue which can be specific to each client.

"An interface which defines the method" see on queue above

"A list of pending requests from clients " see request que above.

"A scheduler, which decides which request to execute next " my version execute the request in the order they are found in the queue.

"the implementation of the active object method. " A "Do Command" in the Active Object invokes the requested method on its local data (stored in SR of Active Object)

"A callback or variable for the client to receive the result." I create a response queue in the client (code requesting the method) and include that queue ref when the client queues up the method request. When the method has been completed in the Active Object any returned data get shoved in that queue so the requestor can find the data.

THe use of queues in and out lets me implement time outs so if the Active Object dies the rest of the code does not hang.

I use Active Objects too

Background logging

Background I/O

Independant functions

Or most designs where I need something to take care of some task autonomously that can just do their job once started and do something for other parts of the app.

If you even have to collect data from a half dozen source and no one thing is allowed to hang the others Active Object fit in very well.

Ben

[AristosQueue (NI)]

I want to make sure that readers of this thread are aware of the architecture level design patterns work that has already been reported in this thread.

[jcz]

Some time ago I was looking for a modular application architecture.Basically something that would allow me to create a small subPrograms that I could use both as a standalone applications as well as a part of a bigger tool. On one of the Cambridge, UK user group meetings Peter FitzGerald presented his idea of similar to what I was looking for. Here's the link to his example :

http://www.labviewcambridge.co.uk/index.php/downloads/40-all-downloads/13-2008-06-04-event-examples (the dynamic event example).

I implemented his approach (slightly modified) with a success. I sort of described it on lavag forum, topic: Modular LabVIEW Application Development . I must add that it was all done in LabVIEW 7.1.1.

Update: I just realised that at that time I also posted a question regarding Modular LabVIEW Application Development on this very forum :  http://decibel.ni.com/content/thread/2532 🙂

[mprimrose]

I tried downloading the the example file from the labviewcambridge link

and found it blocked.  Is it possible to post this file somewhere else?

Thanks,

Mark

[jcz]

Ah indeed. I forgot you need to be logged to download anything.  I attached two zip files to this post:

   20080604-event-driven-programming-demos.zip

   20080604-event-driven-programming-demos-printouts.zip

[Thoric]

I'm one of the hosts of the LabVIEW Cambridge (UK) User Group meetings. For some reason the 'management' decided our website should require registration to gain access to the content, but registration is free and open to all. There are some good example codes in there and a discussion forum (primarily for LabVIEW developers local to Cambridge).

[LuI]

Just to make it clear - the zipped code is no longer LV7.1.1, but LV8.5 or so.

[Daklu]

I'll second Ben's request that any new templates not be password protected.  Being able to customize them to fit our style and needs cuts down on repetitive coding.

Here's a general question for the community:  When should a component of functionality be included in a project as a set of templates, which the developer would copy and edit to achieve the application's goals, and when should it be included as a set of framework base classes, which the developer would inherit from to achieve the application's goals?

My programs are very OOP-centric so I tend to use sets of base classes.  I have both a simple dialog box component and a message queue component that are extended through inheritance.  I resort to templates only if the base class distribution is too complex or won't work (such as with my active object component.)  Are base classes better than templates?  <*shrug*>  I don't know.  Maybe it doesn't matter?

Other ideas:

• Model-View-Controller -- I've recently started using the MVC architecture and really like it.  I've been batting around the idea of creating some sort of reusable framework.  It may not be worth it to create a framework for general distribution; developers tend to have their own preferences when it comes to messaging and events, both of which the architecture depend on heavily.
• Observer Pattern -- It took me a year of trial and error (mostly error) to develop a robust observer pattern I'm happy with.
• Data Structures -- Lots of room here to explore.  "Buffered" arrays that grow in chunks rather than through repeated calls to the Build Array prim.  There are a bunch of tree structures that could be implemented.  I have a side project I'm working on that needs a hypergraph.
• Wizards -- Once I have reusable component ready I have to figure out how to make it easy for other Labview developers to add that component to a project.  In my case that often includes copying the entire module from some source location to the project directory, renaming the library and/or the classes inside it, and adding the library to the project.  I haven't experimented with this at all so maybe it's really easy to do...

[User002]

Hi all.

I was pointed here from the Discussion Forum. I have been developing and participating in creating LVOOP, Java, C# and Python programs.

I have created an _Examples_ folder for people who rather see code than documentation. I haven't covered it all yet, but I'll try to do that later on.

Some of the "patterns" I have created:

-Intermediate reference based oop.

+A snapshot of the referenced data in the class wire, it works just like normal LVOOP

+Thread safety as the "reference" is a queue and it is possible to put locks when exclusive access (lock/unlock) to the class data must be guaranteed

+Good speed. When not using lock/unlock the speed is the same as by value. When using unlock/lock, the speed is about 120kHz unlock/locks on a core i7 machine

+No VI bloat compared to other ref based solutions. Just one method has to be overridden, the rest is handled by the ExecutionBase class.

-StateMachine classes

+Every state is represented as a class

+Every state can contain a sub state machine, instead of one huge hard to debug state machine.

+Should be overridden to a specific state machine.

-IOStreams classes

+InputStream and OutputStream, abstract base classes representing an "interface" to access the data belonging to the classes below

+SocketStream, for streaming primitive data types onto a socket.

+FileStream, for streaming into a file

+MemoryStream, for streaming into the ram memory.

+Classes that write to an InputStream can take any stream. If you want to switch from writing to a file to a socket instead, no problems, same abstract base class!

-Threading

+Quite similar to C#, C++ and Java Threading.

+Inherit Threading and implement Work.vi. This will then execute as a "thread" in a VI server call.

+Quite great for data aquistion loops and control systems that loop continous.

-Events

+One event handler class, that will service each event created. Uses an event queue from the ExecutionBase class.

+All event types are creates as a class. The handler will handle the events depending on which class they belong to.

+Gui clicks can generate events, that get handled appropriately in the handler. Usually sporadic events.

-Networking

+TCPServer, encapsulates a TCP server for any kind of TCP data traffic.

+TCPClient, when connecting, a TCPClient can be handled by a service

-RemoteProcedureCall

+Base class for connecting to a remote machine running a RPC server.

-Service

+Base class for creating a RPC based server.

+Echo service, inherited the base class for checking communication status.

-ControlSystems classes for handling analog control

+Regulator, classes for feedback loops within ControlSystems, inherits to PID control and StateSpace control

-AnalogInput, inherits from Threading. Puts DAQ data on a queue. Supports multiple readers and multiple read rates. Can be used both for slower measurement data logging and fast control systems loops at the same time.

Thats what I go, and some more. Anyone interested?

BR,

Roger

Edit, forgot to add. The code is GPL, so please contribute back to these basic classes if you use them for any application.