monzue

Looking at the orleans framework actually brought me to ask this question, because I couldn't tell if that framework supported a Messaging queue, or if there was any way to determine the number of messages in the queue.

Hi James, I was trying to code a project in C#, and I was looking for a C# library that would be similar to what you have here. Do you know of any? Is there a library that is the inspiration for this messenger library? BTW, the elements in queue upgrade works great for me. Ben

Awesome!! Number of elements in the queue is all that I have ever used. Ben

James, I am your #1 fan!! I noticed recently all the improvements you have made under the hood in the ObserverRegistry... I have a request for you. Will you include a vi in the queue messenger library that is simply queue status? I've made this vi a time or two, to see if a actor gets behind, the problem is that when I switch to a different computer, or update the Messenger library from the repository, this QueueStatus vi is lost...... Ben

Hey drjdpowell, Now when I think of this the Messenger Library, I think of it as specifically a framework for passing messages(a design pattern) to asynchronously running code(Actors), and I think of things like ZeroMQ and WAMP. This link to WAMP has diagrams that sorta show a portion of the Messenger Library operation: http://wamp.ws/why/ Also some zeroMQ info. http://zeromq.org/docs:the-ten-minute-talk What about a name like EMQueue (Event Messaging Queue) also, I pm'd.

This is a good question, and I would be interested in if when using the External Display in IMAQ, if that vi uses the Graphics card at all to help display the Images.

Interesting! I just ran into this. I was calling a vi Dynamically and I wanted to check to see if it was running before I called it. I thought I could just use Exec.State property, but that returns running, even if the SubVI is just loaded in memory and waiting to run. I'm searching for an easy way to tell if a VI is actually Running. If I cant find something soon, I'll probably just have to write code to track when the dynamically called VI starts or exits.

Perhaps OP lives in North Korea, and has been "tasked" with this project.

Yes, I like the way that this is flexible for any control, but my Multiple Actors individually need different control events. Polling is ok for me, because usually in the Proccess actors, the process is started on a timed basis, or is freerunning in a loop as fast as it can go. In these cases, I just want the latest or close to latest desired variable from the UI as parameters in the process math.

I understand that this can easily introduce race conditions. However, in my case where I used the DVR (as essentially a FGV by reference) , I only desired to have access to a recent image for viewing. I understand that this DVR method would not work effectively if I was trying to capture every single frame sent over the network, or if I needed to associate a real time parameter to an exactly timed image. Why would I simply not use the In-Place Structures? I have a Main UI actor that has subpanels, menus, right-click menus on the subpanels as well as the controls inside the subpanels. For charting, I mainly have Simple Vi's that only process and display a chart information. For example, the Main UI actor will get a Chart1 data message and this variant will be directly passed into a simple Charting vi that executes once and Updates the Chart control on the Front Panel, which is user selectable to be placed into a subpanel on the Main UI. So basicly I didn't see the point in making the simple VI another actor. However, I do also have other pop up windows that are actors in themselves that are launched by the Main UI. My Main problem is communicating the UI Variable information to the select locations / actors in the code where the processing happens. Currently, I am doing a mix of event messages, and DVR UI Variables that are polled by the processor when the select variable is needed. The thing is, I seem to be having to pass the DVR UI Variable Reference to almost every Actor, and I don't think that I should be doing that. Anyways, I am going to think on how my UI is laid out, and I am going to describe it more in this thread: http://lavag.org/topic/15438-re-designing-multi-instrument-multi-ui-executable/ I'll continue to comment on UI layout and communication with controls there to save this thread from going off topic too much.

drjdpowell, using your messaging framework, My main reasoning was using a DVR requires less code work to recieve the data in the Actors and there are no memory copies(granted, most UI settings are not very memory intensive): When not Using a DVR: -- one has to make sure that every actor recieves an update when the UI actor has a user change something. - This could be done easily enough with writing the variable to the Notify Observers (Event) in your messaging framework and having all actors that need to be updated register for this event. Then each Actor should contain the UI-Settings class stored in a shift register that is the same as the one in the UI actor. And as events happen, the UI-Settings class is updated with the new values. NOW, here is something that Gets me also....... Some of my actors have a communication loop AND a processing loop that Runs as fast as it can. Now i have to not only pass my UI-settings to the Communication loop, but also to the Processing Loop. So In this case, I am passing the UI-Settings between the two loops on the vi via Notifier, and the Notifier updates every time the Communication loop gets an update. Much like what you have in the Metronome Class. -- If Using a DVR, then the Reference is passed once, and every time a Process actor needs a parameter from the UI, it simply pulls the Correct value from the DVR. I am sure you may loose some encapsulation here, but the gain in coding speed from not having to register for all the events and no memory copies may be worth it? Granted if the UI-Settings needed to be shared over a network, the way to go would be not using a DVR. I started thinking about DVR's because i just used one in my code. Consider This Case: The User launched a TCP Client Actor from a setting on the UI. This TCP Actor was constantly fed an image. The way I handled this, was I created an Image DVR and put it in the class that launched the Actor. So i fed the Image DVR around to every Actor that needed it and as the TCP Actor Updated the Image, it was accessible everywhere very conveniently.

WOW, I had no idea that you could hook the DVR directly up to the Property node. Thanks for showing this here. I am trying to think of a good way to pass UI settings (i.e. On/Off switch states or User location) down to Data Processor Actors. I think I'll just create a UI-Real Time Variable Class, make a DVR then Send a Message to the Actors with the DVR. Then any Actor Process that needs these Real time Updateable Values set by a User can pull what it needs directly from the DVR. This method would be instead of Messaging each Actor with the new Value every time that the UI had a setting Change. Any Thoughts on this? Does this seem exactly what I should do? Should I just Use a <gasp> Global?

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.

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.

Nice! It looks like I'm on the right track. Thanks for all the comments, and here's to waiting for the new version: