Howdy, Stranger!

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

Supported by

parallel port can't be found by parallel_port_trigger

edited April 2016 in OpenSesame

Hi to all, i am trying to access the parallel port from opensesame by means of the parallel_port_trigger plucin. I installed it correctly (even though it seems to be missing the "duration" control compared to the demonstrative images on the internet). However I just can't make it see the parallel port. My parallel port address does not seem to be the default one (378), but rather some 5 digit address (translated from hexadecimal). Anybody knows a solution?

image

image

Thanks a lot in advance!
Luigi

Comments

  • edited 4:35PM

    Hi Luigi,

    The problem here is that OpenSesame fails to load dlportio.dll, which is the library used to access the parallel port. So the problem is not so much accessing the port, as it is loading the library required to access the port.

    Is there a file dlportio.dll in your OpenSesame program folder? If not, you can install it as described here:

    Cheers,
    Sebastiaan

  • edited April 2016

    Thankls a lot! I was not sure wether i had to install also the .dll file besides the plugin. Now that part is solved. However, I am encountering a second problem. Once it gets to the parallel port access it stops with the following error message:

    File "C:\Program Files (x86)\OpenSesame\plugins\parallel_port_trigger\parallel_port_trigger.py", line 126, in run
    TypeError: int() can't convert non-string with explicit base
    
  • edited 4:35PM

    Hi Luigi,

    Port value is in hex or in dec. Address range for the memory register is 0000 - FFFF. The standard address for the parallel port is 0x378, which is short for 0x0378. Because the first digit in the hex number is zero, it often will be left out. Your port value should be: 0xD010
    I will add a check and error message in the future to make this more clear.

    I forgot about the online documentation on cogsci, I will edit those pages shortly. Thanks for the reminder.

    I removed the duration option for the following reason. Some times people want to start the trigger at the start of the stimulus and end the trigger at the end of the trial (or some point within the trial). The duration parameter makes this impossible to achieve. On the other hand, with the duration free version you can create 'duration' yourself by inserting a start trigger item, a wait item/inline script and a stop trigger item.

    Writing this makes me think about a third option: adding a checkbox for duration and when checked create an input box for duration. Let the user decide if he/she wants the time dimension or not. Gonna work on that!

    Cheers,
    Bob

  • edited 4:35PM

    it WORKS!!! THANK YOU!! =D> =D> =D>

  • edited 4:35PM

    Hi Bob!

    I've asked this question in this discussion: http://www.cogsci.nl/forum/index.php?p=/discussion/comment/7249#Comment_7249 and someone pointed me here!

    Now when the trigger is sent, how does it coincide with the stimulus onset? For example, if I now just had a parallel_port_tigger item and then had an audio item, earlier, if the duration was 4 ms, I know that the audio file was played 4ms after the trigger was sent and so it was easy to correct that in calculation for stimulus onset (the lab I work in does ERP research and so it is important to know at a millisecond level when the stimulus was presented..). However now how do I know? The way it is now, does the trigger necessarily coincide with the next item (whether it is a sketchpad or sampler item)?

    Thank you so much!
    Grusha.

  • edited 4:35PM

    Hi Grusha,

    Nothing has changed in regard to the removal of duration. Without duration, you do not need to substract 4 ms and you can encapsulate the entire trial. For example send a code before the audio item and send 0 after the the audio item, or after the trial, whatever is relevant. In the latest version I brought back duration back as an option so you can still use it again.

    But I see a more fundamental problem in your setup. The trigger constitutes the start of the audio item in opensesame, this is not the same as onset time of the audio. I get around the 40 ms latency at best with the standard pygame audio item in opensesame. I measured this with an audio detector. You can correct for audio latency a couple of ways:

    1. use real time audio detection in your experiment and use the audio detection time as stimulus onset time stamp
    2. in advance to the actual experiment, measure latency with an audio detector and determine the mean latency and variance/rms for that pc. You can use the mean as estimator for the accuracy of the stimulus onset and the variance/rms as estimator for the precision of the stimulus onset.

    Cheers!
    Bob

Sign In or Register to comment.