[LVTN] Messenger Library

[drjdpowell]

Question: is anybody using Messenger Library in a LabVIEW version before 2013?    I would like to move up from 2011.

[Thoric]

2014 upwards, including RealTime.

[bbean]

1 hour ago, Thoric said:

2014 upwards, including RealTime.

same here

[bmoyer]

Same here.  On another note, I just started working with it (in LV2017 32-bit) and I'm having an issue with building the exe.  

The source works fine but when I build I get this build error:

"A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support."

C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\drjdpowell\Messenging\Action MSG\Async Execute Core.vi

Any ideas?  I've tried to include the block diagram of this VI and my Actor VIs in the build and also tried creating a debug executable but neither worked. 

So far I've really enjoyed using the Messenger library and hope to use it in many applications (if I can get past making an exe).

 

Thanks,

Bruce

[drjdpowell]

27 minutes ago, bmoyer said:

Any ideas?

I'm working in 2017 and building EXEs, so it can't be a fundamental problem.   Have you created any custom Async Actions?  And what version of Messenger Library are you running?

[drjdpowell]

1 hour ago, bmoyer said:

Any ideas?

I just confirmed I can build in 2017, no problem.   I suggest you try uninstalling then reinstalling Messenger Library using VIPM.  And try build options like "Use Fast File Format".

[bmoyer]

1 hour ago, drjdpowell said:

I'm working in 2017 and building EXEs, so it can't be a fundamental problem.   Have you created any custom Async Actions?  And what version of Messenger Library are you running?

1.8.3.82.  I'm able to create an exe from the Messenger Library Demo 2.lvproj using Top Level.lvclass:ActorNR.vi but when I try building my program (without the steps below) I get the error.

Here's the steps I tried (to get it to build and run correctly):

1. I uninstalled and reinstalled the Messenger library in VIPM but still same error.
2. "Use Fast File Format" checked...I was able to build the exe but when I run the exe it states "LabVIEW:  Resource not found.  An error occurred loading VI 'Actor type2.lvclass: Get Dynamic Launch Shell Reference.vi'.  LabVIEW load error code 3: Could not load front panel."  Then the exe crashes.
3. Checked "Disconnect type definitions", unchecked all "Remove unused...", the exe works now!  (the culprit to step 2 was the "Modify project library file after removing unused members).

Strange build quirks/confusing settings in Build Properties was the culprit.

Thanks for your help!

Bruce

[drjdpowell]

A favour to ask: Can all you guys who use Messenger Library give me a quick review on the Tools Network?   I only have a single review (thanks "burd from berkeley"), whereas the DQMH has 15!!!

[drjdpowell]

On 12/09/2017 at 6:35 PM, bbean said:

Replacing the query with a send and wiring in the reply address worked.  I just temporarily created an asynch create VI (without dynamic dispatch to test). 

If you are updating the RemoteTCP Messenger class, can you expose (make a datamember of the class) the timeout value the Actor uses during communication to the Remote Service.vi?  It would be nice to be able to adjust this timeout if necessary.

Thanks for your help

Try this version.  See the TCP Example "Test Client with Async connection.   It will poll waiting for TestServer to start.  Also uses a Watchdog to identify when the Server shuts down.  I found and fixed another issue (Issue #6 on bitbucket), so I'd like you to test it before I put this in the CR.

drjdpowell_lib_messenging-1.9.1.88.vip

[bbean]

Try this version.  See the TCP Example "Test Client with Async connection.   It will poll waiting for TestServer to start.  Also uses a Watchdog to identify when the Server shuts down.  I found and fixed another issue (Issue #6 on bitbucket), so I'd like you to test it before I put this in the CR.

drjdpowell_lib_messenging-1.9.1.88.vip

I tried a quick test of the new build only traversing the local host from client to server and it worked well.  I will try a more extensive test across a local network tomorrow.   I need to update VIPM to 2017 on all the machines to get the package installed.

 The ping feature of the example is nice because previously when I set up a test with only server-->client messages, if you pulled the network cable the TCP actor on the client side wouldn't timeout or error so you didn't know something was wrong.  Quick question, is there a reason you decided not to implement the ping and "keep alive" features as an option in the TCP actor itself.  Were you worried it would interfere with overall throughput from the TCP Actor's callers? 

[drjdpowell]

Quick question, is there a reason you decided not to implement the ping and "keep alive" features as an option in the TCP actor itself.  Were you worried it would interfere with overall throughput from the TCP Actor's callers? 

The honest answer is that the work projects I have don’t use network communication, and so I haven’t had the time to add features.   Although I do want to keep things simple.   I think people are too quick to try and build complexity into the “middle layers” of communication (and too quick to work against TCP, rather than with it).  Ultimately, the Application layer needs to be able to address unreliable communication, as only it knows what a communication interruption requires.   

My plans for further development of the TCP Messengers involves adding the ability to register with RemoteTCPMessenger for TCP-related notifications, in particular a “Disconnected” event.  The server side would have notification like “Number of Clients Connected”.   I could build a “ping” system into that, with notifications if the ping time increased beyond some threshold.  Then the Application can be informed of any problems, and choose to act on this.   

However, if you really need reliability, you need to implement it at the Application level.   Just because a message has been successfully delivered does not mean it has been handled correctly.  Only a Reply message saying “Job done, results saved to database” tells you your message was handled.

[bbean]

9 hours ago, drjdpowell said:

The honest answer is that the work projects I have don’t use network communication, and so I haven’t had the time to add features.   Although I do want to keep things simple.   I think people are too quick to try and build complexity into the “middle layers” of communication (and too quick to work against TCP, rather than with it).  Ultimately, the Application layer needs to be able to address unreliable communication, as only it knows what a communication interruption requires.   

My plans for further development of the TCP Messengers involves adding the ability to register with RemoteTCPMessenger for TCP-related notifications, in particular a “Disconnected” event.  The server side would have notification like “Number of Clients Connected”.   I could build a “ping” system into that, with notifications if the ping time increased beyond some threshold.  Then the Application can be informed of any problems, and choose to act on this.   

However, if you really need reliability, you need to implement it at the Application level.   Just because a message has been successfully delivered does not mean it has been handled correctly.  Only a Reply message saying “Job done, results saved to database” tells you your message was handled.

Ok makes sense..

I had some more time to test today.  I tested the following and they seemed to work:

TestClient with Async connection.vi (LV2014)--->LAN--->TestServer.vi (LV2014)

TestClient with Async connection.vi (LV2014)--->LAN--->TestServer.vi (LV2016)

TestClient with Async connection.vi (LV2016)--->LAN--->TestServer.vi (LV2014)

 

One potential "bug" in the package.  When I click "Show Example" button in VIPM.  It opens the following path:

...\examples\drjdpowell\Messenging\TCP Example

instead of what I imagine the intent is to open:

\examples\drjdpowell\Messenging

Also when I search for Messenger examples from the LabVIEW help window, the Messenger keyword doesn't appear anymore and I can't locate the examples from LabVIEW help.

Thanks for all your help!

[bbean]

Question regarding the Notify (state).vi in the Observer Register Palette.  Underneath the hood, the code looks like its sending a message every call (vs only when the data changes).  Is that correct?

 

[drjdpowell]

Yes.   I changed that (in Dec, 2014, I see).  I found it caused problems in some cases, where I would send a message to change a state value, the change would be rejected, but no message would come back to reset the control (this is the Controller-Model-View technique).  

[drjdpowell]

FYI: the Issue Tracker for Messenger Library is on Bitbucket.  Users are welcome to comment. 

[ensegre]

Discovered, studying it, impressed by its quality and comprehensiveness.

Just a really really minor thing which irks me - "varient" misspelled in a couple of places.

[ensegre]

I'm evaluating the library for a project of mine, starting from minimal applications. I'm testing on LV17, one windows and two linux machines. My beginnings are fine on windows and on one of the two linuxes, while on the second one they boil down to errors like:

Quote

Error 63 occurred at TCP Open Connection in TCP Client Actor.lvclass:Actor.vi:6640001->Dynamic Launch Shell.vi:5450003->Dynamic Launch Shell.vi.ACBRProxyCaller.C830000B

Possible reason(s):

LabVIEW:  Serial port receive buffer overflow.
=========================
LabVIEW:  The network connection was refused by the server.

which I get from Test Client.vi from the couple in <LV>/examples/drjdpowell/Messenging/TCP example/. On linux I'm with v1.8.3.82, limited by vipm2014. I suspect a simple network configuration difference, but I'm still too lost in the bowels of the library to attempt debugging. Any hint?

[bbean]

10 minutes ago, ensegre said:

I'm evaluating the library for a project of mine, starting from minimal applications. I'm testing on LV17, one windows and two linux machines. My beginnings are fine on windows and on one of the two linuxes, while on the second one they boil down to errors like:

which I get from Test Client.vi from the couple in <LV>/examples/drjdpowell/Messenging/TCP example/. On linux I'm with v1.8.3.82, limited by vipm2014. I suspect a simple network configuration difference, but I'm still too lost in the bowels of the library to attempt debugging. Any hint?

Sounds like a firewall issue.  One side may be blocking the connection attempt.  Not sure about linux, but a recent windows update made the firewalls a little more strict and caused similar problems for me.

[ensegre]

I was about to write: but at least the NI TCP examples work for me, perhaps they use specific open ports? So it turns out I was reaching these examples out of their <LV>/examples/ location, not out of the Example Finder, because "NI Service Locator is not running". That link doesn't talk about linux, nevertheless put me on the track to (re?)install nisvcloc from the rpm. Suddenly my Messenging stuff works on this machine too, weird...

[drjdpowell]

1 hour ago, ensegre said:

I was about to write: but at least the NI TCP examples work for me, perhaps they use specific open ports? So it turns out I was reaching these examples out of their <LV>/examples/ location, not out of the Example Finder, because "NI Service Locator is not running". That link doesn't talk about linux, nevertheless put me on the track to (re?)install nisvcloc from the rpm. Suddenly my Messenging stuff works on this machine too, weird...

The Messenger Library TCP stuff uses service names (and thus requires the Service Locator).  Let me know if you need to specify ports instead and I could add that as an option.

[ensegre]

8 hours ago, drjdpowell said:

The Messenger Library TCP stuff uses service names (and thus requires the Service Locator).  Let me know if you need to specify ports instead and I could add that as an option.

Ah, that makes sense, thanks. As for me I don't have yet an use case for a numeric port; maybe others do.

[burd]

On 9/13/2017 at 10:12 AM, drjdpowell said:

I just confirmed I can build in 2017, no problem.   I suggest you try uninstalling then reinstalling Messenger Library using VIPM.  And try build options like "Use Fast File Format".

Hello Dr Powell,

I would like to thank you again for this great library. I use it in all my projects and I am very happy with the flexibility it brings to my work.

There are 2 weird small problems, though not really critical, that I found in the most recent version the Messenger Library:

Problem 1:

If you create a metronome Actor, the only way to shut it down is by sending a message Macro:Exit

If I send a message Shutdown to this Metronome, it won't shut down. This has been happening since version 1.8.3.82 (I started using this version).

Problem 2:

I am currently working in a project that uses the messenger library  1.8.3.82 then I did an upgrade for the messenger library to the version 1.9.2.90. After the upgrade (In Labview 2017), the project opens without any problem (no broken arrows). However, when I execute the main VI, none of the LAUNCH ACTOR work properly; There is a message saying to open the actor and see if the vi is able to execute but all the actors are fine, even the main actor (no broken arrows) . The only way to make it work again after the upgrade is by saving the main Actor (which does not need to be Re-entrant) as re-entrant and changing the the vi properties to shared clone in the VI Properties menu. After that everything works the same as 1.8.3.82

I hope these information help to improve the Messenger Library

Thank you!

 

mass compile errors.docx

Edited January 4, 2018 by burd

[drjdpowell]

If I send a message Shutdown to this Metronome, it won't shut down. This has been happening since version 1.8.3.82 (I started using this version).

Did you send "Shutdown Actor"?   I don't use "Shutdown" as a command anymore, because it is sometimes used as a notification that something has shutdown.   "Macro: exit", BTW, come from the JKI Statemachine that I used to use as an actor message handler.

[drjdpowell]

21 hours ago, burd said:

Problem 2:

This is Issue #9.  Unfortunately it's a "pick your poison" situation as to which undesirable situation to have, a bug that sometimes locks libraries or having ActorNR non-reentrant actors fail to launch subactors.  I am unsure what to choose.  Either way is annoying.

A workaround is either to have the Top-Level actor be reentrant (as you found), or (assuming you don't need it to be "launched") just rename the VI so it is no longer part of the "Actor.vi" set of Dynamic Dispatch methods (the fact that the non-reentrant ActorNR can theoretically recursively "launch" itself is the thing that LabVIEW is chocking on).  

[burd]

10 hours ago, drjdpowell said:

Did you send "Shutdown Actor"?   I don't use "Shutdown" as a command anymore, because it is sometimes used as a notification that something has shutdown.   "Macro: exit", BTW, come from the JKI Statemachine that I used to use as an actor message handler.

I got very confused because the VI Help for the Metronome Actor says that this actor accepts the Shutdown message (if I remember right)  and not Shutdown Actor message as you said. It is necessary to update this help menu if that is the case. For  creating help for vis, I usually use the VIHELPKS that I recommend for that, as it automates the boring process of creating help files.

Thanks for the information

Also that you for helping with the Issue#9, It is fine just to have the topmost actor as Re-entrant, if it is the only way to make everything work, though it is annoying indeed!