Three timer application with defined endpoints

Question

I'm having trouble making a rather basic application. . .
I am trying to create an application that has three timers (let's say A, and B, and X) that are triggered by three different keys on the keyboard (the "a", "b", and "space bar" keys respectively). this will be used to record the amount of time, and the number of times, that a subject investigates two different objects (A and B). The user of the app will press either the A or B key on the keyboard when the subject starts investigating one object, and then "Space Bar" when the subject stops.
The app needs to output an array/file (or multiple) that has the durations of EACH seperate visit to object A and/or B, as well as the total number of visits to each.
Finally, the App must stop (or give an indication to the user) when EITHER the total (cumulative) amount of time spent at A + B is 30 seconds (i.e. the subject has spent 30 seconds investigating any object), OR the trial has lasted for 20 minutes (i.e. A + B + X ≥ 20).
I'm able to create individual parts of this app, but I'm having a hard time integrating them.
any help regarding tricks I should use to accomplish this would be much appreciated!Message Edited by tlambert03 on 10-06-2007 11:34 AM

Answer 1

I think I saw the behavior you are talking about.  I would look at a few possibilities.
1.  The shift registers in your innermost loops up top are uninitialized.  So they will maintain the state from the last time they were executed.
2.  The outer most loop of the upper portion has no shift registers at all.  So the inner shift registers will only get their state from the last iteration of the outer loop.  I think you may need to put your shift registers on your outer most loop.  The inner most loops are behaving like a functional global variable that is embedded in your application.  Since they only run once, I think you should probably eliminate the inner most loops and wire the shift registers to the outer most loop.
3.  The lower event structure has a little bit complicated logic with case structures embedded 3 levels deep.  That makes it harder to debug and determine if the right case is executing depending on the conditions.
4.  I don't believe local variables are as bad to use as some members of the forum, if they are used carefully.  But with the deeply embedded logic structures, there is a possibility of a race condition going on where the logic is executing on a stale value of the indicators.
I think there is room to simplify and clarify the structures in points 1, 2, and 3 above and that may help determine the reason for the inconsistent behavior which I would attribute to the uninitialized shift registers.