45 replies to this topic

[drjdpowell]

Ben, small note:
I see in one of your images that you index over your array of Instruments and individually configure an Observer to substitute a message and then register this Observer with the Metronome. You’ll have less overhead if you take the entire array of instruments, create a single Observer, configure it to substitute a message, and register it. Observers can hold any number of “Send” objects internally. To make your array into a single Observer, use what is now called “Create Observer (polymorphic)” but was then called something like “Make Observer” or “Add Observer”.



Another small note: There is a bug that is a problem for a feature that you might not be using but should know about. For Variant-type messages, one can not fill in the label and let the message use the variant data name as the label. But a bug in converting to variant sometimes doesn’t take the right name:

Edited by drjdpowell, 11 February 2012 - 12:19 PM.

[drjdpowell]

Hello,
I’m uploading the latest version of my framework, even though it isn’t polished, as I’m unlikely to have any time to polish it for months (baby on the way). It includes all the extra stuff since the last version, including the Actor Manager, and TCP-network versions of the Queue and User Event Messengers. It is in LabVIEW 2011.

— James

 Messenging.zip   2.58MB   89 downloads

[drjdpowell]

Latest version, as a VIPM package, posted to the CR.

[monzue]

hey drjdpowell!

 

So, I have downloaded your newest version of the messager library.  I really like this library, and have been starting to use it.  It has really helped me to understand the LVOOP.

 

I really like the way that the Actors are Launched using the type 2 Actor, where simply the vi with the name of Actor is called in the Class; that Dynamic Launch Shell VI with the child class implementation is simply ingenious.

 

I havent really played around with the Actor Manager much yet, I noticed that the file is missing in the VIPM distribution. That would be cool if you could add it! 

 

here is an idea for you regarding a usefull Parallel Process, you may have already thought of this, though.  I have an actor TCP Client and and actor TCP Server that simply sets up the port with either a service name or a port number, and listens/sends TCP packets as strings.  (I'm not trying to sent class messages over the TCP port.)  So any Actor that registers its observer with the TCP Client will automatically recieve the message "TCP Packet" when there are bytes available at the port. 

[drjdpowell]

Hi Ben,

The launch technique is stolen from mje’s “message pump” package.  It’s used by the Actor Framework, also.  

 

The Actor Manager installs in a different location, and should be available under the Tools menu:

Please note that the Actor Manager is badly in need of rewriting.  It’s not pretty.

 

What’s your use case for TCP?  I have TCP Messengers in the package (which use TCP actors to run the client/server) that are intended to seamlessly substitute for other messengers (handling replies and observer registrations).  At some point I will write the code to launch an actor sitting behind one of these servers.  Do you want a TCP actor to talk to external non-LabVIEW code?

 

BTW, I’m in the midst of writing a talk on this package that I’m going to present at the European CLA Summit.  Of course, this has made me relook at lots of things I did and want to change them   .  I’m going to upload a new version before that summit in April.  

 

— James

[monzue]

Do you want a TCP actor to talk to external non-LabVIEW code?

 

 

— James

 

Yes, that is correct.  I have written so many TCP servers and Clients, its not funny and I'm tired of writing them.  So, A prebuilt Server or Client that I just drop on the diagram that Executes in parallel is awesome!   And I'll just register the tcp message processing actor with the client.  or for a server, the UI or processor simply sends a message to the TCP server actor. 

 

 

Usually there seems to be two ways that data is sent over a TCP to a client. one way is the TCP string is appended with the size of the string, and the other is no size information with the TCP string, the loop simply waits for data and timeouts if no data.

 

so basically how it would work is one section of the actor will listen for connections/disconnects, and the other loop processes messages.  really very similar to your TCP messaging framework that you've written.  I will work on creating this drop in TCP server/client, i'll post it when im done... might be a little while though.