frequent Trial Manager timer errors

paola

Hi Josh,
I have recently started to use Trial Manager for a version of AFC task, and I am getting a bunch of variegated timer errors.

I call TrialManager.getCurrentEvents with states as an argument which, themselves, last a very short time, but are followed by one state which lasts 0.75 s before the trial ends:

currentTrialEvents = TrialManager.getCurrentEvents({'LeftReward', 'RightReward'})

if BpodSystem.Status.BeingUsed == 0; return; end % If user hit console "stop" button, end session

t1 = tic;

[sma, S] = PrepareStateMachine(S, odorList, TrialTypes_LR, delays, currentTrial+1, currentTrialEvents); % Prepare next state machine.
fprintf('prepared sma for trial \t%d in: \t%3.4f secs\n\n', currentTrial+1, toc(t1))

[...]

sma = AddState(sma, 'Name', 'LeftReward', ...
'Timer', LeftValveTime,... % duration of valve on
'StateChangeConditions', {'Tup', 'WaitForLeftPoke'},...
'OutputActions', {'ValveState', 1, 'PWM1', S.LedLickPortIntensity});
sma = AddState(sma, 'Name', 'WaitForLeftPoke', ...
'Timer', 0, ...
'StateChangeConditions', {'Port1In', 'LeftDrinking'},...
'OutputActions', StimulusOutput);
sma = AddState(sma, 'Name', 'LeftDrinking', ...
'Timer', 0,...
'StateChangeConditions', {'Condition1', 'LeftDrinkingGrace'},...
'OutputActions', {});
sma = AddState(sma, 'Name', 'LeftDrinkingGrace', ...
'Timer', 0.75,...
'StateChangeConditions', {'Tup', 'exit', 'Port1In', 'LeftDrinking'},...
'OutputActions', {});

The errors I get (very often, at least once per session) are like these, where the timer referred by the error changes every time and the range is not limited to what I illustrate here:

Mouse 1:
prepared sma for trial 10 in: 0.0131 secs
Error while evaluating TimerFcn for timer 'timer-4'
Error: The USB serial port did not return the requested number of bytes.
prepared sma for trial 11 in: 2.6123 secs

Mouse 2:
prepared sma for trial 11 in: 0.0125 secs
Error while evaluating TimerFcn for timer 'timer-6'
Error: Unknown event code returned: 190

Mouse 3:
prepared sma for trial 13 in: 0.0125 secs
Error while evaluating TimerFcn for timer 'timer-7'
Error: Unknown event code returned: 245

From the first error, I deduce that sometimes my Win computer slows down significantly, but I don't know if there could be any other explanations.
I don't have any other programs running. I tried to monitor the activity in Task Manager but so far I haven't caught the culprit.

Do you have any suggestions? Are timer number and event code informative?

I appreciate your help.
Paola

Josh

Hello Paola,

It's hard to tell from the partial code.
Can you please send your behavior .m file(s) to support@sanworks.io?

Thanks,
-Josh

paola

Thanks, Josh. Will do.
Best,
Paola

Josh

Hello Paola,

I found the issue.

TrialManager requires your protocol to have a 'PrepareStateMachine' function (e.g. _line 98 here), to prepare the next trial's state machine struct. In your PrepareStateMachine function, there was a call to LoadSerialMessages() to program the state machine's serial message library. The state machine firmware can safely receive the state machine description during the trial using SendStateMachine(), but LoadSerialMessages() cannot be run mid-trial.

In your case, the messages are static - so you can move LoadSerialMessages() above the main loop to solve the issue.

If you need to load unique serial messages between trials, we have good news - FSM firmware v23 + Bpod Console v1.7 will support this (currently on the 'develop' branch of Bpod_Gen2, pending imminent release). With this release, you can use implicit serial messages with TrialManager, e.g.

sma = AddState(sma, 'Name', 'MyState', ...
    'Timer', 1, ...
    'StateChangeConditions', {'Tup', 'MyNextState'},...
    'OutputActions', {'ValveModule1', ['O' 3]}); % Open valve 3 on the valve driver module

Please let me know if moving LoadSerialMessages above the main loop resolves the issue, and if you choose to try the beta test please write in with any issues!

One final tip - once you introduce a reward delay, the state flow can access your CorrectEarlyWithdrawal state - but that state exits after 0s, so the machine will not have time to receive the next trial's state machine description. All routes out of the trial following the states listed in getCurrentEvents() must pass through a long enough interval to receive the next trial's state machine. 0.5s should work on a fast PC, 1s is safer.

Thanks,

-Josh

paola

Thanks a lot, Josh!
This makes a lot of sense, I will try it soon.