Hi José,
Could you elaborate on the code not working? In what sense? We have used it with 2 macs and 2 PC’s over here without incident, while the IOhub version was inconsistent and slowed down the computers excessively. I’d be curious to work out what went differently for you versus for us. As you may have seen above from my conversations with Richard and Jon, the end goal is to make this functionality more accessible to researchers, and so if there is a way to make implementing functionality this more transparent, then that would be good. You know… aside from making money less of a barrier for researchers who want to be able to use tools like these (which is also nice).
Cheers,
Kyle
Hi Kyle
I’m attempting to get our PST boxes to work with psychopy (with limited coding experience) Would you be willing to share your experiment file so I can see if I can work backwards for how to put it into our experiments. I tried following your current guidelines but it seems to skip past the stimuli presentation trials (straight from instructions to debrief). I’ve probably done something silly, so it would be good if I could troubleshoot with a working example.
Thanks
Susie
Hi Susanna,
Sure I can share the experimental file. However in all likelihood what you are describing is that you don’t have any gaps between trials. The response box sends a continuous stream of characters to the computer, and so it continues to register the button press until you release it.So instead of registering whether a button has been pressed, it registers whether or not the button is currently being pressed. Since pstbuttonbox works more efficiently than the iohub configuration, this means that the experiment can cycle through in its entirety before a human being can lift their finger. Darcy is working on coding something to get around this, but in the meantime you can add a small gap between trials. DvDFT.psyexp (21.7 KB)
<img src="/uploads/psychopy/original/1X/b5545dd11e86734689f0ed0fd842pstButtonBox.py (4.3 KB)
ae2b2c6cd9c7.jpg" width=“690” height=“297”>
Kyle
1 Like
Hi José,
It’s confusing to me why that code works. What the code is doing is creating a loop (that is what the “while true:” part does) that will run until there is a signal from the box. The part that says “if pstbox.getEvents()” is basically a test of whether or not there is something in the input buffer of the box. That this, this loop should only run as long as it takes for there to be a signal from the box and then quit, regardless of what that signal is. There is no test for whether or not a button is not being pressed, so I think all this loop would do is slow down your program a bit. My guess as to why this is working is that it is effectively like adding a small pause at the end of your routine.
I have found a way to fix this using our code. I have modified the pstButtonBox class. Here is the updated code. As Kyle says above, make sure you put this into the same directory as your experiment file:
pstButtonBox.py (4.5 KB)
The main addition to this new class is a method called waitForKeyUp. This method will pause the program until no button is being pressed on the box. To see it in action, I am posting a modified version of the test experiment file you posted above. It replaces the iohub stuff with our code. I have also also included a lot of comments in the code component of the first routine (i.e., the “INST” routine) so that you (or anybody else who wants to use this) can better understand what this code does.
test-modified.psyexp (20.3 KB)
Let me know if this works.
Hi Susie,
I have a response to José that should help with your problem as well. This is the fix that Kyle mentioned I was working on. If, as Kyle surmises, the problem is that you have no pause between stimuli (i.e., you do not have an inter-trial interval in your design), then it might be that one button press is long enough to advance through all your stimuli. If you look at the post I made for José, you will see that I have included an updated version of pstButtonBox.py and that the putting the method pstbox.waitForKeyUp() in the End Routine section may fix your problem. This method pauses the program until the key is lifted up.
Let me know if this helps.
Darcy
Thanks Darcy & Kyle, Will take a look when I get a chance (being pulled in multiple directions at the moment so i’ve had to put this on the back burner for a couple of days). Really appreciate all your help.
Hello Darcy,
I just tried this, but it still won’t work. I get a message saying that pstbox.flush() is not defined. I did put the file you attached in the same directory as the experiment, though.
I also get a warning that reads "j = self.port.in_waiting
AttributeError: ‘Serial’ object has no attribute ‘in_waiting’
I wonder if it has to do with the version of Psychopy we’re using or the type of Eprime response box…
thanks,
José
Hi José,
You should always be running the most recent version of PsychoPy if you can. Is there a reason why you cannot run the most recent version? What version are you running?
I think the version is the problem. The warning that says that "Serial’ object has no attribute ‘in_waiting’ indicates that this a old version of pySerial (the python library that interfaces with serial ports). In the old version of pySerial, the in_waiting was a method, which would be called by in_waiting(), rather than an attribute, and this, I think, is causing the error. Also, the line “j = self.port.in_waiting” is in the flush method, so a problem with that line would explain why it is telling you that pstbox.flush() is not defined. The python that comes with the newest version of PsychoPy, however, should have the more recent version of pySerial and therefore should not have this problem. If there is a reason why you cannot upgrade to the newest version of PsychoPy, let me know and I will see if I can modify the library to work for you.
Hi Darcy,
Thanks for your email. I’m running v1.83.04 (fairly recent). The only reason why we haven’t updated is because we are worried that all other experiments might be affected by the update. We did an update in October, and the syntax for the parallel port code component of the EEG experiments stopped working (this we have figured out and corrected already). So I’m trying to avoid that, because–as is probably obvious by now–I’m not that familiar with programming/coding.
thanks!
best
josé
Hi José,
Okay. Try this one and let me know if it fixes the problem and/or if you have any other problems. You don’t need to change your code in your experiment file, you just need to replace the pstButtonBox.py file with this one:
pstButtonBox.py (4.7 KB)
Cheers,
Darcy
Hey!
I just tried it, but it gives me the same error message. Thanks a lot for your help, by the way.
best
josé
Hi José,
I have updated the pstButtonBox.py file in the above post, so go ahead and download it again and try it. That is, instead of reposting it in this message, I edited my previous message to include the updated file. I didn’t test my code the first time I corrected it, but I did this time, and it works in PsychoPy 1.83.04. Let me know if it works for you.
Cheers,
Darcy
Dear Darcy,
It works! Thanks a lot!
I also imported the code that Kyle posted to calculate and print out RTs, and it seems to work also.
I’m extremely grateful to everyone in this forum for being so generous with their time.
Best wishes,
José
Hi Kyle,
Sorry for the late response. Apparently, the issue was the Psychopy version I was using. A number of functions were reported as non defined. Darcy figured that out and helped modify the pstButtonBox.py file accordingly, and now it works.
Thanks
josé
Hello everyone,
and thank you for this very useful thread.
For my next experiment I will be using EGI. I wrote a lexical decision task that does whatever I need it to do, but I need to have use the EGI-branded response box we have in the lab. It turns out that that button box is designed to work seamlessly with E-Prime, as it is first plugged into a E-Prime Button Box and then connected to the PC. The EGI support guys couldn’t help me in setting up the box with PsychoPy, although one of them sent me the URL address of this thread. I tried to implement what you guys have done in my script, however I couldn’t make it work, probably because of this is additional issue to deal with - and I hope someone could help out.
Many thank in advance,
-Roberto
Hi Roberto,
I don’t want to put words in anyone’s mouth, but I am not sure what we can do. Are you able to get the button box itself to work, or is it this EGI part that is not working?
Also, I am haven’t the foggiest as to what EGI is, and am pretty sure we don’t have one to play with, and so that is also problematic for generating ideas.
One thing that I can offer that may or may not be helpful is that the system that we worked out for using the button box with psychopy, involved creating a novel piece of code for running the box. That piece of code was specifically to read the button responses and contains no references to other potential functions of the box (such as the mic plug-in or the other screen refresh… something I don’t remember). That was actually part of the idea, as IOhub was running very slowly on our computer and so we wanted something that would run with a little boiler plate and unnecessary clutter as possible. So if you could figure out what exactly EGI is transmitting and alter our code to interpret that, then you might still have some options here.
Cheers,
Kyle
Hi Kyle,
EGI is a water-based EEG technique that avoids using electrolyte gel to activate the electrode signal.
I had imagined that this would have been a hard guess, but it was worth trying! 
I’ll try to come up with something.
Thank you for replying!
-Roberto
Hi Roberto,
Really? That is an add on to the e-prime button box?
Also, as my response may imply, this sounds to be way way over my pay grade. I wouldn’t even know where to begin with such a system. Best of luck though!
Kyle
Can the above code workaround be used with foot pedals… these plug into a 40 pin receptacle inside the box and, as I understand it, can be called using the same numbers as the buttons… I have managed to get the SRB working with e-prime, but I need to use foot pedals rather than the buttons themselves.
Well aod,
Technically anything could be used with anything, however this code doesn’t have anything in it for foot pedals at present. If you actually go into it, its no more than a few pages of code. The idea was to create something that can interact with the button box that wasn’t so processor intensive that it crashed the computer or ruined rt estimates (which other options tended to do in some cases). There we were three of us in our department that worked on this, and I mainly worked on the part to do with our experiment itself. The person who wrote the code to talk to the box is not in this community.
So if you know how to do this, I see no reason you could not look through what we have and see if you can reapply it to the foot pedals (it is not complicated as these things go). If your level of coding knowledge is anywhere near mine, however, then you are probably better off going to one of the threads specifically about using the e-prime foot pedals (for which I am seeing several recommended threads).