LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Input and output on same device, producer/consumer structure

Hello interested people,

I have a question about using the same device for both digital inputs and outputs.  I have written a simple program of one while loop that continuously polls the device, processes, and requests.  I have addressed the device using two DAQmx Asst. and I have attached them with their error in/out cluster terminals to provide data flow and eliminate the chance of addressing the devices at the same time (which produces an error).  Now I want to change this program structure to a producer/consumer loop foundation with state machine.   In this design, I will have the DI in the producer loop and the DO in the consumer loop, under one of the states.  I can't simply connect the error in/out ports in this configuration, so my question is how to avoid the error caused by addressing the same device simultaneously with two different tasks (input and output)?  I have attached two VI's, the "One Loop" vi is the original configuration (simplified), and the Producer-Consumer vi is a NONSENSICAL program that simply represents the desired configuration.  (I don't need any comments on the programming of this vi, it is only an example for illustration of the problem). 

I am thinking about bundling the input data and the error cluster, both from the PXI 6528 DI, into one cluster, queueing that up, and unbundling the de-queued elements for some kind of data flow between the producer loop and the "Request" state of the consumer loop.  Is this the right approach, or am I barking up the wrong tree?

Thanks
Download All
0 Kudos
Message 1 of 5
(1,845 Views)
Hello,
 
The producer/consumer architecture is traditionally used as follows:
 
Producer Loop: responsible for monitoring the user interface for events and actions, and updating the user interface when necessary.
Consumer Loop: responsible for doing the "work behind the scenes" which is scheduled by the user interface actions caught in the Producer loop.
 
Thus, usually what's passed from Producer to Consumer is just an instruction to execute some routine.  By separating the "grunt work" from the "user interface" you take advantage of LabVIEW's multithreading and keep the user interface separate from the potentially computation-intensive work done behind the scenes.
 
With that said, I don't think the producer/consumer architecture is what you're looking for, at least not in the way you've proposed using it.  If you can provide a brief description of your "overall goal" for this application, I will try to give you some direction with an architecture which suits your needs.
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 2 of 5
(1,811 Views)
I want to employ this architecture in a system monitor.  This monitor at present is simply sending user requests when made on the interface and enacting interlocks and other stops when something is wrong with the user request or with the actual system.  I am looking at some examples in LabVIEW basics book for ideas, and they seem to only use the producer loop for data inputs - i.e. monitoring the system.  In my case, these inputs will govern whether the user interface controls the request (everything is OK with the system) or if the user is blocked from manually requesting an action (an interlock state or a set system configuration at run time).  That is why I have inputs in the producer and outputs in the consumer, and having devices with both inputs and outputs is the reason for this question.  I am still setting up the program, so I am not even sure if I will in fact run into the "resource occupied" message.  But I suppose...
0 Kudos
Message 3 of 5
(1,804 Views)
Hello,
 
It sounds to me like you really have two modes:
 
1. user interface actions determine execution
2. user interface is locked, and execution is automated.
 
I think it would make sense to use the producer consumer for an architecture.  Basically you would do the following:
 
1. program the producer to handle the user interface as you normally would.
2. provide one additional event case in the producer which would be your "automated handling" case.  In that case, you could put a state machine which could run until whatever conditions were met to put your program back in "user interface mode".
 
Keep in mind that you can use custom USER EVENTS to programmatically generate events ie. you can trigger the start of your "automated handling" form anywhere in your code at virtually any time.
 
I think this would allow you to take advantage of the producer consumer architecture in its intended spirit, while integrating an automated routine.
 
I hope this helps!
 
Best Regards,
 
JLS
Best,
JLS
Sixclear
0 Kudos
Message 4 of 5
(1,781 Views)
Thanks for the help everyone.  I have implemented this stucture and addressing the same PXI board in both the producer and consumer loops is perfectly viable so long as the board's  error cluster is queued in the producer and accessed in the consumer.  This provides the necessary data flow to avoid errors pertaining to the device being reserved or occupied.
0 Kudos
Message 5 of 5
(1,689 Views)