I believe Yasmine introduced us in a former email. I’m currently taking over developing new MWEL code for Yasmine’s lab and I had a question that involves sending event codes to the blackrock system. I’ve run into an interesting error where when I set the amount of reward dispensed to a value lower than 300ms, there seems to be a malfunction when sending event codes to blackrock for subsequent analysis in Matlab.
In my experiment protocol, two events about the presented stimulus are sent right after each other in a state called ‘Trial Initialization’ (line 338 of protocol_2afc.mwel) which normally give me an equal number of values when reading them in on Matlab, however, for a reason I believe to be due to the dispensing of reward, there seems to be some sort of delay where other event codes are sent in-between the information about the stimulus. Whenever, I set the amount of reward dispensed to a value of 300ms or higher then there isn’t a delay but as soon as the reward is less than that, this error pops up.
I’ve attached a copy of the protocol in question, the event code .mwel file and a couple of screenshots of the errors I’m receiving when looking at the data in Matlab. Please let me know if you need any more clarification and I appreciate any help you can offer.
From the images you shared, it looks like the “other event codes” are all 10020, which corresponds to e_reward_off in config_Event_Codes.mwel. The MWEL files you sent don’t include a definition of the macro dispense_juice, but I do have a version from another of Yasmine’s experiments, which looks like this:
var juice_dispensing = 0 {
if (juice_dispensing == 1) {
vpixx_dout_juice_dispenser = true
vpixx_send_blackrock_sync_word(e_reward_on)
}
if (juice_dispensing == 0) {
vpixx_dout_juice_dispenser = false
vpixx_send_blackrock_sync_word(e_reward_off)
}
}
var vpixx_message = 0
%define dispense_juice (duration)
vpixx_message = duration
report('Dispensing juice for $(vpixx_message / 1000) ms')
pulse (
variable = juice_dispensing
duration = duration)
%end
If this is similar to the version you’re using, then I think it’s clear what’s happening.
Invoking dispense_juice causes the variable juice_dispensing to be set to one and then zero, with duration microseconds in between, using a pulse variable action. In addition to turning the juice pump on or off, each assignment to juice_dispensing also involves sending a code (e_reward_on or e_reward_off, respectively) to Blackrock.
The root of the issue you’re seeing is this: The first assignment (to 1) performed by the pulse action is synchronous, meaning it happens immediately, before the action finishes executing. However, the second assignment (to 0) is asynchronous: It happens on a separate thread, after the experiment has finished the pulse action and moved on to other actions. This is undoubtedly exactly why dispense_juice uses a pulse action, as it prevents juice dispensing from blocking further execution of the experiment. But it also means that the sending of the e_reward_off code can happen at any time.
Presumably, if the juice duration is 300ms or more, the experiment is able to finish sending codes in the “Trial Initialization” state before the e_reward_off code is sent. But if the juice duration is less than 300ms, e_reward_off is sent while “Trial Initialization” is still executing, and you end up having e_reward_off mingled in to the stream of other codes.
All that said, this doesn’t seem like an error in the design or execution of your experiment. Rather, it seems like you need to adjust your MATLAB code to filter out events you aren’t interested in (or, alternatively, extract only the codes that you are interested in). Since the end of juice dispensing happens asynchronously, it’s always going to be possible that e_reward_off will end up in places you weren’t necessarily expecting it, so your MATLAB code should handle that case gracefully.