[LVTN] Messenger Library

[ShaunR]

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.

[Bob W Edwards]

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. 

[drjdpowell]

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

[Bob W Edwards]

Writing the notes forced me to watch the videos closely. I'm going to use the notes as a quick-ref whilst getting started and hoped others might have a go if they had them too. Feel free to make changes/fix wrong stuff in whatever way you like - expect you're a busy man. I'm happy to own the doc and expand it given the info. It's written in libreoffice writer, which exports a good pdf. Now looking fwd to cooking up a few actors.

 

 

 

 

 

LabVIEW_Messenger_Library_-_Programmers_Notes_v1.8.odt LabVIEW_Messenger_Library_-_Programmers_Notes_v1.8.pdf

Edited August 8, 2019 by Bob W Edwards
added version 1.8 with extra sections

[drjdpowell]

Looks good, Bob.  Can I link to it from the Wiki?  

[Bob W Edwards]

Good idea, go ahead.

[Bob W Edwards]

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 ? 

Bob

Edited March 3, 2019 by Bob W Edwards

[Bob W Edwards]

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.

[Bob W Edwards]

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 March 17, 2019 by Bob W Edwards

[drjdpowell]

 

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.

[Andrés Yañez]

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

[drjdpowell]

 

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.

[Andrés Yañez]

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.

[drjdpowell]

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.

[Conner P.]

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?

[Conner P.]

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

[drjdpowell]

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.

[Maksim Kuznetsov]

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

[drjdpowell]

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.

[Maksim Kuznetsov]

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.
 

[drjdpowell]

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.  

[drjdpowell]

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.

[Axxel]

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.

 

[drjdpowell]

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.

[Axxel]

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?