Closed GoogleCodeExporter closed 9 years ago
I partially took care of this problem in revision 226 by forcing the user to
start the scope (note that this does not mean starting recording) before
screwing around with the stimulation page.
I realize that this fix is not elegant. However, if we want a true fix, we need
the stimTimeTask and the tasks associated with actual stim delivery to run on
different, but synchronized clocks. I think that right now, they run on the
same clock. This means that if the user starts stimulation and then tries to
start the scope with the 'record stim times' hardware option checked, the scope
tries to set the stimTimeTask up on the clock that is being used by the
stimulator.
Original comment by jonathan...@gmail.com
on 10 Dec 2010 at 4:03
In revision 300 and beyond, this issue was fixed. It does impart some
constraints on the DAQ that is used for stimulation. Basically, the stimulation
task needs to have access to its own start trigger to separate it completely
from ongoing recording tasks - i.e. it needs a separate board.
Original comment by jonathan...@gmail.com
on 19 Aug 2011 at 3:34
Original issue reported on code.google.com by
jonathan...@gmail.com
on 9 Dec 2010 at 5:08