# MWorks - Stopping a Protocol Early
**URL:** https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892
**Category:** Support
**Created:** [May 24, 2023, 2:00pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892 "2023-05-24T14:00:54Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Neel\_Agarwal](https://mworks.discourse.group/u/Neel_Agarwal)
#### Post date: [May 24, 2023, 2:00pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/1 "2023-05-24T14:00:54Z")
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
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 24, 2023, 5:51pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/2 "2023-05-24T17:51:31Z")
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 24, 2023, 5:51pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/3 "2023-05-24T17:51:31Z")
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 24, 2023, 5:57pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/4 "2023-05-24T17:57:23Z")
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](https://github.com/mworks/mworks-issues/issues/174) for several years now. It’s a very good idea, but I haven’t had a chance to implement it yet.
Cheers,
Chris
---
### Author:  [@Neel\_Agarwal](https://mworks.discourse.group/u/Neel_Agarwal)
#### Post date: [May 24, 2023, 6:31pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/5 "2023-05-24T18:31:20Z")
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
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 24, 2023, 6:57pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/6 "2023-05-24T18:57:58Z")
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 24, 2023, 9:21pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/7 "2023-05-24T21:21:55Z")
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
---
### Author:  [@Neel\_Agarwal](https://mworks.discourse.group/u/Neel_Agarwal)
#### Post date: [May 25, 2023, 2:49pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/8 "2023-05-25T14:49:39Z")
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](https://mworks.discourse.group/uploads/short-url/lHC0UelNFdqpLjZVGbzqludGbg2.mwel) (16.7 KB)
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 25, 2023, 4:17pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/9 "2023-05-25T16:17:01Z")
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
---
### Author:  [@Neel\_Agarwal](https://mworks.discourse.group/u/Neel_Agarwal)
#### Post date: [May 25, 2023, 4:42pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/10 "2023-05-25T16:42:03Z")
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
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [May 31, 2023, 2:15pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/11 "2023-05-31T14:15:18Z")
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](https://github.com/mworks/mworks-issues/issues/174). 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
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [June 21, 2023, 4:08pm UTC](https://mworks.discourse.group/t/mworks-stopping-a-protocol-early/892/12 "2023-06-21T16:08:10Z")