LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

speed of queue

I designed some state machine routine for DAQ by using queue with user interface event loop.
 
Initialize routine -> (next) Read data
Read data -> Read data
Setting Change -> Initialize (with  Killing of  current DAQ)
 
The loop is operating in the 50 ms timed loop.
Normally, the loop state is running under "Read data".
At this point, when I change the setting parameter(Max/Min Range of DAQ) in the separate event loop,  the DAQ should killed and then initialize again  
I anticipated "Read Data" -> "Setting Change" -> "Initialize" -> "Read data", but the real is "Read Data" -> "Setting Change" -> ""Read data"" -> "Initialize".
Therefore Labview produced an error of invalid DAQ channel.
Actually, enqueue of  "Setting Change" was happened in the event loop (not state machine loop).
 
To overcome this problem, I flushed queue before "Setting change" and could reinitialize DAQ.
 
In other application, I found again the interacting speed problem in a conditional routine without flushing queue.
Should I use always the flushing routine or best other way not to include an useless state?
 
 
 
 
0 Kudos
Message 1 of 8
(4,344 Views)
Hi labmaster,
where do the "Read Data" events come from? I don´t think it is a speed problem. Can you upload your code or a picture of it?
Mike
0 Kudos
Message 2 of 8
(4,328 Views)
Actually, I am very beginner in queue technique.
 
Okay, I want to describe my problem in detail
One of attachement showed the block diagram of LV code.
The code consists of "UI event", "UI event Queue", fast "DAQ queue".
The fast DAQ is running all the time for monitoring some data.
 
The other of attachment showed the initial state of DAQ queue (only 2).
(Readdata means I can monitor the DAQ)
 
If I press some "digital button" 3 times, the size of DAQ queue will be 5.
(because the location of dequeueing is only one) 
Because of this, it takes a little time to dequeue of DAQ-WriteDigital.
 
In my application, as I told you earlier, DAQ is running so fast to monitor the data.
How to solve my problem?
 
*)Correction of bbb.png, 5 times should be corrected to 3 times.


메시지가 06-10-2008 08:44 AM에 labmaster에 의해 편집되었음
Download All
0 Kudos
Message 3 of 8
(4,307 Views)
It would be better to upload your VI so that all the code can be seen. It almost looks like the middle loop is not even necessary in this case.

Aside: why do you have a Wait function inside the timed loop, while also wiring to the "Delay" parameter of the timed loop?
0 Kudos
Message 4 of 8
(4,280 Views)
I think your problem is the fact that you have one loop that is both dequeing items, and enqueing items. This is gonna cause a timing problem as to which loop is enquing items first. Take out all enqueue elements in your consumer loop and just have it check to see if there are any elements in the queue to be read, if not, just contine to the current state.
0 Kudos
Message 5 of 8
(4,275 Views)

smercurio…

My code has a device dependent. Please, understand my situation.

In my application, the timing was important and timed loop is sufficient to me.

 

StevenD, thanks.

You mean DAQ enqueuing (state machine) routine?

Would you suggest me shortly how to make a continus monitoring routine" in DAQ without the enqueue?

 

0 Kudos
Message 6 of 8
(4,266 Views)
Use state machine for the loop. Use the Get Queue Status function, wire the #number of elements in queue to a case structure. Case 0 will pass the Enum from the shift register through, on the "Default" case (means there ARE elements in the queue) wire the Queue enum through.






Message Edited by StevenD on 06-10-2008 10:42 AM

Message Edited by StevenD on 06-10-2008 10:51 AM
0 Kudos
Message 7 of 8
(4,250 Views)
I had a wrong concept of queuing against a state machine.
I implemented your suggestion after modifying the code.
Thanks..
 
0 Kudos
Message 8 of 8
(4,189 Views)