Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


monzue last won the day on January 23 2014

monzue had the most liked content!

Community Reputation


About monzue

  • Rank
    More Active
  • Birthday 07/18/1982

Profile Information

  • Gender
  • Location
    Huntsville, AL

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since

Recent Profile Visitors

1,498 profile views
  1. 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.
  2. 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
  3. Awesome!! Number of elements in the queue is all that I have ever used. Ben
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. Perhaps OP lives in North Korea, and has been "tasked" with this project.
  9. 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.
  10. 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
  11. 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 th
  12. 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
  13. 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 s
  14. 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!
  15. Nice! It looks like I'm on the right track. Thanks for all the comments, and here's to waiting for the new version:
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.