Jump to content

Recommended Posts

  • Replies 285
  • 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

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

One possible option with a bad hardware driver is to make your actor an independent exe, using the NetworkMessenger for communication  Then you can kill the entire exe and restart cleanly.  I've never

Posted Images

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 post
Share on other sites
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?

Link to post
Share on other sites
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".

Link to post
Share on other sites
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 post
Share on other sites
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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites
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 post
Share on other sites

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?

notify state change.png 

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 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 post
Share on other sites
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 post
Share on other sites

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 post
Share on other sites
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 post
Share on other sites
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 post
Share on other sites
  • 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 post
Share on other sites

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 post
Share on other sites
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 post
Share on other sites
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 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***
      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.