Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

eyetracking experiment crashes

edited November 2018 in PyGaze

Hi, everyone!
Could you help me with issue on eye-tracking experiment? The experiment crashes when it comes to pygaze start_recording functions, a log form the console is provided below (and it suggested to write on the forum:D). We use Eyelink 1000 plus and in dummy mode the experiment runs fine.
Thanks a lot for any help!

Python 2.7.13

  • Type "help()", "copyright()", "credits()" or "license()" for more information.
  • Use the "print([msg])" function in inline_script items to print to this debug window.
  • Inspect inline_script variables when an experiment is finished.

Starting experiment as ExperimentProcess-1
Expyriment 0.9.1b2-11-gc100ee8 (Python 2.7.13)
openexp.sampler._legacy.init_sound(): sampling freq = 48000, buffer size = 1024 experiment started at Fri Nov 23 19:42:58 2018 disabling garbage collection
starting recording ...
returned 0
Start realtime mode ...
Wait for block start ...
done ...
status message: start_exp
stopping recording ...
done ...
libeyelink.libeyelink.close(): Closing data file
libeyelink.libeyelink.close(): Transferring quickrun.edf to C:/Users/Display/Desktop/Liya/4 ??????\quickrun.edf

Python seems to have crashed. This should not happen. If Python crashes often, please report it on the OpenSesame forum.

time: Fri Nov 23 19:44:06 2018


  • Hi Liya,

    Oddly, your output suggests that actually things are going fine. The start_recording function is run, says it returned 0 (suggests no errors in starting the recording), then starts realtime mode fine, then successfully waits for the 'block start'. All of this seems didn't return any errors, which means the communication with the EyeLink is running fine.

    After that, it seems your experiment tries to set the status message on the EyeLink PC. After that you either close the connection, or the experiment crashed and therefore the connection closed.

    So, it seems from the info we have here that the start_recording worked fine, and that your crash occurred in status_message or in some other place that isn't in the output.

    What exactly is it that you are doing?


  • Hi Edwin,
    thank you for the comment! Yes, looks like something alike crash occurs. On the EyeLink PC the tracker program also closes down after this error, I used OpenSesame in another experiment with the same eyetracker and there was nothing like that. I'm not sure about, but seems like it happens with message within function "start_recording". There are messages in this experiment, which is sent by pygaze_log function, but seems like the experiment crashes before it has come to them
    I've attached the experiment. Could you take a look at it, please? I'll be very grateful for any ideas about a source of the problem or suggestions about things that could be tested to figure out what's going on.
    Thank you!

  • So you've used the tracker and OpenSesame and the PyGaze plug-ins in another experiment, and that does run? Could you confirm whether that other experiment still runs, please?

    If that other experiment runs using the very same software, it seems like something experiment-specific is at fault. For example, I couldn't check whether the file paths in your experiment are correct. There might be an incorrect filename there. Your generic path is ""IMAGE ([image_number]).JPG", which means all your images must be named IMAGE (1).JPG - IMAGE (50).JPG (without missing a number!), and that they are in the same directory as your experiment script. If one of these conditions is not met, the experiment will crash during the preparation phase of your first trial.

    The messages I was referring to in my last post referred to the ones generated by start_recording, which all come out like one would expect if start_recording ran as it should.

  • Hi all!

    Last time that I've asked, I just rebuild the experiment from scratch and, surprisingly, it starts working. Didn't figure out what was wrong. But we tried to launch a new other one and faced with similar problem again.
    It seems that it's induces not by "start_recording", but by a one of eye tracking functions (in dummy mode everything goes well!). The experiment is proceeding normally until the moment when it's coming to the end. At this moment, the tracker program on HostPC crashes (you can find the output, printed on the screen at that moment on the two first screenshots attached), after that the file manager on HostPC lunches automatically. PresentationPC shows respectively the crash of Python (see the last screenshot).
    Could you help me to figure out what's going on and how to fix it?


  • And here is the experiment

  • I've tried also attach the file with the exp, but get the message "You are not allowed to upload files in this category."

  • Hi Liya,

    (Your last comment was incorrectly marked as spam, hence it took a little while before it appeared.)

    Looking at your screenshots, the key message is probably the 'CABLE FAULT' (or perhaps one of the other error messages) that appears on the host PC. I suspect that the Experiment PC crashes as a result of that.

    If the host PC crashes like this, especially if it happens at random, it may indicate some kind of hardware failure. Or at least, that's my gut feeling. But the SR Research people will be able to tell you more about it. So I would post this on the SR Research support forum.


  • Thanks!
    We reached out to the SR tech support and they helped to fix it. Just in case if somebody faces the same problem, the following instructions may help:

    • update the Host tracking software to the latest version. Download the Host tracking software, DO NOT unzip it. Then, click the Configuration button in the WebUI, i.e., the web browser interface on the Display PC. Click the System Update button and choose the zip file you downloaded. It will take a seconds for the Host PC to update and restart.
    • press Ctrl+Alt-Q to switch to the FileManager interface on the Host PC, delete lastrun.ini and lastrun.pre from the /elcl/exe folder. Don't delete or modify any other files here.
Sign In or Register to comment.