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:

Hey James, You are very welcome! I can tell that you have really put a lot of hard work into this framework. I'm using Labview 2011. Also, here is a little more feedback: I found that I the default way of launching a parallel process using the path of the class did not always work for me. This is because I dynamically loaded a child class onto a parent class string. So when it came time to launch the parallel process (for the parent class), the messenger library was looking for a VI that didn't exist (because the child class path was on the string). I started to modify the code in the launch.vi, but then I noticed that you had a nifty little data access vi named "Specify Process.vi" that easily allowed me to specify the path to the correct process. Also, when I noticed that you had this Specify Process.vi I started looking around more in your code and seen that there are a LOT of other very usefull VI's that are not indicated in your tree of vi's. On another Note, I really haven't completely understood how to harness the power of your event registers, or should I say the ObserverRegistry. For example, I am not really getting why that you create Observer Registry in every parallel process and why you seem to notify every time a state executes in the parallel process. Or even what the difference is between Notify State and Notify Event. What I imagine the Notify to be used for is that if you send a message with a certain name, you can register other Observers to "catch" that message also. What happens when you have a lot of notifiers in the code, but nothing ever listens for the notifications? What happens when you send messages, but nothing recieves them? For instance in a parallel process you have a Msg:Reply. I would leave this unwired, or let the case structure node be Use default when unwired. Is it good programming practice to when there is a reply message in the parallel loop, should there always be a NOTIFY attached to the message? Ok, I thought that i would attach some screen shots of my code, also, so you could see what I had done. - Ben Yeske

I am leaning towards messaging the data to a central "Storage" vi and have it write the data. The reason for this is that in one of my projects, I have NOT done this and I am now realizing that I might should have. I simply passed the TDMS reference to my parallel processes, and as the processes needed to write to Disk, I just use the Write to TDMS vi's. This worked, because my file never really needed to change. Now I am wanting to implement a new feature to allow the user to interrupt this constant stream of Data and redirect it to another file. So I need to close the TDMS reference and Open a new File. Problem is that since I passed all the references from a top level down, and I am constantly streaming to disk, I cannot easily change files. If I had used a messaging system back to a storage VI, I could buffer up the data flowing in while the process of closing and opening a new file completed. I would only have 1 place to change the TDMS reference. I just thought of another way to do this, without using a messaging system back to the "storage" vi. I could go ahead and open another file, then pass the new TDMS reference to all of my parallel processes, with a message that the TDMS reference has changed. The advantage with using a single storage VI is that one could parse the data flowing in to determine the correct "point" at which to cut the flow, start buffering, and wait for the new file to open. I feel that it would be much harder to "line up" the TDMS channel streams if a new TDMS reference was simply passed to the parallel loops.

I LOVE this Test Messenger Library! I am fairly new to OOP and I have picked this right up. I have put to good use your Metronome Method and the Parallel Launching of VI's. I had a Class of Instruments, and children classes of Power Supplies and Ammeters. I have an array of Class Instruments, with each element a child class. I simply made a parallel process for each instrument, and launched all the parallel processs in one simple for loop indexed on the array of Class Instruments. Next I used the metronome method to send a broadcast message to each parallel process to grab an update from all the instruments. Works Great! and solves so many timing issues. Now I am trying to learn the Actor Framework, but It is proving fairly challenging.

I agree, The cognoscentUI is great, Thanks for pointing that out. I spent some time today playing around with it and It seems to be exactly what i was talking about. The demo program has only one X-control, but I was able to Duplicate it easily enough. Now, what I need to learn is the Module Class to see how I could create and load in an instrument Module, based on the instruments class. I also played around some with subpanels, and they are easy enough to manipulate. The problem that i am still thinking about is how to have an arbitrary Number of Xcontrols or Subpanels. Do I have a stack of them that are empty off to the side and Move them into position as the User Wants to see a panel? How else could I do this?

My Main reason for posting is that I too am wondering what is the best architecture for displaying status of multiple instruments. I am developing for 3 instruments with it being very probable that i will expand to 7-10 instruments. The User will run and control these instruments asynchronously and would like to see realtime status displayed on the GUI. There is the possibility that there could be some instruments used sometimes, and then other times other instruments are used. What I would like to do is let the user select which instrument Panels are displayed in the Front Panel and allow rearranging of these panels. How can I do this? I would have a variable size front Panel for each Instrument. I thought about using subpanels, but Can they be programatically created? I think that they can be programatically resized. I thought about having a stack of Subpanels off to the side and I could grab them, resize, position, and populate the instrument FP as needed. Also I was thinking that it would be nice to allow the user to rearrange the instrument panels onscreen as needed. I was going to make each instrument its own class and somehow relate the Instrument FP to the class if that made sense. I didn't want to make a pop up window for each FP. And I could probably do this easily with an array of Subpanels, but my problem is that each FP could be a different size. Is this a good Idea, or am I going down a bad path here?

I know this is an old thread, But I am amazed at all the numbers thrown around in this posting that are incorrect. Just in case you need to know, and don't want to work it out for yourself, the number of seconds elapsed between the first days of 1904 and 1970 is 2082844800.

Thanks for confirming this Neville. I'll try to get NI Involved. I probably uploaded too much code. I was only interested in the "IMAQ JPEG Demo.vi" inside of the "IMAQ_JPEG.llb." That uploaded attached zip file is almost exactly what is available on the NI website. I don't have the Vision module, but I do have the IMAQ drivers which come with a NI Framegrabber, so I have a watered down, free version with some IMAQ functionality. Thanks again, Ben