Jump to content

[LVTN] Messenger Library


Recommended Posts

On 06/01/2018 at 2:06 AM, burd said:

I got very confused because the VI Help for the Metronome Actor says that this actor accepts the Shutdown message (if I remember right)

I'll update the documentation.  Thanks.  

To be honest, I don't think I have written code to actually shutdown a Metronome actor in five years.  I just let them shut themselves down automatically.  Sometimes I don't even want to adjust the period at all and then I don't even bother wiring out the Metronome Address.  For example, here I need to limit the total size of debug log files and check them once an hour (3600000 ms).  It's "set and forget"; no shutdown code needed.

Self Message once and hour.png

Link to post
  • 2 weeks later...
  • Replies 297
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

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 chang

For anyone using this package, I’ve uploaded the latest version (should really have updated this more than once a year).  I’d like comment on the following new features: This is one of three asynch

I am trying to shift discussion of Messenger Library to a group at NI, as this conversation is at 12 pages and is hard to follow. New post about a beta feature  for TCP that I am working on: http

Posted Images

Hi James,

I really enjoy using your messenger library for several Labview pojects. I'm not complety sure if it is possible, but have you ever thought about using the actors in a kind of plugin in architecture way  (simunlar to this: https://forums.ni.com/t5/LabVIEW-Development-Best/Plug-in-Architecture-using-Packed-Project-Libraries-lvlibp/ta-p/3514395). 

So my questions is: Is it possible to save actors as packed libary and e.g. launch them from another actor? And if yes, what would I have to change (i'll guess your actor launcher would hav to be modified?)?

Best ragrds from Stuttgart,

Jan

Link to post

I have not done any PPL work, but the basic first step is to build Messenger Library into one or more PPLs.  This may involve changes in library membership to properly group things into PPLs (so it might be a bit of work to convert over existing projects).  Then (I think) one just has to make your code reference the new PPLs and build your own PPL.

If you want to try it, make a fork of Messenger Library, through all the extra bits of it into the main "SendMsg" library and see if you can make a PPL.

Link to post

I'm wondering if others see a similar behavior (described below) and if it's the Messenger Library, LabVIEW, or if it's related to a possibly slow PC (my IT department is extremely overly security cautious).

I have a project that has many Actors (currently about 80) and I want to change some of them to re-entrant.  When I change from NR to Shared clone reentrant execution (in VI Properties), afterwards it takes anywhere from 30 seconds to over a minute to save.  Is this expected? 

I've also noticed other slowdowns in the project (Find Project Items) that can take a long time to respond where the cursor blinks from a arrow cursor to a waiting cursor for about 30 seconds during which I can't select or do anything in LabVIEW.

 

Thanks,

Bruce

Link to post

Make sure your VIs are the right reentrancy, as that dialog will happily change the parent methods in VI.lib.   All "Actor.vi" should be shared reentrant, and all "ActorNR.vi" should be non-reentrant.

Link to post
  • 3 weeks later...
On 4/8/2017 at 3:15 PM, drjdpowell said:

Ah, so the issue is that an actor both replies with an error message, and publishes one.  One possible solution is to say that only one actor should “own" the error.  If actor_a asked actor_b to do something, and an error occurs, then actor_a is the one responsible for handling/reporting it.  You can do this by changing the error handling case to only publish the error message if their was no return address attached to the original request message.  Thus you Reply OR Notify, rather than Reply AND Notify, and there is only one error message.

Dr Powell,

How do I find out if  there is no return address attached to the original request message?

thanks

Edited by burd
Link to post
1 hour ago, burd said:

Dr Powell,

How do I find out if  there is no return address attached to the original request message?

thanks

Read the address and test it by one of these methods:

No Reply Address.png

The left one tests for a "Null" address (the standard parent "Send" object), while the right one tests that the reply address is still "valid" (meaning a message sent to it will go somewhere).   

Link to post
  • 2 weeks later...
On 11/09/2017 at 9:51 PM, drjdpowell said:

Is the NI Service Locator not running on the remote machine?  When I run the example Clients with no Server running, they quickly return error 1510: "The requested service was not found as a registered service with the NI Service Locator.”  

Hi James, I am unable to replicate your Youtub example "Messenger TCP". I received error 1510 when run Client with NI Service Locator running. I am using Labview 2016 and planning to run server on RT cRIO. Please advice. Thanks

Link to post
On 05/03/2018 at 2:42 PM, Noriker said:

I received error 1510 when run Client with NI Service Locator running. I am using Labview 2016 and planning to run server on RT cRIO.

Error 1510 is "The requested service was not found as a registered service with the NI Service Locator.”   Does the LabVIEW Example "TCP Named Service" work on the two machines?  Did you use the right IP address?

  • Like 1
Link to post
14 hours ago, Noriker said:

Messenger TCP example works well on a cRIO. If network disconnected, can actor restart by sending initialisation message instead shutdown the actor?

It's a Client-Server design, where the cRIO actor would be the Server.   A disconnect of the Client has no affect on the Server and it continues to run.   The Client (on the main computer or another RIO) needs to detect the disconnection and attempt to reconnect.   Nobody needs to shutdown, though the Client will need to go into a loop of trying to reconnect every few minutes until the network is back up.  See the conversation starting here, where bbean was dealing with the issue of the Client not being able to connect to the server.  

  • Like 1
Link to post

I'm returning to some Messenger work after a short break, which might explain why I can't see what's wrong with my Messenger Actor based project.

Right now I have a Main actor which is responsible for launching a number of sub-actors. One of these is the FPGA actor. Directly after the launcher I register for all notifications.

Within FPGA actor, the "Self: Initialize" message runs a number of states, the final one being to publish a notification event. This is to be received by the Main actor to known when it has initialised.

Unfortunately this event is not received by the Main actor. I believe this might be because the registration request has not yet been processed by the FPGA actor, and therefore the notification event has no listeners and is effectively unheard.

So my question is: what's the correct way to launch a sub-actor such that you can receive a message from it once it has completed initialisation steps?

 

Main Actor launches FPGA subactor and Registers for All Notifications

main_launches_fpga_subactor.JPG

 

FPGA Actor performs three initialisation steps, the third being to provide a Notification Event

FPGA_actor_notifies.JPG

Edited by Thoric
Link to post

A coincidence.  I'd just committed to fixing the issue of missed events from the "Self:Initialize" case five days ago.  See Issue 13.  However, using a State Notification instead of an Event one should fix that; does it not on RT?  Note, BTW, that you shouldn't do both an Event and State Notification on the same label (I think this isn't the problem though).   If it is only an issue on RT, then I will look into the TCP communication actors, who treat the first Registration message specially (and thus a bug might be their).

Link to post

Are you sure you aren't passing an error in to the "Notify Event"?   No event is sent on error in.  I generally don't connect the error wire to notify unless I want to not Notify on error.

Also, are you passing the Notifications over TCP?

Link to post

Errors are captured in the final "" state, so if there was an error it would be sent to the caller (Main) where I log all errors. I don't see any such error. Also, no TCP usage.

In the meantime I just quickly created a new project with two actors, one calls the other, and proven:

1. The Self:Initialise state cannot send a notification to the caller - it won't receive it (you knew this, bug 13)

2. Sending a message to the subactor directly after registering for notifications, which gets the subactor to send a reply, does work. But it didn't in my actual project work, only in the test code. So there's either a race condition, timing error, or something else different.

I'll look into this more tomorrow.

Edited by Thoric
Link to post
11 minutes ago, Thoric said:

2. Sending a message to the subactor directly after registering for notifications, which gets the subactor to send a reply, does work. But it didn't in my actual project work, only in the test code. So there's either a race condition, timing error, or something else different.

When something works in the IDE but not in an exe (assuming nothing stupid e.g.e path differences) it very often is a race condition showing up. Never fun to do but can you chuck some delays into your launching code and/or the launched code to simulating running in the IDE which is usually slightly less responsive.

Link to post

Does the ObserverRegistry probe work on RT?  The probe included in the package will display all the registrations just before you make the Notification.  Another idea is to take one of the message loggers, make it a nonreentrant actor so you can open its FP on RT, then use it to see if the notification is getting though.

Link to post

So, the first thing I tried was a delay between registering for notifications, and sending the first message. This fixed it. So there's a race condition. Basically I can assume that the registration request is performed asynchronously and is not complete before the subactor sends back a message in response to the "Deploy_FPGA" message.

James - how can I ensure a regsitration request is complete before the subactor sends a notification?

 

messenger_message_delay.JPG

Link to post

I'm surprised as that shouldn't be possible.   Messages are handled in order sent, so the Registration must be handled before your "Deploy_FPGA" message.  Everything in this code is strictly ordered, so there should be no race condition.   Does the ObsReg custom probe work on RT?  If so can you place a probes just before the "FPGA_Initialized" Notification, on both the ObsReg and the Error in.   If it is a race condition preventing registration, you will see this in the ObsReg probe (do it both with and without the time delay).

Link to post

James, the code works in development mode, so using the probe (assuming it works on RT) will show no issues.
It's only once built into an executable and deployed that the problem occurs. Once built, I don't see how I can use probes :-(

Edited by Thoric
Link to post

Ah, sorry, so it works on RT, but not in an EXE on RT.  

Debugging the hard way, then: you’ll have to log to a file.  The method "vi.lib\drjdpowell\Messenging\ObserverRegister\ObsReg Core\ObsReg to Table.vi” may help in this.

Also, quickly try:

1) not running the error wire through the Notify

2) double check you didn’t accidentally run the wires under the Register-for-All call rather than through (this has happened to me once; one cannot tell by looking).

Link to post

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***
      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.
       
      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
    • 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.