# Some questions

**URL:** <https://mworks.discourse.group/t/some-questions/967>\
**Category:** Support\
**Created:** [April 22, 2024, 3:37pm UTC](https://mworks.discourse.group/t/some-questions/967 "2024-04-22T15:37:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\
**Post date:** [April 22, 2024, 3:37pm UTC](https://mworks.discourse.group/t/some-questions/967/1 "2024-04-22T15:37:34Z")

</div>

Hi Chris,

Hope you enjoyed your break!

Following up on where the conversation was left off. The commands were sent at the places where I intended them to be. They were also sent at the exact same places for each trial. It might be an underlying design of the laser so we will try to see if we can figure out why. But we do like configuring each channel individually as needed as it gives us more flexibility.

One question related to the new laser plugin. I think we misunderstood when the channels would be configured to “off” with the new plugin. Now we have to turn the laser on before loading the animal’s experiment. However, we realized that we might not want the laser to be on since the beginning of the session. Sometimes we only need it to be on for some of the protocols happening later in the session. Is there a way to change this? Can this configuration happen when we turn on the laser instead of when we load experiments?

Also, a few more questions on our list that are not related to the laser but these are not urgent at all!

1. Does the time update\_display() takes depends on how many things we are drawing on the screen? It seems like it takes the system longer to draw two stimuli than drawing just one stimulus.
2. Is there a way to delete unused variable sets? We accidentally added too many new variable sets for the EyeLink starting values instead of updating the existing ones and now it’s getting confusing.
3. With the new nightly build, we have to load existing variable sets to get the EyeLink starting values after loading the experiments. The variable set was automatically loaded with the experiments with MWORKS 0.12.2 so it was one fewer step for us to do. We are wondering if there is a way to get that back so it will make the experiments more streamlined and one less thing for us to remember at the rig.
4. We were trying to read display distance from the system variables with the python script (codes pasted below) written by a previous tech. In the config\_Vpixx (attached), we defined read\_system\_variables() as following:

var display\_width = 0  
var display\_height = 0  
var display\_distance = 0

%define read\_system\_variables ()  
run\_python\_file(path = ‘read\_system\_variables.py’)  
%end

The read\_system\_variables.py looks like this (email is giving me trouble sending the original .py file but it only contains these four lines):

from mworkscore import getvar, setvar, message

main\_screen\_info = getvar(‘#mainScreenInfo’)  
message(main\_screen\_info)  
###display\_width = main\_screen\_info(‘’)

Then in the protocol, I did read\_system\_variables() then display\_distance = main\_screen\_info(‘distance’) but it didn’t work. How should we use this read\_system\_variables()?

[config\_Vpixx.mwel](https://mworks.discourse.group/uploads/short-url/j8tUSIfN4Pvd9qpBJ8XqxElFBXp.mwel) (7.47 KB)

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [April 23, 2024, 4:02pm UTC](https://mworks.discourse.group/t/some-questions/967/2 "2024-04-23T16:02:42Z")

</div>

Hi Taylor,

> Does the time update\_display() takes depends on how many things we are drawing on the screen? It seems like it takes the system longer to draw two stimuli than drawing just one stimulus.

Yes. Issuing the drawing commands for each stimulus takes a finite amount of time. The more stimuli you want to draw, the longer it takes.

But remember that the actual display update happens _after_ [update\_display](https://mworks.github.io/documentation/latest/components/update_stimulus_display.html) completes. As long as MWorks can issue all the drawing commands within a single display refresh period, the number of stimuli you draw has no bearing on when the actual display update takes place. (And if MWorks _can’t_ issue all the drawing commands in time, you’ll see a “skipped display refresh” warning.)

> Is there a way to delete unused variable sets?

Yes. Variable sets are stored in `$HOME/Documents/MWorks/Experiment Storage`. There’s a directory for each experiment with saved variables. Inside the experiment directory, there’s a subdirectory named `Saved Variables` that contains an XML file for each saved variable set. To remove a set, just delete its XML file. (You may need to close and re-open the experiment to update MWClient’s list of saved variable sets.)

> With the new nightly build, we have to load existing variable sets to get the EyeLink starting values after loading the experiments. The variable set was automatically loaded with the experiments with MWORKS 0.12.2 so it was one fewer step for us to do. We are wondering if there is a way to get that back so it will make the experiments more streamlined and one less thing for us to remember at the rig.

Variable sets are loaded automatically only when you load an experiment via a [workspace file](https://mworks.discourse.group/docs?topic=51) that includes the variable set. If loading your workspace isn’t loading the expected variable set, then I suggest checking the workspace file to confirm that it references the correct set. (You could also create a new workspace file after loading the desired variable set manually.)

> How should we use this read\_system\_variables()?

The Python code isn’t complete. It should look like this:

```auto
main_screen_info = getvar('#mainScreenInfo')

setvar('display_width', main_screen_info['width'])
setvar('display_height', main_screen_info['height'])
setvar('display_distance', main_screen_info['distance'])

```

Then, in your protocol, just use the value of `display_distance` as needed.

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\
**Post date:** [April 26, 2024, 2:59pm UTC](https://mworks.discourse.group/t/some-questions/967/3 "2024-04-26T14:59:17Z")

</div>

Hi Chris,

Following up on the update\_display() question. Does that mean if I command the queuing of all the stimuli at a non-time sensitive state, the actual update\_display() should not take different amount of time for drawing different number of stimuli?

The issue I am having right now is that for two protocols, I turn the laser on before update\_display\_and\_wait() with the expectation that the laser would be on about 16ms before the stimulus onset.  
For the protocol with one stimulus (protocol\_LaserAmplitudeWithStim), in the “Stimulus On” state, I turn the laser on, queue the stimulus, and then update\_display\_and\_wait(). The laser onset is about 20ms before the stimulus onset.  
For the protocol with two stimuli (protocol\_2afcLaser), in the 'Stimulus On - Pre-Saccade’ state, I queue all the stimuli first, turn the laser on, and then update\_display\_and\_wait(). However, the laser onset is about 30ms before the stimulus onset for this protocol.  
If I understood correctly, it seems like it is not the drawing commands taking a longer time for the second protocol but it is the actual update\_display\_and\_wait() that is? I’ve attached the two protocol if that helps.

The variable set issue and the read\_system\_display() question are tested and resolved. Thank you!

Best,  
Taylor

[protocol\_2afcLaser.mwel](https://mworks.discourse.group/uploads/short-url/25647KY5z3N0tqGTBmNXz6PfC4O.mwel) (52.1 KB)

[protocol\_LaserAmplitudeWithStim.mwel](https://mworks.discourse.group/uploads/short-url/neGwon7qL5YZnDdJuAeG2eU6914.mwel) (16.2 KB)

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [April 29, 2024, 2:23pm UTC](https://mworks.discourse.group/t/some-questions/967/4 "2024-04-29T14:23:03Z")

</div>

Hi Taylor,

> Does that mean if I command the queuing of all the stimuli at a non-time sensitive state, the actual update\_display() should not take different amount of time for drawing different number of stimuli?

No. Like I said, update\_display does some work for each stimulus, so if there are more stimuli, it will do more work. There’s no way to “pre-perform” that work.

FYI, queue\_stimulus does almost nothing – it just adds the stimulus to the list of stimuli to draw. No actual drawing work takes place until update\_display.

> The issue I am having right now is that for two protocols, I turn the laser on before update\_display\_and\_wait() with the expectation that the laser would be on about 16ms before the stimulus onset.
> 
> For the protocol with one stimulus (protocol\_LaserAmplitudeWithStim), in the “Stimulus On” state, I turn the laser on, queue the stimulus, and then update\_display\_and\_wait(). The laser onset is about 20ms before the stimulus onset.
> 
> For the protocol with two stimuli (protocol\_2afcLaser), in the 'Stimulus On - Pre-Saccade’ state, I queue all the stimuli first, turn the laser on, and then update\_display\_and\_wait(). However, the laser onset is about 30ms before the stimulus onset for this protocol.

I doubt the 10ms difference is all due to the additional stimuli. Even if you normally expect update\_display\_and\_wait to take about 16ms, there’s no guarantee that it’s going to do so. It all depends on where update\_display is invoked relative to the display’s refresh cycle, and you have no control over that. Sometimes the drawing will take place several frames ahead of the actual display update, so update\_display\_and\_wait will wait for 32ms (with a 60Hz display) or longer. Other times, you’ll be drawing for the very next frame, so the wait may be less than a single refresh period. I suspect this variability is the main source of the timing differences you’re seeing.

As I’ve said previously, you’re going to have a hard time aligning the laser and stimulus timing with the technique you’re using. I think this issue is an example of that difficulty. I’d really recommend switching to the [alternative technique](https://mworks.discourse.group/t/the-timing-between-turning-laser-on-and-stimulus-on/951/17) that I’ve described elsewhere.

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\
**Post date:** [April 29, 2024, 8:56pm UTC](https://mworks.discourse.group/t/some-questions/967/5 "2024-04-29T20:56:26Z")

</div>

Hi Chris,

Thank you for the reminder of the alternative technique! We go back and forth on whether we would like the laser to be depended on behavior or run on a separate clock like dispense\_juice. We will try this alternative technique and think about if and how we want to use the turn\_laser\_on macro in this case.

Thank you again for your help as we are exploring and figuring things out!

Best,  
Taylor

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [July 16, 2024, 1:36pm UTC](https://mworks.discourse.group/t/some-questions/967/6 "2024-07-16T13:36:31Z")

</div>