Queues and event structure

[s35148]

Hi,

I'm having some troubles with a program that I'm doing.
I think the big problem are in the queues and the structure event. I don't know why, but the elements in the queue only increase. And I think, because of that, some things that should happen, don't happen. For example, when I press the button "Impact" an square wave should appear, and it didn't appear.

Thanks for all your help,

Sílvia

[JÞB]

Here is the offending snippet from the Aquire case.  You never get anything except a F in "Impact"

[s35148]

Why I just receive False?

Impact is a control, and when I press that button the event structure insert that value in the queue, I think so.

I don't understand...

Thanks for your help,

Sílvia

[tbob]

In your Acquire state, if Impact ever becomes True, your code sets it to False and enqueues it up again.  Your next state will be Acquire again with Impact False, and this repeats over and over.  Your bottom loop has no delay time, so it runs as fast as it can, taking 100% CPU time.  There is no CPU time to process any new events, like the Impact Value Change event.  Put a small delay time in your bottom loop, outside the case structure.  Then your events will be processed and you will get a True for impact if you press the button.  But it turns false on the very next loop.  Is this the way you want it to work?

[s35148]

Hi tbob,

I want just a little impulse, its why I set the "Impact" to false in that case structure.
I try to use "Wait Until Next ms Multiple" in the "Acquire" state, but if that value is upper than the time of the DAQmx, the read and write stay unsynchronized.
Do you know a way to check the lag between the two waves?
Another doubt is, if labview allow multithreading with parallel while loop, why CPU don't have time to process the events?
In "Get Queue Status", the queue only increase, it shouldn't decrease also when I dequeue an element?

Thanks for everything,

Sílvia

[RavensFan]

Did you read my message #27 in your original thread?

That should tell you why your queue is possibly growing.

[tbob]

Ravens Fan is right.  Follow his advice.  Don't put a wait inside any case structure.  It won't execute when other cases execute.  Put the wait inside the loop but outside the case structure so that the wait executes on every loop iteration.  If you are worried about synchronization, use a value of 0.  Even this will allow some CPU time for other functions.  Also, don't use Wait until next ms multiple.  Use the plain old Wait(ms).  Follow this advice, try it.

[s35148]

Hi,

Of course I read your post, but like I said, I don't understand why, when I press the "Impulse" button, I have the start in the queue. I shouldn't have the previous used enum, because of the shift register?
You are right, the things are slow down because of the re-enqueues and the many Acquire state I have in the queue. But how can I fix that?

Thanks,

Sílvia

[tbob]

---

@sreis wrote:

Hi,

Of course I read your post, but like I said, I don't understand why, when I press the "Impulse" button, I have the start in the queue. I shouldn't have the previous used enum, because of the shift register?
You are right, the things are slow down because of the re-enqueues and the many Acquire state I have in the queue. But how can I fix that?

Thanks,

Sílvia

---

Yes the previous enum will be there because of the shift register.  But look at what is happening in your Acquire loop.  You are enqueueing on every loop iteration.  So your action is like this:

Press Start - enqueue Initialize and Acquire

Initilaize state runs

Acquire state runs - Acquire is queued up again.  Because you have no wait state,  this loop runs super fast and you keep dequeueing acquire and queueing acquire again.  The wait state is imperative to allow the CPU time to process some other loops.  This is not done automatically, you have to allow it by adding waits to loops.

Now you happen to press impact and somehow the CPU finds time to process the event.  What state gets queued?  Acquire again.  Now you have two acquires queued because the last Acquire state also queued an acquire.  Every button you press will enque something on top of what is already there and your dequeue will never be able to keep up.

The solution is to not enqueue anything in the bottom loop.  Never do this.  If you want to acquire when no event is happeing, queue up the acquire in the Timeout event.

[RavensFan]

Correct.  You will have whatever is in the shift register as part of the new cluster you are creating.  (I thought you'd get the default of the enum, but that is my mistake.  I never use Bundle, and only use Bundle by Name when building clusters._

When you hit the Start button, the Acquire command is what will be saved in the shift register (because that is the last thing put into the cluster at the end of the For Loop in the Start event.)

So when you do anything, the acquire command is what is in the enum and thus you put another acquire in the queue, which keeps building upon itself when it re-enqueues.

Why are you not sending a command enum in the Impulse or Impact event cases?  You need to have an impulse or impact state in your state machine that does whatever it is you want it to do.