Jump to content
drjdpowell

[LVTN] Messenger Library

Recommended Posts

19 hours ago, Maksim Kuznetsov said:

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).

BTW, I'm no expert in such plugins, but this statement seems very wrong to me.  Your plugins should find common dependencies in the EXE that is loading them, not making new copies.

Share this post


Link to post
Share on other sites
5 hours ago, drjdpowell said:

BTW, I'm no expert in such plugins, but this statement seems very wrong to me.  Your plugins should find common dependencies in the EXE that is loading them, not making new copies.

Yes, you have a very good point here. Usually I follow this approach. However, TestStand Actor is allowed to load any sequence file through TestStand API.
The sequence file itself sometimes calls LabVIEW code, which in my case by a coincidence use the same library that is already loaded by a Run-Time engine.
For the sequence developer it is impossible to know that his steps will have a conflict in memory once deployed.

Thank you for a suggestion about putting Actors and Messenger library under the library. It sounds like a potential solution, I will give it a go.

Share this post


Link to post
Share on other sites
On 12/17/2019 at 1:48 PM, drjdpowell said:

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).

Unfortunately that didn't work.
The same behavior appears as described in the initial post: "Send Message (without reply)" and "Receive Notification" work, however "Send Message (with reply)" doesn't.

What I did was I created an .exe actor which receives and replies with a text message. Then I created a client actor that sends a message and waits for a reply.
Source and Build for the client work perfectly.

Then for a client actor I created a source distribution and included all dependencies in a library (that included Messenger Library).
I also tried putting the client actor itself into a library, but still with no luck.

Share this post


Link to post
Share on other sites
1 hour ago, Maksim Kuznetsov said:

Then for a client actor I created a source distribution and included all dependencies in a library (that included Messenger Library).

But that wasn't the idea.  Your plugins can't pull in different copies of common dependancies; they must use the copy in the exe, be that source or a ppl.  You need to consult someone who is an expert in plugins.

Share this post


Link to post
Share on other sites

I believe there is a misunderstanding and I am failing to explain correctly the issue that I am facing. Let me please try once again,
if you still have patience. I prepared the following diagram:

image.png.513fcef830c7520d3514da746c73d24a.png

1. TestStand Actor.exe is launched in LabVIEW Run-Time Server, hence the Messenger Library VIs will be loaded into memory.

2. TestStand Actor.exe runs the sequence file (with any kind of steps) using TestStand API.

3. Sequence File has some LabVIEW steps that are using Messenger Library VIs. LabVIEW Adapter in TestStand automatically
uses the same LabVIEW Run-Time Engine Server as in step 1. Hence there will be a name conflict.

Ideally I would build all of the LabVIEW steps into a packed library (as advised by NI). Doing that provides a namespace + puts all the
dependencies into one file. However, this brakes communication in Messenger Library and steps become useless.

Running steps without library produces a naming conflict in LabVIEW Run-Time Server.

Share this post


Link to post
Share on other sites

Hi everybody. After couple of more days of thinking and trying, I managed to narrow down
the issue to a very simple experiment. Making it work will solve the problem I've been facing for many days.

Experiment setup:

1. Create a simple Actor with a TCPEventMessenger (server). Make it reply with some text to the incoming message.
2. Create another Actor that connects to the actor from step 1 (through TCP). Make it send a message (with reply).
3. Add actor from step 2 to project library.
3. Test both actors in development environment, they should communicate perfectly.
4. Create a packed library build specification for project library from step 3.
5. Now open the actor from the freshly built .lvlibp and try to run it. It should fail with a timeout error while waiting for a reply.

This behavior doesn't make sense to me. Because when instead of building packed library I build an executable everything works
perfectly. Why can't I build a packed library and make it work the same way.

P.S. Packed library includes every dependency, same way as in executable.

Any advice will be highly appreciated! Thank you in advance and happy new year!

Kind Regards,
Max

Share this post


Link to post
Share on other sites

Here is a link I found that I think might be the same issue, though with a Global Variable as the communication method between components: https://forums.ni.com/t5/LabVIEW/How-to-access-common-global-variable-between-different-Packed/td-p/3324410?profile.language=en

There, as I suggested above, the solution was to put the common dependancy in a common ppl, that all communicating components used.  

Share this post


Link to post
Share on other sites

Thank you for the link. But, the problem appear even if I just have a single Actor that uses dependencies from ppl.
Basically as soon as "Messenger Library" is put in ppl or a library the TCP Messenger brakes (I can send message without reply, but I can't receive replies).

Apparently PPL also creates a namespace for everything that is inside and that brings us back to your reply:

On 12/16/2019 at 6:16 PM, drjdpowell said:

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.

Is there any easy fix that I can apply to make Messenger Library work from ppl and library?

Kind Regards.
Maksims

Share this post


Link to post
Share on other sites
On 12/19/2019 at 12:39 PM, Maksim Kuznetsov said:

Unfortunately that didn't work.
The same behavior appears as described in the initial post: "Send Message (without reply)" and "Receive Notification" work, however "Send Message (with reply)" doesn't.

What I did was I created an .exe actor which receives and replies with a text message. Then I created a client actor that sends a message and waits for a reply.
Source and Build for the client work perfectly.

Then for a client actor I created a source distribution and included all dependencies in a library (that included Messenger Library).
I also tried putting the client actor itself into a library, but still with no luck.

I think there is a misunderstanding somewhere as what you describe here is almost the opposite of what I suggested here:

On 12/19/2019 at 12:39 PM, Maksim Kuznetsov said:

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).

 

Share this post


Link to post
Share on other sites

To eliminate the misunderstanding. I have 2 applications:

  • One is a built executable, uses messenger library as is from VI package manager.
  • Second is a ppl with one actor inside (possible on a completely different PC).

I can't make these 2 applications communicate through a TCP messenger.

I understand that PPL changes the namespace of all classes. Hence when flattening/unflattening messenger addresses
the namespace is included. That is why communication doesn't work.

To solve this I think I need to somehow remove the namespace when flattening
and then add it when unflattening (in actor that runs from PPL).

What do you think?

Share this post


Link to post
Share on other sites

I think you should put Messenger Library in a ppl and have all your other code use that ppl.  Then everyone is using the same namespace.  Why have you not done that?  

Share this post


Link to post
Share on other sites

You've just told me the equivalent of: I want two people to talk to each other, but each use a private language that no other person can understand.  

  • Haha 1

Share this post


Link to post
Share on other sites

It is a good analogy. It is unfortunate that changing namespace affects the class names and hence brakes the communication.
However for my particular task it is essential. I will try to remove the namespace from flattened address and see what happens.

Thank you for all of your assistance and support. I highly appreciate it.

Share this post


Link to post
Share on other sites
14 minutes ago, Maksim Kuznetsov said:

However for my particular task it is essential.

Why?

Share this post


Link to post
Share on other sites
11 hours ago, Maksim Kuznetsov said:

To eliminate the misunderstanding. I have 2 applications:

  • One is a built executable, uses messenger library as is from VI package manager.
  • Second is a ppl with one actor inside (possible on a completely different PC).

I can't make these 2 applications communicate through a TCP messenger.

I understand that PPL changes the namespace of all classes. Hence when flattening/unflattening messenger addresses
the namespace is included. That is why communication doesn't work.

To solve this I think I need to somehow remove the namespace when flattening
and then add it when unflattening (in actor that runs from PPL).

What do you think?

Here's a couple of diagrams.  You seem to be doing this:

V1.png.7cc01ca9642a4f7bc6515207f60373d5.png

Where the privately-namespaced copy of Messenger Library in your ppl cannot communicate.   But I'm suggesting this:

V2.png.0304cc03dcbe3f7b593144480073587a.png

Where every component uses a common ppl.

  • Thanks 1

Share this post


Link to post
Share on other sites

Yes, Dr Powell, this is exactly what I was trying to do. Thank you for diagrams. I also realised it is not possible and shouldn't be possible based on this discussion:
https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-type-casting-between-classes-types-in-PPLs-lvlibp-s-or/idi-p/3136231?profile.language=en

Why it was necessary?

Due to how TestStand Interacts with LabVIEW application instances:
http://www.ni.com/product-documentation/14335/en/

TestStand steps tend to use the same application instance as LabVIEW executable (based on Messenger Library),
this is why steps that used Messenger Library from another location didn't work. I wanted
steps to be easily distributable, so had to keep dependencies (including Messenger Library) next to them.

NI suggests to keep LabVIEW steps in PPL, that didn't work for me because it changed the namespace of the library.
However, as you suggested, also changing namespace of the actor I communicate to, worked!

So now I have two PPLs with exactly same names, but with different contents. One with actor, second with steps. Additionally,
to make TestStand use a different application instance I specified a project path for each step (it forces it to use another application instance).
Then I continued my experiments and included steps directly into the Actor PPL and it also worked perfectly without having multiple
PPLs. Just one Actor PPL, that has API VIs that are called from TestStand.

So far so good, it works well. Thank you very much! It is a relief and I learnt valuable things.

P.S. Sharing PPL Messenger Library should also work, it will involve a little bit of extra work.

Share this post


Link to post
Share on other sites

I am now thinking of creating PPL for a Messenger Library, that is the best solution. I remember 2 years ago you suggested:

On 1/25/2018 at 8:26 PM, drjdpowell said:

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.

Creating a PPL and relinking VIs in existing actors to that PPL should work. However how would you approach creating the PPL that will also appear in
LabVIEW palette for development (as it is now with Messenger Library)? I would like to distribute PPL to developers seamlessly without having them to dig
into the PPL and look for particular VIs.

Share this post


Link to post
Share on other sites

Sadly, I still have no experience with PPLs, and you'll have to ask someone else.  I have no idea about palettes.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 9/13/2019 at 3:24 PM, drjdpowell said:

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:

2146204797_FixReferenceLeak.png.3fb51efbe10eae86af6c78643cb176a8.png

Just a warning: this bug is the prime suspect in an application failing after 55 days continuous use.  LabVIEW has a limit of one million Queues alive at any time, after which "Obtain Queue" throws an Error 2: out of memory.  This happens after 55 days if one actor shuts down (without its Caller shutting down) every 5 or so seconds.  Unfortunately the application was built two days before this bug was reported.  Please upgrade to the latest Messenger Library version.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 1/21/2020 at 11:51 AM, drjdpowell said:

Please upgrade to the latest Messenger Library version.

Is the latest version 1.10.9.115? Is there another higher version somewhere because that one seems to still have the issue.

Share this post


Link to post
Share on other sites
2 hours ago, bbean said:

Is the latest version 1.10.9.115? Is there another higher version somewhere because that one seems to still have the issue.

Sorry, I've been lax in updating the Tools Network and the LAVA-CR.  I have updated the LAVA CR to the 1.11.1 version.

Share this post


Link to post
Share on other sites

Basic question: I've written actor templates with config and plugin features. Using those to write soundcard in and out actors. They have helper loops that use 'register' and 'notify' to transmit the waveforms around.

A standard labview notifier is set by the messaging loop to shut down the helper loop. How do you shut down your helper loops - is there a 'messenger library' feature you use?

When using queues I used to close the queue in the main loop and detect queue errors in the helper loops.

Share this post


Link to post
Share on other sites

I don't use any messenger-library-specific way.  Usually I kill a reference like a notifier, but lately I have been using the new "channels" feature, which have a "last value" shutdown Boolean.  So far, channels have produced cleaner code.

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.


  • 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***
      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
×
×
  • Create New...

Important Information

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