Iterating while loops while event structure is timed out

[CFAMS Brad]

Hi all,

I am trying to implement an event based program into a data processing program.  I am new to event programming and this part of the project was only made possible by help from this list, but I am back for more.

In the attached VI (PTCS....), the event portion of the program works as needed, however I assumed in putting it together that the while loop would iterate all of the time.  Because I used the timeout function of the event structure, the timeout actually freezes the entire while loop and I can't acquire data unless I repeatedly toggle the toggle button (the random number generators are really DAQ devices). 

I have also attached a similar program on which this idea was based (while loop event structer.vi).  Here, the state machine is in the toggle event, not the timeout event.  Is this the only approach that will work?  I am thinking that I have to remove the state machine from the time out case, but I am wondering if simply adding another state would be possible and easier...Thus far placing the state machine in the Toggle Trap: Change value case does not produce the desired results (in PTCS...) as in the attached simple VI. 

Both VI's are attached in  LV 7.1 only

[johnsold]

You are close. Put the event structures in a separate loop. The DAQ (or simulation) runs in a parallel loop. The loops exchange data and commands via queues.

As your programs are written the loops can only iterate once for each time the event structure executes -- This is basic dataflow programming. So when you have the timeout sett to -1, the loops will wait forever for an event.

Lynn

[CFAMS Brad]

Thanks for the quick tip Lynn.  I knew I just needed someone else's fresh opinion after I wasted the morning trying the wrong approach.  I have posted your suggestion, however I don't have any semaphores or queues to synch the loops, because there is no data being transferred between them.  One loop simply needs to act on events and uses the while loop to set up the state machine and the other is a data flow program.  Does that seem logical to you, or am I asking for trouble that I can't foresee right now?

Cheers,
Brad

[CFAMS Brad]

Sorry, that was the wrong version .vi.  Here is the correct version in 7.1.  And now that I am down the road a little, I see a problem where the program freezes if the user hits the stop button before the toggle trap button is switched...

Message Edited by CFAMS Brad on 07-06-2006 03:27 PM

[CFAMS Brad]

Running the VI in highlighted execution reveals that the local variable is not updated with the boolean value coming from the stop button case of the event structure.  The event structure while loop stops, but the data acquisition loop never stops, continually updating a false value to the conditional terminal despite the source of the local variable obviously being true.  I don't understand this.

I have tried semaphores and queues, and they solve this problem.  However, most of the time, the event structure loop is in timeout, and therefore the semaphores and queues are not updated.  This means I do not achieve iteration of the data acquisition loop unless a programmed event happens.  I want this loop to iterate all of the time, regardless of the event loop, and only to stop simultaneously with the event loop. 

I am going to try to write to a functional global variable from the stop button, but I have a feeling that this will produce the same results as semaphores and data queues.  (If I understood the problem a little more, maybe I'd have something more concrete than a feeling).

[johnsold]

Brad,

Actually I think it works exactly as wired. The mechanical action on the Stop button is set to "Switch until Released." So the event structure captures the value change and responds appropriately (that loop always stops). However by the time the local variable is read (at the next 200 ms interval) the switch has returned to the False state.

A queue will work fine in this application. I use them all the time. In the Stop event case, enqueue a "Halt" command. ( I use "Halt" rather than "Stop" just to avoid confusion - or maybe to create more). In the other loop Dequeue Element with a short timeout (you don't want the loop to wait for something to be put into the queue). If the dequeued element = "Halt" then stop the loop. In more complex applications I may use a second queue to return status (= "Stopped") to the main loop. If you use this method, you eliminate the local variables and can return to "Latch when Released" mechanical action on the Stop button.

Lynn

[CFAMS Brad]

Thanks Lynn.

I've re-implemented the queues into the program, and it still doesn't work.  What I don't understand is how to tell the data acquisition loop to keep reiterating when there are no events happening.  By doing what you recommended (at least what I think you recommended), the program stops without a problem.  However it does not acquire data without an event happening.  I've also tried wiring a false element to the queue for every case but the stop button value change case and that doesn't work either because during the timeouts, there is only on false element being sent to the queue, and therefore only one iteration of the data acquisition loop.  Then the while loop up top is waiting for the bottom loop to fill the queue which won't happen until the timeout is alleviated and the bottom loop can iterate.

I've attached my attempt at queueing this program.  Am I doing that wrong?  I haven't used queues outside of the basics I classroom.

Brad

[jasonhill]

I think Lynn has the best solution.  Using the queue to provide control strings that are passed to a case structure.  It will make it much easier to add features at a later date.

If you are set on using a boolean queue, I have a couple suggestions.  Rather than de-queuing the element, try previewing it.  I recommend that you put the enqueue inside the event structure.  Otherwise you will never get through all the falses to find the true.



An even more abrupt way of closing the aquisition loop is to destroy the queue after the event structure completes and just be checking the status in the aquistion loop.  When the queue status tries to read a destroyed queue, it returns and error, and stops the loop.

Message Edited by jasonhill on 07-07-2006 10:42 AM

[johnsold]

Brad,

The timeout should be on the Dequeue function rather than the Enqueue. Also putting the Enqueue inside the Stop Event case means the queue only gets written when the event occurs.

I have attached a modified version.

Lynn

[CFAMS Brad]

Thank you Lynn and Jason - all of those tips are good solutions.  Thanks especially for explaining that my program was originally working exactly as wired - as I learn this language I am finding it harder to read than to write. 

Brad