Jump to content

[LVTN] Messenger Library

Recommended Posts

2 hours ago, smithd said:

I'm guessing shaun would say this one: https://lvs-tools.co.uk/software/websocket-api-labview-library/

But the one on vipm seems good enough to me. A lot of the others are only 1 half or the oth)er.

Thanks for the plug. But I would only recommend it if TLS is required since (as far as I'm aware) it is the only one that supports it.

  • Thanks 1
Link to comment
  • 2 weeks later...
  • 2 weeks later...

I've added the 'JSON based config load / save' to one of the Actor templates which is working well - the top level Actor ends up with it's config data + that of all subActors and subsubActors and so on in it's internal data - and back the other way too, to initialise controls and internal data. A few questions relating to config file storage preferences:-

1. Do you make top Actor do the actual file save / load or are there benefits in having a dedicated Config subActor take care of that (and maybe more)?

2. Where's the accepted location for such config data to go these days in Windows 7 onwards? I don't want to use the registry.

3. How best to manage configuration of an app whose subActor population can vary from run to run. My software radio needs to support a number of different hardware platforms so will load driver Actors to suit the hardware chosen. The user will want the configuration he's chosen to reappear next session. I guess the subActor responsible for loading the hardware drivers has a little more to do than blindly sending JSON config 'down the tree'. The data may not match those Actors currently loaded.

Using Messenger Library so far - good fun.

Link to comment

The signal path in my software radio is a complex number double waveform at 96ksamples/s in a range of buffer sizes of 1024, 2048 - 16384 set to suit the users needs. Highest CPU load is with 1024 sample buffers, where a buffer needs to run through the dsp to the speakers every 10.666mS. My prototype receiver uses ordinary LabVIEW queues to transport the data between soundcard daemons and the dsp vi.

Should I message the signal path around the place or should I stick with normal queues and message all the rest? Currently the desktop computer loafs along at 7-10% cpu load, but the target tablet is higher at maybe 30% so I'm mindful of not increasing that if it can be helped.

I guess the answer is really to try it and see!

Cheers Bob

Edited by Bob W Edwards
Link to comment

A few questions relating to config file storage preferences

Different applications can have different config needs.  In fact, a single app can have multiple different needs requiring different styles and thus different config files.  So it is hard to give general advice other than "JSON is flexible and easy".  Re your questions:

1) saving and loading files isn't complicated, so I've never seen value in a separate "config" actor.

2) I usually use just "LabVIEW Data", but see also this blog post.

3) I've done similar systems.  Here configuring the system involves reading (from the config file) what actors are needed and launching them before sending them there config subJSON.  This can involve dynamic loading of the actor class (from the lvclass name in the file).  


Should I message the signal path around the place or should I stick with normal queues and message all the rest?

Your max of 96 messages second doesn't sound that much to me.  Using a standard message will be simpler.  But this is something you should test as soon as possible.  It is ok to introduce something more complex if needed, but only if needed.

Link to comment

Hi dear Dr. Powell, I am using Messenger library for an application. I am launching a couple of Actors as Graphical User Interfaces, I have modified a template to use a basic event structure to send request and receive the responses of a Central Actor (Tree Hierarchy)  but now I want to integrate an error handler to report the errors of the GUI Actors to my Central Actor, I understand that the Reply method needs the address to send the error to the caller, but I have events where the interaction of the user triggers the event case so I dont know which would be the best strategy for error handling with my custom template.


I have attached my template, I have thought about wrapping the event structure with a case structure and using a shift register with the error cluster  to catch the errors and replace Reply method with Notify observers to send the error information to the caller, of this way I have a static address to my Central Actor, but perhaps it is not the best.


I will wait for his advice, thanks for the attention.

LSI Generic Actor.7z

Link to comment

I have modified a template to use a basic event structure

Can I encourage you have another look at the DEV template?  You seem to have taken the DEV template and deleted the entire "Follow-on Action" handler, and are now trying to reinvent some of the very features you just deleted.  At the very least, don't delete the error-handling case which already makes a Notification of any error. 

Have you seen the Youtube instructional videos on Messenger Library?

The DEV template looks complicated, but is designed to support both high-performance use, like a simple Event-structure (with error handling) and more complex use, like a JKI State Machine.  Since even simply-running things often require complex initialisation operations, I would suggest that starting with a "simpler" structure will led to less simple real-world programs.

Link to comment

Hi Dr. Powell, thanks for the response,  I think you are right, I am not the only developer using the framework and many of my colleagues are starting to use LabVIEW so simplify the template looked as a good idea haha but I did not consider the error handler at beginning, I prefer to teach how the entire structure works instead to reinvent the wheel. 

Have you seen the Youtube instructional videos on Messenger Library? Yes, I will return to the original template, until now I have found very satisfactory the framework, thanks for sharing with the community.

Link to comment

FYI, the DEV template is designed to be able to handle simple Events very quickly and easily, just like a more simpler Event-Structure loop.  The follow-on actions output from the Event Structure is set to "use default if unwired", and the default action is just the error handler (and message reply).  The "Next Action" and "Reply" subVIs that must execute are performance optimised to add negligible overhead in the default case of no actions and no message to reply to.


Link to comment
  • 4 weeks later...

Hi all,

I have a question mostly directed at James, but others can feel free to chime in. How do you represent your actors in UML diagrams? What I have in mind is that receivable messages correspond to public methods, frames in the state machine refer to private methods, and State/Event updates to the listener registry are private and notated with <<notify>> . What do y'all do?

Link to comment
  • 4 weeks later...
On 4/17/2019 at 11:38 AM, Conner P. said:

How do you represent your actors in UML diagrams? What I have in mind is that receivable messages correspond to public methods, frames in the state machine refer to private methods, and State/Event updates to the listener registry are private and notated with <<notify>> . What do y'all do?

Sorry, I missed your post while on vacation.   I actually don't do UML diagrams, so I'm not much help.

Link to comment
  • 1 month later...

Dr Powell,

First of all thank you for developing a dream library (framework), I've been using it for 2 years already.
It is incredibly powerful and elegant. There are no words to express my admiration of your work!

For couple of days I've been thinking about one scenario:

Imagine there are 5 actors, each of them is dedicated to one particular piece of hardware or software component. They are launched by Main actor.
Each of 5 actors has a state and it is updated once action is performed. Now, what if one of the actors gets into an infinite loop (or an action
that will make it stuck). In this case it won't be able to update it's state. However my Main actor doesn't know about it, it only remembers that the
last state of that frozen actor was, for example "good".

1. How to make the Main actor realise that one of its sub-actors is frozen?
2. What to do in this case with a frozen actor? How to restart it?

P.S. I've been thinking about using the "Watchdog" actor. Create 5 of them in Main actor and share with subactors.
Then inside of subactors constantly reset the Watchdogs. If watchdog wasn't reset, Main actor gets a message.
Not sure if this is the most elegant solution. And there is still question 2 left.

It would be great if you could share your thoughts about this. Thank you!

Kind regards,

  • Like 1
Link to comment

Hi Max,

Recovering from a stuck hardware actor is often impossible, as it is some dll call that is stuck and LabVIEW cannot abort the call.  Nor can the dll be reloaded without restarting the entire application.  However one still needs to recognise and report the problem.  I use the "Timeout Watchdog" recently added to the library.  The main actor uses that on the handling of some message that periodically comes from the hardware actor.

Now, another unreliable actor is one that handles potentially large blocks of memory.  An out-of-memory error will abort the actor, invalidating it's address, and you can use an "Address Watchdog" to notify Main.  In that case you probably can restart the actor and recover.

  • Thanks 1
Link to comment
  • 2 months later...

Is it normal to have reference leaks on "Parallel Process Library\Create ID notifier.vi" and "Async Execute Core.vi" when shutting down, using startup type 2?

When using Startup type 1 only  "Parallel Process Library\Create ID notifier.vi" has reference leak. 

Tested with "vi.lib\drjdpowell\Messenging\Testing\Test Queue Actor Folder\Test error on startup.vi"

See picture of trace execution, I''m on LV2018 and latest messenger lib.


Link to comment
On 9/12/2019 at 2:40 PM, drjdpowell said:

Yes, these references are intended to only be closed when the actor that created them stops running.  The term "reference leak" is used by the trace toolkit to indicate any reference cleaned up by LabVIEW when a vi goes idle, regardless of whether it is an actual leak.

Thanks for explanation, so I shouldn't worry about those.

I am asking because I have some stability issues with code and trying to pinpoint it with DETT toolkit.

What might not be normal is these startup handshake queues, they should be released after "Ack Startup" right?

DETT Trace.jpg

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By drjdpowell
      An extensive library for passing messages between parallel processes. Generalizes the communication method, allowing the message sender to use the method provided by the receiver. Supported communication methods include wrappings of simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.
      Communication patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates.  Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.
      An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..).  An "Actor Manager" debug tool is also installed under the Tools menu.  Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the Actor Model).
      ***Introductory Videos are on a YouTube channel.***
      ***A great summary of many Messenger Library sources, provided by Bob W Edwards***
      JDP Science Tools group on NI.com.
      Original conversation on this work is here.

      Now hosted on the LabVIEW Tools Network (but note that the latest version will often be on LAVA)
      ***NOTE: latest versions require VIPM 2017 or later to install.***
    • By drjdpowell
      I've started to make some instructional videos on YouTube for my Messenger Library.   I was inspired by Delacor's nice videos on their new DQMH framework and also by Steve Watts' CSLUG channel.  Any feedback appreciated.
    • By drjdpowell
      I’m hoping to add some sample projects to my “Messenging” package, and I thought it would be easy and instructive to rework one of NI’s templates, “Continuous Measurement and Logging”, as it is already somewhat actor-like with three communicating modules.  Attached is a (back-saved for 2011) copy of the NI project, with my version included (run “Main.vi” for the original, “Main.lvclass:Actor.vi” for my version). 
       I kept the basic functionality the same, but couldn’t resist changing some of the UI (in the old code, “Main” controls the UI; in the new code, published state messages from the Acquisition and Logging Actors set the UI).
      Continuous Measurment and Logging with Messenging.zip

       Any comments appreciated.   Is this example less clear than the NI original?  Why?  How could I improve it?
      In particular, is code like this (the most complicated interaction, I think) understandable without heavy documentation?  It’s a “Start Logger, then Start Acquisition, then Unset the Busy Cursor” three-actor chain message:

      I’m thinking of making a “Send Chain Message” subVI (that accepts arrays of addresses and message labels) to replace the above code.
      — James
    • By torekp
      At http://zone.ni.com/d...a/epd/p/id/4394, NI provides some example code for using Windows Messaging in Labview 2009. But the example generates and intercepts the messages in the same single toplevel VI. Is it possible to converse between two VIs using Windows Messaging? Would I need (or be able) to create a new DLL in order to do that?

      Create Windows Message Queue:

      From the Readme file:
      **How it works**
      A DLL included does all of the dirty work. The VIs in the library are primarily
      wrappers around the DLL with the exception of Wait for Windows Message.vi.
      When creating the first Windows message queue, the DLL installs a windows Get Message Hook and a CallMsgProc Hook on the LabVIEW process. This allows the DLL to inspect all messages heading for LabVIEW before LabVIEW processes them. The hook function determines whether each individual message is a message in which the queue is interested. If it is, it adds the message to the queue, and sets an occurrence. The Wait on Windows Message.vi is waiting on the same occurrence, and thus it continues its execution, retrieving the message from the queue. A number of utility functions are also provided for working with the queue.
      Any advice appreciated, even if it's "abandon all hope". (I'm a very weak C programmer.) I'm attaching the CPP code for the DLL, as a text file.
      Windows Messages for LabVIEW.txt
    • By jbjorlie
      I am working on a complete redesign of our instrument control software. I'll be using LVOOP and some form of messaging/queue system. The program must control 10+ different types of instruments, each having variations in I/O (pressure control, temp control, motors, different types of controllers, etc...). Most of our instruments run from a touchscreen attached to an embedded PC. A few run from a desktop and we have some that need the desktop version to control multiple instruments at the same time (using a tab control in my old program).
      So far I have a top-level vi that decides if this is a touchscreen, desktop, or simple test-viewer and launches the proper set of user interfaces. There are UI's for IDLE state, Test Setup, Config, Calibrate, Run Test, and so on... I have been studying discussions here from the super-megadudes on frameworks, lvoop, messaging, and how NOT to do things. After giving my best shot to AQ's AF I'm now using LapDog messaging from Daklu & it is time to ask some questions!
      1. Would you recommend using a single top-level UI and then plugging in different pages (Test Setup, Idle, Run Test, etc...) via sub-panels? In the past I have found that complex sup-panels can really slow things down. However, without them I end up seeing the desktop when switching between UI's. Not a big deal but not very professional looking.
      2. On the framework subject, is it better to have my I/O channels messaging a mediator who then messages the current UI or should they message the UI directly?
      3. What about updating indicators? It seems that passing UI indicator references to CHx is faster than CHx sending messages to the UI (or to mediator then to UI). I need good response time: Example - I want an LED to light up on the front panel when a heating relay is turned on and off. The relay may only be on for 50ms every second. Can I really send a LED ON msg and then an LED OFF msg and expect it to work smoothly? For 2-8 channels at once?
      3. Should I be re-opening the channels every time I switch UI pages or should I initialize them once and leave them running even when they are not doing anything? If the latter, what happens to the queues when the UI closes and another opens? I could pass the callee queue but what about the caller queue?
      4. I have a CHx parent class with children for each I/O "type". At runtime, some stored config information would tell CHx what child to use, which channel # this is, what to label the UI controls and indicators, and, according to the type of UI (also using classes), which controls to show/hide for appropriate functionality. There was a thought of giving each I/O class a UI and then plugging them into sub-panels on the bigger UI but I thought that may be too confusing for the poor sucker that inherits my code. It already seems that using LVOOP and a messaging framework distorts what I think of as "dataflow" drastically. Any quick thoughts on this or pointers to similar discussions?
      Here are some UI screenshots so you can get an idea of what I am doing:

      I truly attempted using the Actor Framework from the bottom up but I just cannot wrap my head around implementing it on this scale. Everything is so deeply encapsulated that I cannot figure out how to actually DO anything! LapDog allows me the freedom to implement a moderate amount of LVOOP without having to wrap every aspect of the program into classes and messages.
      I know that's a mess of vague questions for a single post, sorry! I'm new to all this.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.