Interrupt Experiment and Return Without Resetting Selection

Support
1

Dear Chris,

I am trying to build an experiment with more than one protocol, let’s say Eye Calibration and Main Experiment. During the main experiment, I want to be able to pause it and change to Eye Calibration protocol. After I do the recalibration, I want to come back to the Main Experiment, resuming it without resetting all the selections that have been made. I don’t want to come back and restart the Main Experiment from the beginning.

I have tried pausing it from MWorks Client but changing protocol results in the reset of everything in the other protocol. This means I will have do the other protocol the beginning. Is there a way around this problem?

Thank you
Tenri

2

Hi Tenri,

Changing protocols causes all paradigm components (blocks, trials, etc.) to be reset. However, it does not have any effect on variables (including selection variables). Therefore, if you can store all the relevant state information for your protocol in variables, you should be able to stop and resume it as needed.

I think the main change you’d need to make is to stop using the selection mechanisms built in to paradigm components. Instead, use selection variables, which won’t automatically reset on you. Also, when your protocol starts, it probably will need to check whether it’s starting “fresh” or resuming a previously-started run. In the latter case, it should skip various initialization tasks (such as resetting selection variables).

If you can share an example protocol with me, I can give more specific information about how this could work.

Cheers,
Chris

3

Hi Chris,

Thanks for the fast response.

Attached is the example protocol. It is unfinished but it should show the logic of the experiment. What I want to do is do a calibration in the beginning of the session and then start the Sampling Protocol. I will almost certainly need to pause the Sampling Protocol to do a recalibration when needed, which means changing protocol.

The two most important variables are SOA (31 possible values) and hemifield (2 possible values), which are in the range replicators of Sampling Protocol. I want to have an equal number of valid trials, 30 trials, for every condition (31 x 2 = 62 conditions), presented in random order.

How do I make this work?

I also have a second question, if you don’t mind. I want to calculate reaction time, which is the time between target presentation and saccade to “target”. Saccade to target is defined as the time when IO_target1_fixated or IO_target2_fixated change its value to 1. Time of target presentation is the time stamp of Display Update event of “target”.

Is this good enough? Or should I get a time with now() right after I present the target (Update Stimulus Display) and use this as an approximation of “target” presentation time?

Best
Tenri

4

Hi Tenri,

Sorry for the delay in responding.

I want to have an equal number of valid trials, 30 trials, for every condition (31 x 2 = 62 conditions), presented in random order. How do I make this work?

I’ve attached a short example that demonstrates how to do this, while also letting you stop and restart the protocol. (It’s written in MWEL, but everything in it can be done in an XML-based experiment, too.)

The example contains two protocols. “Main Protocol” performs the 30x62 trials you described, while “Other Protocol” just logs a message to the console. The main protocol stops itself at random intervals, which gives you a chance to run the other protocol. When you restart the main protocol, it picks up where it left off, without repeating previously-completed trials.

One aspect of your task that complicates things slightly is that you’re making random selections over combinations of two variables (SOA and hemifield). To handle this, the example uses two additional variables: SOA_hemifield, whose value is a list of lists containing all possible combinations of SOA and hemifield; and SOA_hemifield_index, a selection variable used to draw random SOA+hemifield combinations from SOA_hemifield.

Hopefully this will make sense. If you have any questions, please let me know.

Time of target presentation is the time stamp of Display Update event of “target”. Is this good enough? Or should I get a time with now() right after I present the target (Update Stimulus Display) and use this as an approximation of “target” presentation time?

You should stick with your current method. The time stamp of the relevant #stimDisplayUpdate (or #announceStimulus) event is the best estimate MWorks has for when the stimulus will start to appear on the display. The only way to do better is to measure the stimulus onset with a photodiode.

If you want to use the predicted output time inside your experiment, set the predicted_output_time parameter of the update_stimulus_display action to the name of the variable in which to store the value.

Chris

5

Attachment: persistent_selection.mwel.zip (1.01 KB)