From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
06-28-2010 01:13 PM
I am trying to determine which architecture, or combination woudl best suite my application:
The core aspect is a client receiving data from a network at variable speeds - I have this working using a producer consumer loop (data) design pattern, that starts and stops by placing it inside a case structure with start button. I'd now like to combine this with an event driven user interface, which also uses the serial port to talk to external hardware every now and then. I have that working seperately with a producer consumer (event) design pattern. I'd like to combine them and include regular events (handshaking with the external hardware) to take place whilst the producer-consumer (data) reads from the network.
How can I mix the two design patterns?! I'm struggling to get my head 'round this.
Thanks
06-28-2010 02:24 PM
Put both architectures in the same vi, running in parallel. You can use a queue to send messages between the two.
06-28-2010 04:01 PM
Thanks tbob, could you show me what that structure would look like with an example from the templates please? I'm not too sure about that. I've just put the whole producer/consumer (data) structure inside a consumer (event) but haven't thought through the handshaking yet.
06-28-2010 05:01 PM
Here is an example of two Producer-Consumers in one vi. Notice the two queues. One is for commands to the event loops. The other is for the serial data loops. When certain data is received, you can send commands to the event loop (actually to Consumer loop, 2nd from top) to cause some action. So the user can initiate some action via event structure, and received data can also initiate some action.
This is complex and it might not do all you want. But its a start.
06-28-2010 05:05 PM
I think I have four parallel loops:
1. A user event structure to direct the code from the user
2. A real-time data collection loop (to read from the network and do some heavy going calculations)
3. A device comms, loop (via RS232) to send result of calculations to my external hardware (has a manual step-by-step mode, and auto mode to take data automatically from 2. to 3.)
4. A handshaking loop to keep talking to my device and take action if a comms. failure occurs
2. is currently a seperate producer/consumer (data).vi
1. and 3 are currently in a producer/consumer (event).vi with a badly working effort to include 4.
I've only ever used two loops as per the templates, so I'll experiment with parallel loops tomorrow.
06-28-2010 05:08 PM
Ah! you beat me to it. That looks very useful, it's getting late but have something to play with tomorrow. Thank you.
06-29-2010 01:18 PM
Could someone explain why this doesn't work?! .. and if it's possible to address specific consumers?
06-29-2010 01:34 PM
Each queue can be thought of as pile of things.
There is a pile of things created everytime you create a queue. one create one pile.
The remove from queue takes something out of the pile.
If you put one thing in and have many critters each trying to take something out, only the first one attempt it will get it.
Ben
06-29-2010 01:46 PM
Ok, so can I create three queues, write the same value to each queue and read from one of the queues? Like this ..
06-29-2010 01:58 PM
@grahamwebb wrote:
Could someone explain why this doesn't work?! .. and if it's possible to address specific consumers?
There a a couple way to get the operation you want. I've posted a minor modification that sets the queue to 1 element and uses the lossy enqueue function and replaced the dequeue functions with Preview. Note: since no comsumer is actually dequeueing an element the queue allways contains the last element enqueued so the consumer loops were throttled back to iterate only 10 times a second.