three timer application with defined endpoints

[tlambert03]

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

[mishklyar]

hi,

I would try something like attached template.

[RavensFan]

I think you will want to start by looking at the event structure.  Have an event to handle the Key Down event.  Based on which key is pressed, it would start Timer A and Stop B, Start Timer B and stop A, Stop both, or do nothing (in case it is another key).  You could start timer X (the 20 minute timer) when the program starts

Store the elapsed time for each timer in a shift register.  (A, B and X)

Have a timeout case so that the status of the timers can be checked and compared to determine when to stop the program.

The trickiest part will be handling each timer in shift registers.  Any time you want to start timing, you will have to take the current time and hold in in a shift register and continually compare to the current time.  You will have to also track how much time had accumulated in previous starts and stops.  It shouldn't be difficult, but a good logical programming problem.

[tlambert03]

thanks both for your thoughts.
I've got something working reasonably well now with shift registers and seperate timers . . .

[tlambert03]

so this is what I have so far . . . it does what I need pretty well (although I haven't implemented the data export yet...)

i have a weird problem though.  the app & front panel are only responsive to the keyboard every other time I run the VI. . . is this a problem with my key down event structure?

[RavensFan]

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.