Jump to content

Recommended Posts

James,

This may have been answered before, so forgive me if it has.

The actor model you use ensures sequential execution of the Event Structure and State Machine. This means the state machine can complete its task(s) without interference from the event structure, because the event structure literally cannot react to any incoming messages until the state machine completes its stack and yields execution.

But what if you have a case where this is unhelpful? For example, consider that the state machine is in the middle of a series of state changes, controlling hardware and taking measurements, when an Emergency Stop message comes in. I would want the emergency stop message to be received and reacted upon immediately, with the event structure being able to inform the state machine that it needs to take into account this emergency stop state, change its task list (stack) and instead put hardware in a safe state with immediate effect.

Currently I don't see a way to do that without the state machine yielding to the event structure at regular intervals (every 100ms for example), which requires some uncomfortable coding styles. I could, for example, let the state machine yield to the event structure with a status flag set in the shift register that the Timeout Case uses to recognise a need to return to the state machine. This would give the event structure a chance to look at incoming messages and react. But what if a benign message comes in that would normally be held back until after the state machine was finished? Suddenly it gets processed and dealt with too soon. This is why it's important not to yield to the event structure before the state machine is ready to process new requests.

Alternatively I somehow use a notification style message within the state machine itself, enabling the possibility of checking an Emergency State notification at regular intervals within the state machine, preventing the need to yield to the event structure. But this notifier would have to be populated from outside the actor, because the event structure is not free to create the notification. This means we now have external source able to directly influence a privately scoped state machine, bypassing the controlling event structure and defeating the primary principle of the actor's stacked structure. Or do we let this fly because we're just using it for emergency notifiers?

Your counsel is greatly sought, my friend.

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

For anyone using this package, I’ve uploaded the latest version (should really have updated this more than once a year).  I’d like comment on the following new features: This is one of three asynch

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

Posted Images

I few other methods for you to consider:

1) a separate "helper loop": in this, the main loop of the template is a "manager", with a separate loop inside the actor doing the work.  The "worker" can be controlled by non-actorish ways (such as an Abort Notifier) by the Manager, which is always capable of handling new messages coming in.  This encapsulates the non-actor communication, keeping it local (and understandable).  I likely addition to this is a "job queue", to hold the list of actions that the manager queues up for the worker.  Here is where one can have job priority, or cancelable jobs.  Note that this is different from the "action stack" (what you called a "state machine").   These are different things that are too often combined.

2) Have a "Sequence actor" that does the long actions, which can't itself be aborted, but which acts on hardware via short-to-execute synchronous Request-Reply messages to separate hardware actors.  Send the "abort" messages to the hardware actors, putting them into a safe-mode state where they reply to action requests with errors.  The first such error message causes the "Sequence actor" to end it's sequence (using standard error-chaining logic).   Note that if your stop really is an emergency then this bypassing of your complex higher-level logic to talk directly to low-level hardware actors is actually a lot safer and more easily testable.

3) An asynchronous version of (2), where the "Sequence actor" uses Async Request-Reply for interaction with the Hardware actors.  Less flexible than (2), but more properly actorish, in that the Sequence actor is always able to handle messages.

I actually don't mind your abort notifier triggered from outside the actor.  This is, as you say, bending the rules for a limited and clear purpose, and for the special case of aborting.

 

Unfortunately, though, you're dealing with the problem of "state" (true "state", not the actions of a so-called "QSM") and that isn't ever easy.  

  • Like 1
Link to post
Share on other sites

Interesting - these offerings are significant effort. I was hoping for something simpler, but I wonder perhaps if the use of a 'globalised' notifier is the solution I need. As you state, it's for a limited and clearly defined purpose.

I'd be interested to see suggestion 1, (the helper loop, with the main actor template becoming the manager of an internalised worker), provided as another template option from the scripting tools. 

Thanks for the advice James - professional as always!

Link to post
Share on other sites
  • 2 weeks later...

Hello James,

Since I started using the framework I started having trouble with the so called Infinite Reset of Death during shutting down of the application (executable). The cause of the problem is not the messenger library, and now there is a way to deal with this problem as explained here:

http://www.labviewcraftsmen.com/blog/not-so-infinite-reset-of-death

I used the methodology and it works very well! Now there is no more possibility for the resetting VI message that never goes away during shutting down of the application.

I hope users of the messenger framework find this useful.

 

Link to post
Share on other sites
  • 3 months later...

When updating Messenger Library from version1.8.3.82 to version 1.9.6.99, my application throws this error:

image.png.74513b9956fdf661a681b807adc0094c.png

Looking at the code I see the change that was made and comments pointing to here to explain the change:  https://labviewcoder.com/2016/07/06/quick-tip-asynchronously-launching-vis-the-right-way/

If I change Dynamic Launch Shell.vi on the block diagram back to a strictly typed VI reference, the error goes away.  What's gone wrong?  

The library has made my application development much easier, but I don't understand things well enough when an issue like this comes up.  For now my solution is to backdate the library to the previous version, but I'd like to understand what's happening.

 

Edited by dhendrix11
Link to post
Share on other sites

This is Issue 9, the trickiest problem in Messenger Library at the moment.   Can you try version 1.10.6, which is in the LAVA-CR (this has been submitted to the Tools Network and is working its way through the process.  There is no ideal solution but this is my best attempt.  Alternately, you can try renaming your Main:ActorNR to something else (assuming you don't need to launch it but are instead running it directly).

Link to post
Share on other sites

James,

Is it possible to glean information about the sender of a message? In my Actor I receive a message and it would be useful if I could learn some originator details, namely the Name of the Actor (VI Name perhaps). I wonder if it's possible to learn this info from the Reply to... indicator of a Read Reply Address call?

image.png.eb0a0b571ee6c72bc34a289594451d8e.png

A little bit of background - I want my actor to be smart enough to recognise where a message has come from. It's 'actor agnostic', except for one in particular, and if packets come from that one particular actor I want to perform additional tasks. I can't place additional information into the message itself, so I need this actor to be able to determine the source of the message automagically. Can we do that?

Link to post
Share on other sites

Does your receiving actor know the exact reply address that the special sender will use?  You can use addresses as unique identifiers with "equals".  There is a vi in the palettes that searches an array of addresses for the reply address on an incoming message.

Your design is different from ones I'm familiar with, so that may not be a good answer.

Link to post
Share on other sites

I was adding a 'quick' feature to my framework - in retrospect it wasn't the right approach so I've changed my tactic and now I have a better implementation that doesn't require this actor knowing the message origins.

I appreciate knowing now though that the addresses are directly identifiable, even if we cannot extract any information about the address from it.

Thanks James

Link to post
Share on other sites
  • 1 month later...

 

I PM'd James the following question regarding unit testing and the Messenger Library actors. He asked I repost it here so that he can answer publicly for the benefit of the community and it is documented with the rest of Messenger Library discussion.
 
Quote

Hi James, I have some thoughts/a question about the messenger library, actors, and testing. I have to create an "xcontrol" that involves an intensity chart and interlinked a histogram and I did a very quick test class with logic code right there on the actor block diagram. At the same time, I have been reading about and trying to put a foot into the door of unit testing. I found it conceptually hard to think of how to test the actor as I had written it. While working on the problem in general, I was browsing your augmented graph code. I noticed that there is zero low-level code and every "action" defers to a member vi of the graph class which encapsulates the actor data. I suppose this would be a step in the right direction to facilitate testing, because it clearly packages logic into defined methods. However, since I don't have much experience with testing, let alone for LabView, I feel at a loss trying to understand how to test these things when so many functions do things like modify cursor positions and such. That feels much more like side effects than logic. Would you might providing some insight into how you go about testing in LabVIEW, with attention to messenger library actors and classes? Thanks again for all that you do for the community.

 

Link to post
Share on other sites

I'm afraid I have no answer as how to test actual UI code, other than an actual set of tests done by a person.  That is quite a big problem.  However, I commonly do have business logic in some kind of subVI or class method, and that can be unit tested.   So for example, I can test if the "Save Data" and "Load Data" methods properly write/read the data, but I can't test if the "Save" and "Load" Menu items actually call those method correctly.  

One can, though, test the message-interaction of an actor in a Unit Test.   And one can use Queries to help do this quite easily, even if the actor, in actual use, is interacting much more asynchronously.  Below is a part of such a test of a ModbusTCP Server.  I included a diagram of the actor interactions at top (a secondary value of unit tests is that they allow one to demonstrate the use of a component in a simplified setup).  Note that I quickly made a simple message loop to stand in for the "Device", needed to handle some of the commands sent over Modbus (the actual actor that is the Device in the application is much more complicated).   

1639812413_ModbusTCPActorUnitTest.png.d52764d401f4fb4092d6e0ea00477330.png

Not shown, off the bottom of the screen, I use the Plasmionique Modbus Library as a test Modbus client to run a series of communication tests with the server.    

Note, though that this is an example of an Actor that involves no UI at all.   If it had UI elements, I could not test that automatically.

Link to post
Share on other sites
  • 3 weeks later...

Hello all - I am trying to figure out a way to use the TCP Messenger to create a PC client that can send messages to up to 52 remote cDAQs.  I used your simple TCP Client Server example to start off with and it works fine for a single cDAQ server.  The problem is that I do not want to have to launch 52 actors in my client code pointing to each of the 52 cDAQ IP addresses.  Is there a way to just send simple messages to the server without have to launch an actor or perhaps reuse an actor by programmatically pointing to the IP address I need to talk to at any given time?

Link to post
Share on other sites

I also need something that can handle situations where the cDAQ is not present or drops out and needs to be reconnected with.

I think I maybe trying to use the wrong tool for this application.  I might be better off with a topic based DDS that has inherent reconnect capability.

Link to post
Share on other sites

When you say cdaq, you mean normal cdaq or one of windows/rt cdaqs? Assuming windows/rt, maybe if you want some basic messages just set up a web service with a named queue to forward messages to. Then you don't need an actor, just call the http api directly (or spawn it as a task).

Link to post
Share on other sites

I am using cDAQ's with Linux RT but I suppose I could still use websockets, right?  In the meantime I am trying out on-the-fly creation of Messenger remote connections to my cDAQs.  It is not very fast ~50ms total transaction time per cDAQ but it might do since the command response side of things is more supervisory control of the overall system.  For status and data collection I am using RTI-DDS which is blazing fast. 

One concern I am having with Messenger is that on occasion I have seen the 50ms transaction times suddenly increase to 5000ms.  Shooting in the dark, I am wondering if it could have something to do with NI Service Locator sync between client and servers?

Anyway, it would be nice if the messenger library had the option of specifying static port numbers instead of service names.

Edited by viSci
Link to post
Share on other sites

Yeah websockets are easy, theres 12 libraries out there for setting them up using the tcp primitives.

50 ms delay could be nagle -- if its a closed network, 50 ms is at least 25 round trips, likely more.

One possibility for the long long delay is if you're using hostname rather than numeric IP address. The hostname lookup is a disaster for any networking code, at least on windows.

Link to post
Share on other sites

What about the port service name locator, could that be a problem as well?  I was planning on using RTI DDS for all network communications but the LabVIEW wrappers provided by RTI and now included in LV2018 have some shortcomings.  Things like no native support for command-reply, no events and issues with strings within a cluster that start with a numeric digit pushed me to consider Messenger...

Link to post
Share on other sites
8 hours ago, viSci said:

Things like no native support for command-reply, no events

I've never looked at rti-dds, but could you implement a "reply address" with it?  Instead of a blocking command-reply, you could do an async command-reply-continuation.  I talk about this messaging pattern in this GDevCon talk: https://youtu.be/HIuzY_Bs7BI (staring at 7:38).  

Regarding Event support, you can always write a reusable forwarding loop, which listens to an rti-dds whatever-they-call-it and posts the messages to a User Event.

I'm a believer in not cobling together different communication methods, and if I had your use case I would try and use only one package to implement it, adding capability if needed (though in my case that package would be Messenger Library, of course).

Edited by drjdpowell
Link to post
Share on other sites
15 hours ago, viSci said:

BTW, which websocket library would you recommend for command-reply use cases on a Linux RT target? 

I'm guessing shaun would say this one: https://lvs-tools.co.uk/software/websocket-api-labview-library/

But the one on vipm seems good enough to me. A lot of the others are only 1 half or the other.

Edited by smithd
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.