timers

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
timers
#1
Trying to understand more about timers, in particular:

do all states need to have a 'global timer' defined? In all the example protocols I have, this seems to be the case
such that even states that arent timed have the 'Timer' field set to 0. If so, then
Reply
#2
Hi Justin

Each state has a state timer. The timer begins when the machine enters a state, and generates a 'Tup' event when the defined interval ends IF you are still in the same state.

In the OneState example state machine, 'Timer' refers to the state timer, and '1' refers to its duration.

In the interest of efficiency (to reduce the dead-time between trials by a few ms when state machines are large), the state machine assembler's AddState function does not use a "parse args" scheme - so all of the valid argument/value pairs ('Name', 'Timer', 'StateChangeConditions' and 'OutputActions') must be given for each state, even if they are not used.

Global timers are entirely different from the 'Timer' you see in each state definition. They are not attached to individual states, and are not required to run a state machine. This link should help clarify their use:

https://sites.google.com/site/bpoddocume...timer_beta

Also, see the global timer examples in here:

https://github.com/sanworks/Bpod/tree/be...20Machines

I hope this helps!
Reply
#3
(03-14-2017, 03:25 AM)Josh Wrote: Hi Justin

Each state has a state timer. The timer begins when the machine enters a state, and generates a 'Tup' event when the defined interval ends IF you are still in the same state.

In the OneState example state machine, 'Timer' refers to the state timer, and '1' refers to its duration.

In the interest of efficiency (to reduce the dead-time between trials by a few ms when state machines are large), the state machine assembler's AddState function does not use a "parse args" scheme - so all of the valid argument/value pairs ('Name', 'Timer', 'StateChangeConditions' and 'OutputActions') must be given for each state, even if they are not used.

Global timers are entirely different from the 'Timer' you see in each state definition. They are not attached to individual states, and are not required to run a state machine. This link should help clarify their use:

https://sites.google.com/site/bpoddocume...timer_beta

Also, see the global timer examples in here:

https://github.com/sanworks/Bpod/tree/be...20Machines

I hope this helps!

Ah, so Global timers somewhat replicate the functionality of Bcontrol's ScheduledWaves, yes?
Reply
#4
(03-14-2017, 03:25 AM)Josh Wrote: Hi Justin

Each state has a state timer. The timer begins when the machine enters a state, and generates a 'Tup' event when the defined interval ends IF you are still in the same state.

In the OneState example state machine, 'Timer' refers to the state timer, and '1' refers to its duration.

In the interest of efficiency (to reduce the dead-time between trials by a few ms when state machines are large), the state machine assembler's AddState function does not use a "parse args" scheme - so all of the valid argument/value pairs ('Name', 'Timer', 'StateChangeConditions' and 'OutputActions') must be given for each state, even if they are not used.

Global timers are entirely different from the 'Timer' you see in each state definition. They are not attached to individual states, and are not required to run a state machine. This link should help clarify their use:

https://sites.google.com/site/bpoddocume...timer_beta

Also, see the global timer examples in here:

https://github.com/sanworks/Bpod/tree/be...20Machines

I hope this helps!

Doh, just realized you mentioned GlobalTimers ~ SchedWaves in an email to me. Sorry, must learn to read better
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)