Example Code

Message Bus Architecture - An Intro

Code and Documents

Attachment

Introduction

It all started when I was browsing across the forums and realised that I wanted an architecture that took all my favorite elements of LabVIEW (User events, Polymorphic VIs, Ease of Use, Flexibility being among them) and put them together all in one architecture...

Concepts

Let me introduce the idea of a Message Bus. You have subscribers to a message bus that can send or receive messages and perform actions as a result.

Basic Topology.PNG

A subscriber spends most of its time waiting for a message on the bus, and once its received a message, it can choose to discard or process it, and perform any neccessary actions.

So what is a message? Its a user event that contains a Message ID and Message Data (as shown below)

Message Format.PNG

Ok, thats good so far, but what about SubVIs?

Basic Tiered Topology.PNG


I propose that SubVIs (By this, I mean major SubVIs, that contain a big portion of your programs functionality like the DAQ handler, or a Comms handler) have their own local message bus and are linked to the top level bus via a Link. This means that all Top Level messages like Stop commands/Control commands are forwarded to the local message bus. This allows you to Stop all the subscribers (and hence the SubVI) from the top level easily, as well as send configuration/start/data messages. Now you have something that conceptually looks like this:

Basic Tiered Topology with VI Scope shown.PNG

Now I'm thinking- how I report things like error data back to the top level so it can decide whats next in terms of program execution?

Bidirectional Concept.PNG

...with this architecture its easy to send data back up to the Top Level VI too.

Execution

What do the VIs look like?

VIs.PNG

What would a typical subscriber look like?

A Subscriber.PNG

I have written an example VI that shows typical usage of this architecture, including the 'Link and Filter' functionality where a local bus can choose to only listen to certain message IDs, therefore reducing the traffic internally.

If you have any questions, please comment on this and if it highlights a lack of detail in this article, I will append it in.

I have attached 2 versions of the architecture, both in LabVIEW 2009SP1. One uses Strings in the Message ID, and the other uses a Strict Type Def Enum as the Message ID. Both have their advantages and disadvantages (loose coupling vs. tight coupling), and if you are undecided with this, I'd look at the String version first.

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
swatts
Active Participant Active Participant
Active Participant
on

Nice work, elegant, I'm wondering if you could encapsulate the queue reference by putting the whole lot in a wrapper VI.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Mark_SAI
Active Participant
Active Participant
on

I thought about it, it would likely involve some complications though as its not the same queue reference everywhere (I.e. Top level Bus and Local Bus) so I'd be looking at having a .vit component that I spawn an instance of for every unique bus and track which VIs are using which VIT reference which is certainly possible and I may well give this a go. (I would have to call it something totally different! Message Cloud perhaps...)

swatts
Active Participant Active Participant
Active Participant
on

hmmmm,On second thoughts i like the idea of using the polymorphic selector as the VI command. I reckon that a support VI should hold the queue reference internally. Looking at the technique, rather than the architecture I'm thinking this could be the basis of a rethink on our component design (LV "Functional Global" based state machine)..... you got me thinking boyo. 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

nblume
Member
Member
on

This is very nicely done, but 2 of the 3 times I have run the example VI, it has frozen LabVIEW.  The first time, it didn't happen until I tried to send a "Stop" message.  The other time it happened immediately after pressing the Run button.  Have you had any issues with this?  Any ideas what might be causing it?

Mark_SAI
Active Participant
Active Participant
on

Which version of LabVIEW are you using?

Do you have FDS or a lower version?

I'm interested in tracking down the cause of your crash. I am certain its not a fault with the underlying architecture as its heavily based on an architecture that has been used for large projects in the past.

Mark_SAI
Active Participant
Active Participant
on

The code as it stands needs updating (I will try and get round to updating the links in the article). All VIs should be changed to re-entrant (Pre-allocate) for the architecture to work bug-free during debugging/highlight execution.

Joe India
Member
Member
on

Nice work. I will get back with a detailed feedback.

prajwal.prithviraj
Member
Member
on

thx macaba,u have opened the box .we need to start thinking in ur way.

Contributors