Hi Chris,
I hope all is well. I had a question about stopping an experiment before it finished in MWorks.
Sometimes when we’re running a protocol, we feel as though we got enough repetitions to move forward with our experiment and hit the red stop button. In doing so, we don’t give the protocol the opportunity to reach its last state (for us “End Task”) which is critical to returning certain stimulus parameters back to their starting values.
An example would be our “Mapper” protocol which takes a certain center position and moves the stimulus around that point. If we stop early for whatever reason and restart the protocol quickly, we end up changing that center position (and often don’t notice) which effects our ability to properly map out neuron response properties.
I was wondering if it is possible to send a protocol into a specific state when we hit the stop button so that before the protocol truly ends we can return stimulus parameters back to their original values.
Let me know if that was clear. Thanks.
Best,
Neel
Hi Neel,
Can you just reset the stimulus parameters at the beginning of the protocol, instead of at the end? That seems like the simplest solution.
More generally, adding support for actions that run after the stop button is pressed has been on my to-do list for several years now. It’s a very good idea, but I haven’t had a chance to implement it yet.
Cheers,
Chris
Hi Chris,
For certain parameters that solution works well. For example, when I need to change the amount of blank trials I want to present for a given experiment, I set it at the beginning of the protocol so that it remains consistent every time I hit play. In the “Mapper” example I previously gave, I can’t reset the stimulus position parameters at the beginning because the protocol itself needs to receive a stimulus position as input to build a matrix of stimulus positions around that value. The protocol inherits the stimulus x and y position, stores it in a holder variable, creates a matrix of positions, changes the stimulus x and y position based on the matrix then returns the stimulus x and y position from the holder variables.
This particular issue arises in some of our other protocols as well so if we could push on that fix it would be greatly appreciated. Happy to zoom about it if I’m not begin clear about the problem.
Cheers,
Neel
Hi Neel,
Sorry, I still don’t see why you can’t just move the reset code to the beginning. Can you share the “Mapper” protocol that you described? Maybe I would understand if I could see all the details.
Thanks,
Chris
Hi Chris,
I attached the “Mapper” protocol that I was referring to.
In lines 36-37, you see that we save the stimulus x and y position (stimulus_x & stimulus_y) into holder variables. We build a map of positions based on this value then we systematically vary the stimulus_x & stimulus_y throughout the experiment. The problem is that the input to the protocol is the very same variable that gets systematically changed in the protocol.
If you can see a solution that would be greatly appreciated.
Best,
Neel
protocol_RF_Mapper.mwel (16.7 KB)
Hi Neel,
Thanks for sending the protocol.
Where do the initial values for stimulus_x and stimulus_y come from? Are you inputting them via MWClient’s variables window? If so, why not assign to map_stimulus_x and map_stimulus_y directly, and then never modify those in the protocol?
Chris
Hi Chris,
I was considering that as a fix but that would significantly change the flow of our experiment. The stimulus_x and stimulus_y parameters are the actual values for the stimulus position that were presented in a previous protocol (our experiment is composed of a series of protocols). We don’t manually input those parameters they are inherited at the end of a different protocol. We want to avoid a user input because that’s prone to error when we are multitasking with neural recordings, note-taking, etc.
Hope that explains it.
Best,
Neel
Hi Neel,
Thanks, I think I understand now.
It seems like the difficulty comes from trying to use a single pair of variables (stimulus_x and stimulus_y) both to set the position of stimuli on screen and to pass stimulus location information between protocols. What if you introduce another pair of variables (maybe saved_stimulus_x and saved_stimulus_y) to do the second job? You could assign to them in a protocol that proceeds RF Mapper (wherever the stimulus position of interest is determined), and then RF Mapper could just read them and not bother with map_stimulus_x and map_stimulus_y.
To be clear, I’m not trying to argue against post-stop actions. Like I said, that’s a good idea with many potential uses. However, it’s also going to be non-trivial to implement, so I think the best way to solve your immediate problem is by modifying your protocol(s).
Cheers,
Chris