MWorks timing errors

Support
1

Hi Chris,

I have been getting timing errors and Simon said he never used to get these errors, so I thought I would run them by you. Any idea why I might be getting these scheduling errors?

2

Attachment: image001.tiff (1.18 MB)

3

Hi Rosa,

The errors indicate that one or more scheduled actions instances aren’t keeping up with the schedule you’ve requested. So my first questions are:

  1. How frequently are you trying to run the action(s)?
  2. What’s happening inside the action(s)?

If you want to send me your MWEL file, I could take a look at that, too.

Cheers,
Chris

4

Hi Chris,

Have you had a chance to look at the code I sent you?

thanks,
Rosa

5

Sorry, I never received your code. Can you try sending it again?

Please remember to use a non-NIH email account. Also, attachments with the extension .mwel sometimes get marked as spam. To avoid this, I usually either compress the file into a ZIP archive or add a .txt extension to the filename before attaching.

Thanks,
Chris

6

ah, yes i sent the last email with a .mwel. so here it is as a .zip. and
here is the message that had accompanied it:

Hi Chris,

I am not sure which action isn’t keeping up (I can’t tell from the
warning). One big change between Simon’s old code and my new code is that
we are calling for more frequent temperature checks (perhaps this is the
scheduled action that is causing the issue?). We are also recording the
eye tracking data at the same frequency (every 50ms). I have cc’d Simon
since he helped me write the new code and may also have an insight (Simon -
was there any other action we added more frequent calls for?).

I have attached the .mwel file (now as .zip) for you to review. I have two
versions of the code, one that uses mworks for eye calibration and one that
doesn’t (otherwise they are the same, and the issue arises with both
versions of the code). I am attaching the version with the mworks
eye-calibration, but the issue arises when I run the actual experiment (not
the eye calibration). Please let me know if you need any of the support
scripts or further clarification. One more note, please don’t read too
much into the notes at the top of the .mwel file, as they were copied over
from Simon’s old code and may not accurately reflect aspects of the code in
its existing form (I should clean those up!).

Thank you,
Rosa.

7

Hi Rosa,

Thank you for re-sending the experiment file.

I see just one scheduled actions instance:

action/schedule (
    delay = 50ms
    duration = 50ms
    repeats = -999
    ) {
    action/blackrock_led_driver_read_temps recurring_temp_read (
        device = my_LED_driver
        )
    recurring_temp_read_array1 = temp_a
    recurring_temp_read_array2 = temp_c
    run_python_file ('/scripts/python_recurring_logger.py')
}

The recurring_temp_read_array variables don’t have any attached actions, so we need to consider only the blackrock_led_driver_read_temps and run_python_file actions.

Although I’m not certain how long the temperature readout takes, my expectation is that it should be much less than 50ms (likely only a few milliseconds, though I would need to test it to be sure). That leaves the Python script as the most likely culprit. Can you tell me what that script is doing? If it’s logging data to a file, then that could easily take more than 50ms.

If the Python code is the problem, probably the easiest fix would be to have different scheduled actions for the temperature readout and the Python script run, with a suitably longer duration for the latter, e.g.

action/schedule (
    delay = 50ms
    duration = 50ms
    repeats = -999
    ) {
    action/blackrock_led_driver_read_temps recurring_temp_read (
        device = my_LED_driver
        )
    recurring_temp_read_array1 = temp_a
    recurring_temp_read_array2 = temp_c
}

action/schedule (
    delay = 500ms
    duration = 500ms
    repeats = -999
    ) {
    run_python_file ('/scripts/python_recurring_logger.py')
}

Cheers,
Chris