Reading Parallel Port as Response Device


Author
Message
Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 100K
Hmm, if the trial doesn't move on, that would indicate it's still waiting to receive the specified /posttrialsignal. The problem here likely is that /posttrialsignal only recognizes lpt, not lptdata (as per the documentation -- I don't have a suitable device for testing around at this very moment).

What's the device's status register state when the respective pins are low?

DrLand
DrLand
Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)
Group: Forum Members
Posts: 14, Visits: 38
I think the issue is that the /posttrialsignal doesn't work with reading from lptdata. Even though I can't control the pins that are "watched" by the lpt status register, it holds a value of (127). If I use /posttrialsignal = (lpt3, 127), then this works to stop the trial. However, this doesn't fix my orignal problem with cycling through my trials. So it appears that this is a limitation with the software. I'm not sure how to fix the problem at the moment.

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 100K
For how long does your device keep the pins high? Can you configure that duration?

DrLand
DrLand
Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)
Group: Forum Members
Posts: 14, Visits: 38
This isn't something that I can control. I am tracking the trajectory of a ball toss. When the ball crosses a start line, my motion analysis system will turn pin 2 to high. When the ball rolls past the finish line, the system turns pin 2 back to low. 

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 100K
Here's an idea. Simply have another <trial> check for the 'low' state instead of using /posttrialsignal. I.e., do

<trial checkportsignal>
/ stimulusframes = [1=button]
/ inputdevice = lptdata3
/ validresponse = (241)
/ branch = [trial.checkportstatuschange]
</trial>

<trial checkportstatuschange>
/ inputdevice = lptdata3
/ validresponse = (242)
</trial>

That should do the trick (provided I'm not missing anything).

DrLand
DrLand
Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)
Group: Forum Members
Posts: 14, Visits: 38
Bingo! That's it! The level of support on this site is unmatched. Thanks for all the help.

Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 100K
Great! And thank you for the kind words, too!

DrLand
DrLand
Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)
Group: Forum Members
Posts: 14, Visits: 38
Ok, to follow up on the previous script, I have run into another problem when reading inputs from the parallel port. I am wanting a sound stimulus to be played when a correctresponse occurs from the parallel port. Here is the code:

<trial lowtones>
/ stimulusframes = [1=lowtrials]
/ inputdevice = lptdata3
/ validresponse = (241, 244)
/correctresponse = (241)
/correctmessage = true(lowtone, 1000)
/ branch = [trial.trialendcheck]
</trial>

<trial trialendcheck>
/ inputdevice = lptdata3
/ validresponse = (244)
</trial>

The trial starts and stops fine, but no tone is played. However, if for instance I don't use the parallel port for the input, but base it on a keyboard command...the tone plays when the correct response is given. It's only when I'm using the parallel port input that I'm not getting the sound feedback.


Dave
Dave
Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)Supreme Being (1M reputation)
Group: Administrators
Posts: 12K, Visits: 100K
What happens when you use /responsemessage instead of /correctmessage?

/ responsemessage = (241, lowtone, 1000)

Also, what do the 'response' and 'correct' columns in the data file actually indicate for the given trial? Are the values recorded there '241' and '1', respectively?

DrLand
DrLand
Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)Esteemed Member (2.5K reputation)
Group: Forum Members
Posts: 14, Visits: 38
Hi Dave,
Thanks for your quick response. Your reply cued me in to the problem. I have it working now. It works with both the /responsemessage and /correctresponse.
Basically what was happening was...at the start of the trial, one pin I had set to go high, and another set to go low. At the end of the trial, the pins would switch in preparation for the next trial. Even though I was switching both pins at the "same" time, one pin was switching first and thus throwing a different value for a split second. So my data output file wasn't showing the correct value. I was able to fix this on the device side of things.

One final quick question: My trials are based on input from the parallel port, but it would be nice if I could /stop a block early with input from a keyboard. I believe I read in the documentation that you couldn't mix parallel port inputs with a keyboard input. I wasn't sure if there was any work around for this.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Explore
Messages
Mentions
Search