LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

queue and multiple timed loops

Hallo,

i'm going to write a vi to observe and control a test stand.
There are 9 AI Channels, 6  DI Ch., 2 DO Ch. and 1 AO Ch. i've to drive at the same time....
I want to use the producer consumer model with queue for doing this application  -  one  producer and  5 different timed synchronized consumers :
  • one for doing FAST as possible limit testing on one AI Channel and driving -in the result of the limit testing- 1 DO line;
  • one for doing some slower limit testing on the other 8 AI's and driving -in the result of the l.t.- the other 1 DO line;
  • one for the boolean operation
  • one for driving the 1 AO Ch.
  • and the last one for time uncritical things like notification mail sending...   
"my" main problem is the concurrence of these processes...

My Questions:

  • is it reasonable to use timed loops and queue together - i thought it is because of the simple synchronization and the possibility to know wether the loop is in time (late ending notificaton) (?)
  • if i convert 2 timed loops in subvi and give them different execution systems (=different thread i.t.?), why is the one loop always late ending?
  • is there a better programing model for doing so?
I'll hope you survive me terrible english - thank you!
(LV 8.0 - cDAQ-9172/9215/9233/9263/9401- 3,0GHz Xeon 1G Ram)

sample part of code attached
0 Kudos
Message 1 of 7
(3,557 Views)
Hi,
first of all some facts of your application:
You are using in the Queue_2.vi a implicit timed while loop and you have two subVIs erste.vi (dt 10ms; priority 100) and zweite.vi (dt 100ms; priority 100) incl synchronization between these two timed loops.

The iteration timing of the while loop depends on the number of AI channels. Therefore you get in both(?) timed loops the finished late flag because your dequeue functions has a timeout of -1 and both timed loops have the same priority.

My questions are:
Have you ever checked the timing of the while loop?
Why do you read the queue elements in two separate subVIs?
Why do you want to maintain the original phase in both timed loops?

My suggestions:
Replace the while loop in Queue2.vi with a timed loop.
Split those parts of the daqmx into a separate timed loop which will be not directly dependend from the AI (AI has a hardware timing), all other channels are software timed. Furthermore, you are using compactDAQ via USB (right?) and USB burdens the CPU because there are no DMA transfer of the values.
Think about the priorities of the timed loops - what is more important?

BR,
ThSa
Message 2 of 7
(3,505 Views)
Hi Thomas,

thank you for your answer!
 
"Have you ever checked the timing of the while loop?" -> You are right the timed loops finished late - i think i've to fill them with the analyses code and then check the timing again...
"Why do you read the queue elements in two separate subVIs?" -> I've build the Sub VI's to allocate different execution systems to the parts of the program - is it o.k.?
"Why do you want to maintain the original phase in both timed loops?" -> I thought i've to do so for holding the phase of the signal in the different loops??

The code is now closer to that what i want to do - could you please take another view to the example code?

Thank you again!

Robert



0 Kudos
Message 3 of 7
(3,494 Views)
Hi Robert,
generally it looks like better than the 1st sample but there are some things which are possible to improve.
First of all, you create two queues with the same name and the same datatype (sollwert), but with another tabbing order within the cluster. (tabbing order is very important for clusters)
However, in this case you will get an error because you want to create two queues which have the same name but different datatypes.



The argument regarding the phase of the signal is in case of queues and timed loops not directly correct, because queues will be used for synchronization with data exchange
In LabVIEW are two mechanisms for synchronization with data exchange (queues, notifiers) and three mechanisms for simple synchronization (occurrences, semaphores, rendezvous). However, in your case it would be better to disable the attribute "Maintain Original Phase" in all timed loops with the deqeue element function.
The other thing is, I think it makes no sense to read out of the same queue (regarding your old program) in two different subVIs. If your final application needs this, it is ok but to my mind it makes not really sense.
One cool thing you did is that you have limited the queue size to 50. On the one hand it is very well but on the other hand, this thing could make big problems. Because the queue does not overwrite the oldest sample as the real time fifo do, therefore you have to include a special management for this kind of situation if you do not want that the application stops in this case.

Furthermore, I saw in your block diagram documentation that you want to realize a software emergency stop. For this case, I would suggest, to give those timed loops which are involved the highest priorities.

BR,
ThSa



Message Edited by ThSa on 08-24-2006 04:15 PM

Message 4 of 7
(3,485 Views)
Hi Thomas,

"...First of all, you create two queues with the same name and the same datatype (sollwert)" - i've overlooked the similar names - sorry...
"...The other thing is, I think it makes no sense to read out of the same queue (regarding your old program) in two different subVIs"  - you are right it makes no sense (first try)
"...therefore you have to include a special management..." - if i understand you in the right way i've have to make sure that the consumers run faster then the producer?
"...
. For this case, I would suggest, to give those timed loops which are involved the highest priorities..." - this means: erste.vi zweite.vi and dritte.vi all in execution system subroutine??

Thanks a lot!

Robert




0 Kudos
Message 5 of 7
(3,473 Views)
Hi Robert

"...therefore you have to include a special management..." - if i understand you in the right way i've have to make sure that the consumers run faster then the producer?
This depends on your DAQmx configuration. On the one hand it would be better if you ensure that the producer runs slower than the consumer, but on the other hand the acquisition rate is fix. Either you find a balance between producer and consumer OR you have to allow the DAQmx driver to overwrite old/unread samples, otherwise you get a buffer overflow error.

"...
. For this case, I would suggest, to give those timed loops which are involved the highest priorities..." - this means: erste.vi zweite.vi and dritte.vi all in execution system subroutine??
Do not use the subroutine, because with the timed loops which run with different priorities you have a preemptive model.
Only set those timed loops for emergency stop to a higher priority then the others.

BR,
ThSa
Message 6 of 7
(3,465 Views)
I havent used the DAQmx read property "override unread data" node yet - but i'll be doing this!

O.K. Thomas many!!! thanks for your endurance! -  and congratulations you survived my bad english!

Robert


0 Kudos
Message 7 of 7
(3,442 Views)