Jump to content

[LVTN] Messenger Library

Recommended Posts

Your right, there is a reference leak here.  That Queue is a reference created in the actor's calling code, and is used to trigger the "Autoshutdown" message when the caller stops, thus invalidating the Queue.  There is an async component called the "ReferenceMonitor" which watches that Queue and sends the Autoshutdown message then closes.   ReferenceMonitor also polls the actor's address, so it can shut itself down if the actor dies.  However, I forgot to destroy the Queue in that case.   Here is an image where I have added the needed Close operation:



Thank for spotting this,

-- James

Link to post
  • 4 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 Dr James,

Recently I've been thinking about the security when of TCP messengers. For example,
often I am communicating with actors from TestStand steps. Everything runs on the same PC,
works perfectly. However, I realised that if potential attacker knows the port of the actor,
he/she will be able to connect to my actors from outside and potentially do harm.

At the moment I see 2 solutions:

1. To configure Windows Firewall for the main application to only accept local connections.

2. To bind TCP socket to localhost by specifying "net address" here:


The second solution will work regardless of firewall settings.
It would be great to hear your thoughts.Thank you!

Kind Regards,



Link to post
26 minutes ago, drjdpowell said:

What number do I feed to "net address" to make it local host only?  I wasn't aware of such a feature.

I would imagine the string (or u32 Net Address 2130706433)


  • Thanks 1
Link to post

Here is a beta version, 1.11.0, with changes to TCP Messengers to support the various TCP options about ports and the like.  Also adds a Keep-alive to detect half-open connections.  Bitbucket Issues 26, 27, 33.  I have not had time to do more than a basic test; it would be a help if someone could give it a try.   Note that I've replaced some of the creation VIs for TCP Messengers in the pallette (originals should still work, but I wanted to change VI names).


  • Thanks 1
Link to post

Thank you for your work Dr Powell.

I did some testing of the following VIs from the palette:


And I can confirm that I was able to establish connection using Service Name or Specific Port and
also it was possible to isolate actor from external network by setting net address to "2130706433" (


However I noticed that the "Name the TCP Service.vi" is now missing from the palette.
I could still get it from the new "Create the TCP Server.vi" and wire it as a "event messenger subtype" to "Actor Startup" VI.

Kind Regards,

Link to post
  • 2 weeks later...

Dr Powell,

Thank you for the new release of the library. It is a beautiful piece of work.

Today I faced a new challenge (sorry for bombarding the forum). One of my actors is using TestStand API to execute test sequences. I noticed strange behavior, when this
actor is executing synchronous TestStand API calls that take a noticeable time (>200ms) other actors (5 of them, fully decoupled) are also being freezed until that API call is finished.
I started researching what could cause this. I believe it is a deadlock because preferred execution system of all actors is the same:

Ideally I would like to set specific "Preferred Execution System" for actors that require it. I tried to change this setting in VI properties
for ActorNR.vi. But doing this affects whole class hierarchy and propagates to all actors (as a result they stay under the same execution system).

Idea that I have in my mind is to create another actor type that is configured for specific execution system.
It would be great to hear how would you approach this issue?

Thank you!

Kind Regards,

Link to post
37 minutes ago, Maksim Kuznetsov said:

One of my actors is using TestStand API to execute test sequences. I noticed strange behavior, when this
actor is executing synchronous TestStand API calls that take a noticeable time (>200ms) other actors (5 of them, fully decoupled) are also being freezed until that API call is finished...

By default, subVI are set to "Same as Caller" execution system, but they can be a specific system instead.  I suspect it might be just the subVI that does the TestStand call that needs to be in a different Execution System, not the calling Actor.vi itself.  So try just changing the subVI.

  • Thanks 1
Link to post
6 minutes ago, drjdpowell said:

By default, subVI are set to "Same as Caller" execution system, but they can be a specific system instead.  I suspect it might be just the subVI that does the TestStand call that needs to be in a different Execution System, not the calling Actor.vi itself.  So try just changing the subVI.

If that doesn't work you may have to separate the TestStandAPI calls out.  Are you using your TestStand Actor as a GUI or user interface?  If so you may have to create another Actor to separate out the TestStand API calls that are causing the log jam into a new Actor....That new actor should not have any property/invoke nodes which would force its VI into the UI thread.

  • Thanks 1
Link to post

Note: there is nothing stopping you putting all your code in an actor in one single subvi (which Actor.vi or ActorNR.vi then calls). So you can try this easily.

Edited by drjdpowell
  • Thanks 1
Link to post

Thank you for all the suggestions! Since I based my actor on NI example of TestStand UI the SubVIs were already configured to run in a separate execution
and I still experienced blockings. That is why I thought maybe the actor itself has to run in a different execution and posted in this thread.
However today I found out that the freeze was caused by a dialog box that was created asynchronously by the TestStand API (e.g. when it noticed that sequence file was changed).
There is a "TestStand - Set TestStand Application Window.vi" that accepts VI reference and makes all the dialog boxes modal to that VI (I set it to TestStand ActorNR.vi reference).

It works perfectly fine when TestStand Actor's front panel is the front-most window, no blockings. However if another actor's front panel is currently in focus (front-most) there will be
no dialog box until I switch the focus back to TestStand Actor front panel. And in this case both actors get frozen until I acknowledge that dialog box.

P.S. Simple front panel drag around with a mouse pointer make actors unfreeze.

I think it is related to modality settings that I will explore in more details.
Thanks again James and bbean. I highly appreciate your time and support.

Link to post
  • 5 weeks later...

How does your calling code keep track of the different clones?  Match that.  If the caller gives them specific names, such as storing the actor addresses in a cluster, then use those names in a JSON object.  If, instead, the actor addresses naturally are treated as an array, then store a JSON array.

Link to post

Exactly.  You can even do the case where the types of actor is determined at run time, in which case the caller makes a JSON object like this:

{"Actor Class Name":"MyActorX.lvclass","Config":{...}} 

Then on application load, the caller launches an actor of that class, then sends it the "Config".

Link to post
  • 3 weeks later...

Hello Dr Powell and everybody. I am facing some frustrating behavior, already spent many hours trying to figure it out, but no luck.
Maybe you could assist me. In my previous posts I mentioned that I have been working on TestStand Actor.

Current setup:
TestStand API wrapped in Messenger Library. It is calling Steps that also use Messenger Library to send messages (through TCP) to other actors
that control hardware.

TestStand Actor and LabVIEW steps share the same application instance. Hence, I am getting a conflicts/errors when trying to run sequences.
The same steps work perfectly from normal TestStand provided by NI.

I am looking for a way to isolate LabVIEW steps code from the TestStand Actor. It can be accomplished by putting all the dependencies in "lvlib" or "lvlibp". This way Messenger Library
in custom steps will have a separate namespace. However when putting Messenger Library in "lvlib" or "lvlibp", my steps can no longer receive TCP replies. Only "Send Message"
without a reply address work (if reply address is provided the send message makes the destination address invalid) . Interestingly, the published events are received successfully.

Do you know why would "Send Message (without reply)" and "Receive Notification" work, however "Send Message (with reply)" wouldn't? (when Messenger Library is in put in .lvlib)

Thank you!

Kind regards,

Edited by Maksim Kuznetsov
Link to post

Could you explain a little more what you are doing.  I am confused that you are using TCP (something usually used for communication BETWEEN applications) and having namespace conflicts (which happen when you have multiple paths to the same-named thing on the SAME instance).

On no condition would I recommend renamespacing the library, as TCP involves flattening the messages to strings, and that uses the class names, which you are changing.  The TCP Messengers override the usually LabVIEW flattening for some common messages for reasons of performance, replacing the class names with a much-shorter format using an enum for class type.  This is why some messages will still work.  But this is strictly limited.

I had imagined, when you first brought up Teststand and TCP Messengers, that you were building a separate LabVIEW application, and that Teststand (in a separate application) connects to the first via TCP.  That could not have conflicts.

Link to post

Thank you for your reply. Indeed, I built a separate application (.exe) for TestStand. It is using the Messenger Library with TCP input messenger. Actors from other applications
connect to TestStand Actor and run sequences, subscribe for sequence finished events, etc. That part works well.

The conflict arises when the sequence file itself contains a LabVIEW step that connects to another actor (e.g. valve controller) and sends a command to it.
That step also utilises the Messenger Library, but loads it from the folder next to the sequence (to make sure it runs on systems with LabVIEW Run-Time only).
As a result I have a TestStand Actor that runs in LabVIEW Run-Time application instance, that actor loads a sequence that has steps that also run in LabVIEW Run-Time.
And that's where problem arises. Sequence can't load any Messenger Library VIs because they are already in memory (loaded by TestStand Actor).

Edited by Maksim Kuznetsov
Link to post


4 hours ago, Maksim Kuznetsov said:

but loads it from the folder next to the sequence (to make sure it runs on systems with LabVIEW Run-Time only

I don't understand this bit.   Are your "steps" source code rather than built?  

Link to post

Yes, the steps are source.

I understand that ideally steps should be built and it can be achieved by building them into "packed library". But packed library
automatically brake the communication (same as when changing the namespace of the Messenger library).

Another possibility would be to build every step into an executable, but then returning errors, setting step input data would
become more complex.

Link to post

Ah, so really your issue is about "plug in" architecture where you want to be able to drop new plugins to a folder, and there is the problem of the plugins depending on common code (Messenger Library).   I have only previously done dynamically-loaded code that is built as part of the same build as the EXE that loads them, where such issues don't come up.  You might be better to ask in another forum, as the issues you have are not Messenger-Library specific and will be common to other such plug-in designs.

Another option is to put the entire of Messenger Library in a PPL (changing namespace) but then have ALL your code use this PPL instead of VI.lib (so everything uses the same namespace).

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.

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

      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.