Jump to content

Search the Community

Showing results for tags 'queue'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 5 results

  1. I am trying to read the value of some data in a while loop from a sub-vi (attached as FTP WPF UDP below) into the top-level vi (attached as Proportional Controller VI) but I find that the data is timing out in my top-level vi whereas it runs smoothly withing the subvi. I have used the while loop and the timing in the subvi is synchronized to the external code that sends data via udp to the subvi. Is there a way you think this can be fixed? Below is my attached code. Thank you! Proportional Controller.vi FTB WPF UDP - Original.vi
  2. I did a presentation at NIWeek 2013 on the new user event features in LabVIEW 2013. I will post a link here when it's ready for online consumption. For now, I'd like to start a discussion on what all the LAVA members think of the changes and additions. If you have questions on how one feature or another work, please post here and we'll get it answered. To summarize, here is what was changed, added: New - Event Inspector Window (you're gonna love this!) New - High Priority events New - Flush Event Queue Function New - VI Scripting methods and properties for events New - Mouse Scroll Wheel Event Improvements to the Edit Events Dialog: It's now resizable (Finally) You can filter search the list of event sources and events. For easy navigation. You can limit instances of the event in the static queue (Similar to Flush Queue function) [*]Finally, there was a behaviour change: Non-handled, dynamically registered events do not reset the Event structure timeout terminal. In LabVIEW 2012 and older: Non-handled, dynamically registered events reset the Event structure timeout terminal. Let's keep this positive. We all need to learn how to use these new features and how to integrate them within our frameworks. I know a lot of you are using user events as the main communication mechanism for your processes and modules. Let's figure out how to make our code better with all this new cool stuff.
  3. Hi all, I got a strange queue behavior that is probably related to race conditions. The problem is eliminated (a way around is found), so there is no need in a quick solution. However, I would be happy to understand reasons for such a phenomenon. BD of the “problematic†VI is attached. The queue size is limited to 1. The program consists of multiple asynchronous processes. Execution reaches the Enqueue Element node than stops. The timeout never happens; the program hangs. However, there is more. If I try to execute the VI step-wise, everything works fine until the execution enters the internal Case Structure. When it enters, three Stepping buttons become disabled. If I try to decompose the program, i.e. to use the same VI in a simple single-process program, both problems disappear. Have you encountered such a strange behavior? Any ideas that can help to the poor creature (me) to avoid sleepless nights?
  4. I am mentoring an FRC team and we were discussing a design where we have a couple channels of information, some of which is very high frequency and losing data is not too important, so we are using a notifier. We also have a different channel of data which is much lower frequency, but losing any would be an big problem and we are using a queue. Now the tricky part we would like to be able to wait on data from either source (preferably not busy wait). I have come up with a a couple possibilities: Busy wait on both, looping between checking both sources and a 0 delay in the loop to prevent starving the rest of the code. Tweak the queue based send to also push data to the high volume notifier, when I get a read on the notifier also check the queue and process it. User events? Not sure, but this looks right; however, note that the notifications/queue messages are generated in one subVI (which is called by external framework code) and being sent to another subVI which has a number of long running control loops in it. I was hoping for something a little more elegant, that I have overlooked. Any pointers? Thanks from an old C programmer still trying to get comfortable in labview.
  5. I am designing a method for multiple application instances to coordinate an action across a network. I have previously implemented this using queues for coordination of asynchronous VIs within a single application instance. I now need to make this work across a local network. I have been looking at network shared variables, network streams, TCP/IP, UDP. I would like to know if anyone else has accomplished this and what you learned along the way. The basic requirements are: N number of independent applications need to coordinate some action (essentially a rendezvous). No one application knows if the others exist. (don't know their IP or anything about them) No one application knows if it will be the first to join or will join later. All applications will share a common name for the rendezvous. The first application should create the rendezvous As other join, they should see that the rendezvous already exists and join it instead of creating a new one. All applications should be able to see how many have joined. When all applications depart, the rendezvous should be destroyed by the last one to leave. Thanks for any tips or examples you can share. -John
×
×
  • Create New...

Important Information

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