Jump to content

monzue

Members
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by monzue


  1. 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


  2. 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

    • Like 1

  3. 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.


  4. Is it possible to get the actual execution state (running/waiting to run) of a VI?

     

    The Exec.State property node returns "Running" if a SubVI is waiting to run or if it is actually running.

     

    attachicon.gifrunning.png

    attachicon.gifwaiting to run.png

     

     

    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.


  5. 3) The above technique in (2) is event driven (User pushes button —> sends message —> fires Value Changed event).  In contrast, using a DVR requires the receiver to poll for changes to the UI settings it cares about.  It also works remotely (the example above works over TCP), though that is often not needed.

     

    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.


  6. monzue: yes, it seems easier. Yes, the code can be lighter. It is one of the best ways to introduce race conditions into your actor interactions.

     

    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.

     

     

    Maybe a hybrid approach could work... You could create a singleton class that provides global access to an encapsulated DVR that references your 'Model' data.  You can put semaphore mutex functions in the class so that Read/Modify/Write sequences can be safely performed by any processes in your app.

     

    Why would I simply not use the In-Place Structures?

     

    Some random thoughts:

    1)  I tend not to have an actual “UI actor”; instead I have each actor have it’s own UI on its front panel, and have the main actor present the subactors in one or more subpanels (or just open their windows.  This involves less messages to pass around.

    2)  One can also deal with needing lots of messages for lots of UI controls by treating the controls generically using techniques illustrated below.  This is a “Control Server” example that I don’t think is in the version of “Messenging” in the code repository, but will be in the next version.

    attachicon.gifControl Client Server.png

    Changing any control in Pane 2 of the “Control Client” sends a Variant Message that then fires a Value Change event in the Control Server.

    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.


  7. 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.


  8. 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?


  9. 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.


  10. 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. 


  11. 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.

    Launching Parallel Processes

    Instrument Updates linked To Metronome

    - Ben Yeske


  12. I am running the UI on the control machine but the operator can also access a GUI from a remote machine which will plug in much like Steen's system noted above. I do keep the "business" seperate by making each channel the commander of it's own routines. It runs by itself only receiving change commands through a queue from the mediator. My education from this forum lead me to believe that was the best way to do it. I was going to have each channel write its data to the tdms file as well but maybe I should message the data to a central "Storage" vi and have it write the data??

    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.

    • Like 1

  13. 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.


  14. 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?


  15. 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?


  16. 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


  17. QUOTE(Neville D @ Oct 26 2007, 03:08 PM)

    Can you post some example code that demonstrates the problem? I have been using Decode and Encode for a while now, with no problems.

    What are you trying to do? Maybe if its blowing up, you could just save the JPEG string from the Encode to file, and then open the file instead?

    How about trying to kill the buffer after decode and then using a fresh buffer on the next iteration?

    If there really is a bug in the Decode, only NI can fix it, (since they have the source code) and you will have to open up a service request with them.

    Neville.

    Attached in the previous Comment by me is a screenshot of the IMAQ JPEG Demo Code with a while loop. After your suggestion about killing the buffer after decode, then using a fresh buffer on the next iteration. I have implemented that concept (I think!) and have uploaded that code. See attached .zip file.

    Also noteworthy is the fact that I do not have NI Vision Module, so I had to slightly Modify the JPEG code by deleting the IMAQ Cast.vi inside JPEG Decode.vi I don't think that doing this would cause my memory error though.

    And noteworthy is the fact that the code from NU does not come with the current image datatype. I have tried converting the datatype with the utility provided by NI for this, and have tried just copying and pasting the new image datatype. I don't know if one works better than the other.

    I could save the string to a file then open the file, but that to me seems to involve an unnecessary step. What I am doing is recieving a JPEG Encoded String over a UDP connection. On the recieving end I, I simply want to view the imagery. This imagery comes across the UDP connection at a rate of ~3 frames / second.

    Thanks for your help, Neville

    What I would like is for someone to verify that I am performing the Imaq Functionality correctly, and am not missing something small. Also, If someone could verify or not verify that the JPEG Decode.vi is working correctly with RGB images.

    Ben


  18. QUOTE(mateo @ Jun 26 2007, 11:52 AM)

    QUOTE(Neville D @ Jul 9 2007, 12:48 PM)

    What do you mean by "great amount"?

    Is it affecting performance?

    How large of a JPEG file are you trying to encode?

    The buffer in Encode may be re-usable for future calls. I wouldn't worry about it unless it is drastically affecting performance.

    Neville.

    I am having this VERY SAME PROBLEM. What is meant by great amount is that the code eats at the system Memory until it is entirely taken up. Note, I didn't see this effect with grayscale images, only RGB images.

    This problem can be easily observed by downloading the JPEG code from NI at http://sine.ni.com/devzone/cda/epd/p/id/3314

    Filename: 202724.zip

    Then, Modifying IMAQ JPEG Demo.vi inside IMAQ_JPEG.llb so that there is a while loop placed in such a way as to allow the Imaq JPEG Decode.vi to run continuously. See attached picture. The .zip file is really a Jpeg image. Just rename the .zip file to .jpg

    Any suggestions on what to do?

    Ben

×
×
  • Create New...

Important Information

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