Jump to content

[LVTN] Messenger Library


Recommended Posts

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

Link to comment
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

Link to comment
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

Link to comment

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? 

Link to comment

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.

Link to comment
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!

Link to comment
  • 3 weeks later...

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?

Link to comment
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.

Link to comment

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

Link to comment
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.

Link to comment
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.

Link to comment
  • 2 months later...
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 by burd
Link to comment

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.

Link to comment
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).  

Link to comment
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!

Link to comment

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.

×
×
  • Create New...

Important Information

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