Jump to content
News about the LabVIEW Wiki! Read more... ×
drjdpowell

[LVTN] Messenger Library

Recommended Posts

James,

This may have been answered before, so forgive me if it has.

The actor model you use ensures sequential execution of the Event Structure and State Machine. This means the state machine can complete its task(s) without interference from the event structure, because the event structure literally cannot react to any incoming messages until the state machine completes its stack and yields execution.

But what if you have a case where this is unhelpful? For example, consider that the state machine is in the middle of a series of state changes, controlling hardware and taking measurements, when an Emergency Stop message comes in. I would want the emergency stop message to be received and reacted upon immediately, with the event structure being able to inform the state machine that it needs to take into account this emergency stop state, change its task list (stack) and instead put hardware in a safe state with immediate effect.

Currently I don't see a way to do that without the state machine yielding to the event structure at regular intervals (every 100ms for example), which requires some uncomfortable coding styles. I could, for example, let the state machine yield to the event structure with a status flag set in the shift register that the Timeout Case uses to recognise a need to return to the state machine. This would give the event structure a chance to look at incoming messages and react. But what if a benign message comes in that would normally be held back until after the state machine was finished? Suddenly it gets processed and dealt with too soon. This is why it's important not to yield to the event structure before the state machine is ready to process new requests.

Alternatively I somehow use a notification style message within the state machine itself, enabling the possibility of checking an Emergency State notification at regular intervals within the state machine, preventing the need to yield to the event structure. But this notifier would have to be populated from outside the actor, because the event structure is not free to create the notification. This means we now have external source able to directly influence a privately scoped state machine, bypassing the controlling event structure and defeating the primary principle of the actor's stacked structure. Or do we let this fly because we're just using it for emergency notifiers?

Your counsel is greatly sought, my friend.

Share this post


Link to post
Share on other sites

I few other methods for you to consider:

1) a separate "helper loop": in this, the main loop of the template is a "manager", with a separate loop inside the actor doing the work.  The "worker" can be controlled by non-actorish ways (such as an Abort Notifier) by the Manager, which is always capable of handling new messages coming in.  This encapsulates the non-actor communication, keeping it local (and understandable).  I likely addition to this is a "job queue", to hold the list of actions that the manager queues up for the worker.  Here is where one can have job priority, or cancelable jobs.  Note that this is different from the "action stack" (what you called a "state machine").   These are different things that are too often combined.

2) Have a "Sequence actor" that does the long actions, which can't itself be aborted, but which acts on hardware via short-to-execute synchronous Request-Reply messages to separate hardware actors.  Send the "abort" messages to the hardware actors, putting them into a safe-mode state where they reply to action requests with errors.  The first such error message causes the "Sequence actor" to end it's sequence (using standard error-chaining logic).   Note that if your stop really is an emergency then this bypassing of your complex higher-level logic to talk directly to low-level hardware actors is actually a lot safer and more easily testable.

3) An asynchronous version of (2), where the "Sequence actor" uses Async Request-Reply for interaction with the Hardware actors.  Less flexible than (2), but more properly actorish, in that the Sequence actor is always able to handle messages.

I actually don't mind your abort notifier triggered from outside the actor.  This is, as you say, bending the rules for a limited and clear purpose, and for the special case of aborting.

 

Unfortunately, though, you're dealing with the problem of "state" (true "state", not the actions of a so-called "QSM") and that isn't ever easy.  

  • Like 1

Share this post


Link to post
Share on other sites

Interesting - these offerings are significant effort. I was hoping for something simpler, but I wonder perhaps if the use of a 'globalised' notifier is the solution I need. As you state, it's for a limited and clearly defined purpose.

I'd be interested to see suggestion 1, (the helper loop, with the main actor template becoming the manager of an internalised worker), provided as another template option from the scripting tools. 

Thanks for the advice James - professional as always!

Share this post


Link to post
Share on other sites

Hello James,

Since I started using the framework I started having trouble with the so called Infinite Reset of Death during shutting down of the application (executable). The cause of the problem is not the messenger library, and now there is a way to deal with this problem as explained here:

http://www.labviewcraftsmen.com/blog/not-so-infinite-reset-of-death

I used the methodology and it works very well! Now there is no more possibility for the resetting VI message that never goes away during shutting down of the application.

I hope users of the messenger framework find this useful.

 

Share this post


Link to post
Share on other sites

When updating Messenger Library from version1.8.3.82 to version 1.9.6.99, my application throws this error:

image.png.74513b9956fdf661a681b807adc0094c.png

Looking at the code I see the change that was made and comments pointing to here to explain the change:  https://labviewcoder.com/2016/07/06/quick-tip-asynchronously-launching-vis-the-right-way/

If I change Dynamic Launch Shell.vi on the block diagram back to a strictly typed VI reference, the error goes away.  What's gone wrong?  

The library has made my application development much easier, but I don't understand things well enough when an issue like this comes up.  For now my solution is to backdate the library to the previous version, but I'd like to understand what's happening.

 

Edited by dhendrix11

Share this post


Link to post
Share on other sites

This is Issue 9, the trickiest problem in Messenger Library at the moment.   Can you try version 1.10.6, which is in the LAVA-CR (this has been submitted to the Tools Network and is working its way through the process.  There is no ideal solution but this is my best attempt.  Alternately, you can try renaming your Main:ActorNR to something else (assuming you don't need to launch it but are instead running it directly).

Share this post


Link to post
Share on other sites

No errors when running version 1.10.6.  I am running my main actor directly, so I'll keep the renaming solution in my back pocket if I see the issue pop up again.  Thanks for your help.

Share this post


Link to post
Share on other sites

James,

Is it possible to glean information about the sender of a message? In my Actor I receive a message and it would be useful if I could learn some originator details, namely the Name of the Actor (VI Name perhaps). I wonder if it's possible to learn this info from the Reply to... indicator of a Read Reply Address call?

image.png.eb0a0b571ee6c72bc34a289594451d8e.png

A little bit of background - I want my actor to be smart enough to recognise where a message has come from. It's 'actor agnostic', except for one in particular, and if packets come from that one particular actor I want to perform additional tasks. I can't place additional information into the message itself, so I need this actor to be able to determine the source of the message automagically. Can we do that?

Share this post


Link to post
Share on other sites

Does your receiving actor know the exact reply address that the special sender will use?  You can use addresses as unique identifiers with "equals".  There is a vi in the palettes that searches an array of addresses for the reply address on an incoming message.

Your design is different from ones I'm familiar with, so that may not be a good answer.

Share this post


Link to post
Share on other sites

I was adding a 'quick' feature to my framework - in retrospect it wasn't the right approach so I've changed my tactic and now I have a better implementation that doesn't require this actor knowing the message origins.

I appreciate knowing now though that the addresses are directly identifiable, even if we cannot extract any information about the address from it.

Thanks James

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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