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

Wow, 47 pages is more than I've ever written on Messenger Library.   Please post it.

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

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.


×
×
  • Create New...

Important Information

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