Mark Balla

Hello Everyone I've been following this thread intently and comparing the comments to a framework that Rob Humfeld, and his team at JET and I have been working on since the CLA summit. Rob presented an idea that he and his team were working on called the JAMA framework. I was able to video record the presentation and the next week when I got the code from Rob I dove in and began working with it. Since then we have made many refinements and used classes to make the framework more powerful. Since this thread has discussed many of the issues that we have tried to design into the framework I thought this would be a good time to introduce it in its current version. At the CLA summit someone said that this framework was akin to an observer pattern. Since I wouldn’t know an observer pattern from a quilt pattern I will leave it up to others to decide what it is. I currently call it the Msg_Routing framework the fully tested version will come from JET sometime later this year. The framework has 4 major components Modules, Msgs, Couriers and Routers. There is a 5th component called Module Router but it is not necessary to use the framework 1. Modules are any vi that needs to sent and/or receive Msgs. To work within the framework the Module will need to create and manage a Courier and a Router for each Msg</li><li><font face="Calibri">2. </font>Msgs is a defined data set that is transferred from one Module to another. All child Msg class will inherit from the parent Msg class.</li><li><font face="Calibri">3. </font>Couriers: An abstract class which is the Msg transfer mechanism by which the Module will receive messages. A Module will create a courier child class and register the class to receive Msgs. Child classes Queue_Couriers,Event_Couriers, and Notify_Couriers are already a part of the framework</li><li><font face="Calibri">4. </font>Routers: These hold the information that tell a shipping Module how to get it’s Msg to other Modules. A Router is created for each Msg and they share the same name. A Router is a named single element queue so all Modules can access the same routing data. The Router’s data is an array of Couriers.</li></ul><br><br>Framework features<br><br>Modules are totally autonomous and can connect and disconnect from the framework at run time without affecting other Modules. The Module is responsible for connecting and disconnecting to and from the framework and is not dependent on its caller for anything. Modules have no knowledge of each other only the Msgs they deal with.<br><br>Modules are responsible for creating and destroying their own Msg transfer mechanism called Couriers. One of the attributes that I have use from the Actor framework is that a Module is responsible for creating and destroying its Msg Courier. Callers no longer have to create a reference and pass it to the callee. <br><br>Msgs are Global in scope and are usable by all Modules. Any Module is allowed to ship or receive a defined Msg. Msgs and Routers are the only two things that connect Modules to each other making this framework very loosely coupled. <br><br>The Msg transfer mechanism or Couriers is abstracted. This allows one modules to use "Events" to receive Msgs and another to use "Queues". The decision to use Queues, Events, Notifies, or any other is made on a Module by Module decision and does not have to be a system wide constraint. <br><br>A Module must register for every message that it wishes to receive. To receive a Msg a Module must find the Router and place it’s Courier in the routers shipping array. <br><br>To send a Msg a Module gets the Routers shipping array for the target Msg and ships the Msg to each Module via its Courier. Data consistencyis maintained because Msgs are copied and sent to Modules not stored. <br><br>Here are some diagrams to help visualize the framework. They correspond to the demos in the attached code.<br><br> <br><br><br><br><br><br><br><br><br><br><br>Developers<br><br>Module Developers only need to care about few things to work within the framework. What messages to receive, how those messages will be received and what messages to send. Developers can choose which method of Msg transfer works best for the module requirements by using a Courier child class that implements a specific mechanism. Only the Msg format is defined by the frame work how those Msgs are sent is up to the developer.<br><br> <br><br>Major Points<br><br>Msg transfer is completed without any kind of mediator loop.The Msg Router provides the information on how to send the Msg and the Module Shipping the Msg does the actual work.<br><br>Because it is the shipping Module that does the shipping and not another mediator loop, there is little loss in performance. <br><br>Modules are only coupled by Msgs and not the way in which they are transferred.<br><br>The full framework is attached complete with code, demos and images. It is written in LV 2010. <br><br>To start using the framework load the project and open the [Module Tree].vi all of the instructions are in the block diagram.The diagrams and instructions are inside the cases of the case structure.<br><br>Please let me know what you think of the framework good, bad or otherwise.<br><br> MSG_ROUTING.zip<br><br>Mark

You didn't mention this so I will for others benefit. The VIs in the DAQmx tool kit are locked meaning the code is not able to be seen. Would you be willing to share the code with us? I'm sure many members would be interested to see how this is done. Mark

Certified 6-8-2011 Placed in XNode Category.

Currently all my editor has to do is generate an error and the old ni edito comes up.To call the new ni editor you would need to change the code to dynamically call it and close down mine.

Thanks for notifier ing me about the bar b queue it's going to be a great Event.

I second the removing of the ini file. starting labview where it has to create it's own ini seems to fix this problem for me. Then even if I put the old on back with no changes every thing is back the way it was,