Jump to content

Recommended Posts

That's a standard technique I use all the time to prevent unwanted code coupling.  In fact I almost always do it if I have reason to pass the address of an actor.  I use either "Send" or "Actor" parent classes; there is no reason to use "Actor type 2".  With the Send class (the grandparent of all address classes) one also has the option of passing a TCP Messenger, allowing you to run C or D on a different machine.

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

Note: I am considering uping Messenger Library's base LabVIEW version from 2013 to 2017.  This is to allow use adding actor templates that use JSONtext to do configuration, and to add VIMs to the palettes.  None of my clients use LabVIEW earlier than 2017.   Let me know if you use Messenger Library with LabVIEW earlier than 2017sp1 (sp1 fixed VIM bugs).

  • Like 1
Link to post
Share on other sites

Thank you for sharing your opinion on using parent classes for actor references to prevent unwanted code coupling! I will use Send class.

21 minutes ago, drjdpowell said:

Note: I am considering uping Messenger Library's base LabVIEW version from 2013 to 2017.  This is to allow use adding actor templates that use JSONtext to do configuration, and to add VIMs to the palettes.  None of my clients use LabVIEW earlier than 2017.   Let me know if you use Messenger Library with LabVIEW earlier than 2017sp1 (sp1 fixed VIM bugs).

That would be great, really looking forward to these changes.
____________________________________________________________________

If I ask too many question, please tell me! But I have another one. I use TCP messengers quite often to send messages and subscribe. That works perfect!
However today I tried to send a local queue in a message for the receiver to reply when asynchronous action is finished:

Untitled.png.72f250eb97d01d620d7b1344f2ad6048.png

The problem here is that I shared messenger references between 2 application instances which is not allowed.
This approach works in the same application instance.

I was wondering, is there a way to make the code above work across multiple application instances? I tried to create a TCP server instead of the
"action result" queue, but that doesn't seem to work.

Link to post
Share on other sites

This is basically this issue: https://bitbucket.org/drjdpowell/messenger-library/issues/32/clearer-way-to-pass-addresses-as-data-over

Addresses are all based on communication methods, such as a Queue, that don't work across application boundaries.   The TCP messengers get around this by replacing Reply addresses on messages with a special address that routes the reply back though the TCP connection.  So all the local-only communication methods will work remotely, but only for addresses passed as Reply addresses.  In your example, you are passing the address as data, not as the reply address.  Rather than Query, use Send, with your Queue as Reply address.  Use "read reply address" at the other end to get the address (actually now a "Route Back" address) and send your two messages to it.

  • Thanks 1
Link to post
Share on other sites
9 hours ago, drjdpowell said:

Note: I am considering uping Messenger Library's base LabVIEW version from 2013 to 2017.  This is to allow use adding actor templates that use JSONtext to do configuration, and to add VIMs to the palettes.  None of my clients use LabVIEW earlier than 2017.   Let me know if you use Messenger Library with LabVIEW earlier than 2017sp1 (sp1 fixed VIM bugs).

2017SP1 is fine for me. We have a generic configuration actor that uses JSON. Will be interested to compare your approach, if you include one in the toolkit.

Link to post
Share on other sites
  • 2 weeks later...
23 hours ago, Maksim Kuznetsov said:

Are you planning to return the "attachment" feature for the outer-envelope?
I remember using it for some time, but after installing the latest messenger library it seems to be gone.

It's badly documented, but it appears to be there for me, but in the "UseOuterEnvelopeLabel" vi (see below).  This is because that is where I envision it being useful, with a requestor attaching something to the reply. 

But you may be using the "Add Attachment" vi, directly.  This is still on disk, just not in the palettes.  I will add it back into the palettes (issue 5).

UseOuterEnvelopeLabel.png.70fa6b311e2294970113dacbcfc6442c.png

  • Like 1
Link to post
Share on other sites

 

On 8/26/2020 at 3:54 PM, Maksim Kuznetsov said:

Are you planning to return the "attachment" feature for the outer-envelope?

Can you show me how you use "Add Attachment"?  It's tricky to document its use, as I only use it as part of "Use Outer Envelope", and also because "Object Message" does double duty as "Outer Envelope" (as a Message is an object, then Object Message, when containing another Message, is acting like an outer envelope about that inner message).

Link to post
Share on other sites

My problem with the "Attachment" feature is that is difficult to come up with an intuitive API.  Just look quick example using a couple of Future Tokens to do one request-reply, with attached info.  Way too complicated, with four bits of info in the reply message (envelope label, attachment, inner message label, and inner message data).  This needs simplifying to be more than a niche feature.

1557895047_EnvelopewithAttachment2.png.6083d41ad3956dda79e851a3800a98ac.png

Link to post
Share on other sites
On 8/27/2020 at 5:28 PM, drjdpowell said:

Can you show me how you use "Add Attachment"?  It's tricky to document its use, as I only use it as part of "Use Outer Envelope", and also because "Object Message" does double duty as "Outer Envelope" (as a Message is an object, then Object Message, when containing another Message, is acting like an outer envelope about that inner message).

I have an OPC actor to which I can subscribe for channel data change events. Channels are strings. However after some time I realised that using strings was not that convenient, especially if one of the channel names changes. So, I decided to create an enum of all OPC channels and subscribed in the following way:

Subscription.PNG.7f50bd8080abe62ba1015f36eac9c247.PNG

This approach allowed me to leave the OPC actor unchanged. Then this is how I handle the events:

Handling.PNG.3f24fdd48bcb680df4b1d661821cb5e4.PNG

Now if need to change the OPC channel name, I can just change it in the typedef without touching anything else. Also writing/reading channels (separate messages supported by OPC actor) is convenient using an enum converted to string.

Edited by Maksim Kuznetsov
Link to post
Share on other sites
  • 1 month later...

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: https://forums.ni.com/t5/JDP-Science-Tools/New-Beta-feature-Reconnecting-TCP-Messenger/gpm-p/4092514#M5

Here's the image.  The idea is to have a persistent TCP Client connection that will try and reestablish itself if broken. 

822534739_2020-10-2015_09_33-ContextHelp.png.78975dd0f0582c0ec0d28bfff9305aaf.png

  • Thanks 2
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.