Jump to content
drjdpowell

[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

Share this post


Link to post
Share on other sites

Dr James,

I'm learning Messenger Library to see if it suits a software defined radio retirement project. To remind me of the basics, I've made a 47 page programmers note. It's free to you if that's useful, otherwise I will keep it private. 

Share this post


Link to post
Share on other sites

Sorry, I may have busted the link in the Wiki by editing the programmer's notes above. Could you fix it again and I'll leave it alone ? 

:oops:Bob

Edited by Bob W Edwards

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
 

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

859434944_DefaultDEVEventHANDLING.png.9cbf2382737d6ff7e43aa09785e44a86.png

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Bob, I just saw your document. WOW! Thank you for contributing that to the community. I'm looking foreward to reading it!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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,
Max

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Thank you James for a prompt reply.

Indeed the "Timeout Watchdog" will make it clear to the main if something goes wrong and if the code used is well-written
there should be no occasion when actor becomes totally unresponsive (in the ideal case).

Thanks again for everything.
 

Share this post


Link to post
Share on other sites

Unfortunately one sometimes has to call code like hardware DLLs that are not well written.  I have to use a dll that will throw up a dialog box underneath the main LabVIEW window (never to be clicked on by the User) if it has a problem.  

Share this post


Link to post
Share on other sites

One possible option with a bad hardware driver is to make your actor an independent exe, using the NetworkMessenger for communication  Then you can kill the entire exe and restart cleanly.  I've never done that, though.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
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***
      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.
       
      James
    • 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?
      Toplevel:

      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
×
×
  • Create New...

Important Information

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