I would like to use one computer (VE1) to run a virtual environment simulation program and a second computer (SL2) to run a SuperLab program. I would like to have the VE1 computer send inputs to the SL2 computer. I would like to find out how it might be done.
The SL2 SuperLab program is straightforward and I can write it, if it were the only program. However, it uses an RB-730 keypad for responses and I’m measuring response times, so I like to use it in XID mode.
I would like the VE1 computer to send signals to the SL2 computer at certain points and I need SuperLab to accept them as Input so that they can be programmed to initiate an event that is waiting for a signal from VE1. The communication does not have to be sophisticated. VE1 generates a string of events at known locations that are visited in a fixed order. All critical timing is done in SuperLab. The signal from VE1 would act as a “Start” key to initiate a trial. SuperLab on SL2 would present a display and collect a response on the RB-730 keypad.
Are any of the following feasible?
(1)Use the Accessory Cable together with the RB-730 to send a signal from the VE1 computer. I only need 2 responses (2 keys) for the SuperLab program on SL2. I also could put the response switches in a separate box and run them thru the Accessory cable together with the signal from VE1. The responses and the VE1 signal would never be present at the same time. However, I need response timing data, so the XID mode would be best. The timing of the event signal from VE1 is not critical. Could we set it up so that the 2 responses events were coded as 2 RB-730 keys and the VE1 signal was coded as a third key? I assume that any input thru the Accessory Cable and the RJ-45 connecter would have to be TTL.
(2) If (1) above isn’t feasible, would it be possible to use 2 RB-730 keypads, one for the VE1 computer event signal and the other for the 2 responses? I notice that SuperLab version 4.08 now accepts more than one USB. Does the Input now allow input from 2 different device types concurrently? I am currently using version 4.07b.
(3) Can I send events from the VE1 computer to the SL2 computer using the PCI-DIO24 I/O Card. How would they show up as Input in SuperLab? I assume that this would be TTL output from VE1 to TTL input via the Measurement Computing PCI card in SL2.
(4) Is there any way that I can have the 2 computers communicate via a TCP/IP “socket” via an Ethernet connection. I could set up a local area network between them, but I’d need to be able to trigger events in the SuperLab program on SL2.
Although the RB-730 has the ability to accept input from the Accessory Connector, SuperLab does not currently take advantage of that. TCP/IP communication is not supported either.
Yes, you can send events from the VE1 computer to the SL2 computer using the PCI-DIO24 I/O card. To see how they would show up in SuperLab, click on the Experiment menu, then click on Participant Input. When the dialog appears, enable “Measurement Computing I/O Card”.
Setting SuperLab input parameters for TTL I/O input
I have configured my VE1 computer to send TTL pulses to trigger events on my SL2 computer. Both computers use the PCI DIO24 I/O board. The VE1 uses an output channel and the SL2 computer uses an input channel. The SL2 computer is a slave to the VE1 computer, which triggers events on SL2 at the appropriate times.
VE1 reliably triggers SL2 events when we send an output pulse from VE1 to SL2.
However, SL2 sees ghost inputs when VE1 is not sending a signal. The output record of SL2 says that it received the correct input event. We only trigger an event if a signal on the correct channel is received. VE1 output record says it is holding constant and not sending any TTL output. These events occur infrequently about 1 every 5 hours but variable over a range of about 2 hours to 8 hours. This is enough for us to lose many subjects when the 2 computers get out of synch.
The 2 computers are connected with a short (1 foot) shielded & grounded cable with only 2 channels wired together (only one channel is used).
How can these ghost triggers be eliminated. Tech support from Measurement Computing has not been able to help.
I can adjust the output characteristics of TTL pulses. However, I can’t find a way to adjust the input characteristics required to trigger an event input. Is there a way to adjust TTL input requirements that must be met before an event will be triggered. (for example double pulses)
I’d appreciate advice. I have been trying to solve this problem for at least a month. There doesn’t seem to be anything wrong with the boards. We swapped boards and the problem is the same. We measured the output signal on VE1 using an oscilloscope and we are getting a pulse of just short of +5v as expected. The SL2 board does not ghost trigger SuperLab events if it is not connected to the VE1 computer’s PCI DIO24 board’s output (TTL cable is disconnected from the SL2) .
I have configured my VE1 computer to send TTL pulses to trigger events on my SL2 computer. Both computers use the PCI DIO24 I/O board. The VE1 uses an output channel and the SL2 computer uses an input channel. The SL2 computer is a slave to the VE1 computer, which triggers events on SL2 at the appropriate times.
VE1 reliably triggers SL2 events when we send an output pulse from VE1 to SL2.
However, SL2 sees ghost inputs when VE1 is not sending a signal. The output record of SL2 says that it received the correct input event. We only trigger an event if a signal on the correct channel is received. VE1 output record says it is holding constant and not sending any TTL output. These events occur infrequently about 1 every 5 hours but variable over a range of about 2 hours to 8 hours. This is enough for us to lose many subjects when the 2 computers get out of synch.
The 2 computers are connected with a short (1 foot) shielded & grounded cable with only 2 channels wired together (only one channel is used).
How can these ghost triggers be eliminated. Tech support from Measurement Computing has not been able to help.
I can adjust the output characteristics of TTL pulses. However, I can’t find a way to adjust the input characteristics required to trigger an event input. Is there a way to adjust TTL input requirements that must be met before an event will be triggered. (for example double pulses)
I’d appreciate advice. I have been trying to solve this problem for at least a month. There doesn’t seem to be anything wrong with the boards. We swapped boards and the problem is the same. We measured the output signal on VE1 using an oscilloscope and we are getting a pulse of just short of +5v as expected. The SL2 board does not ghost trigger SuperLab events if it is not connected to the VE1 computer’s PCI DIO24 board’s output (TTL cable is disconnected from the SL2) .
PCI DIO24 input To SuperLab 4 --Noise Problem Solved
Fyi, I named the two computers by program used and ID #. VE1 referred to the master computer #1 running a VE program. SL2 referred to the slave computer #2 running SuperLab. I am using version 4, not version 2.
However, I have solved the PCI DIO24 I/O board connection problem since my last query.
I did two things concurrently:
I plugged both computers, monitors & other equipment in the experimental setup into an uninteruptable power supply, UPS.
I put a 2200 ohm pull down resistors on each channel’s linking line on the connection cable, Each resister is between the signal channel pin and ground pin.
I suspect that #2 was more important, but the electrical noise problem was eliminated, so I stopped playing around with the setup.
For the future, it still would be useful if there was more control of SuperLab's input so that it could be set to detect more specific TTL signals such as setting the pulse width range, number of pulses, etc required to trigger an event. SuperLab input seems to act as a very simple voltage threshold trigger. Even very brief transients trigger the input event, if they exceed the input threshold.
Being able to link two computers adds considerable capability to SuperLab. I have played with linking two computers, both using SuperLab and this works too. It allows multiple screen presentations and multiple responses, linked together with more flexible rules or actions.
You are correct about the resistors being a must. Pull up or pull down resistors set the “default” state of the input and they are a pre-requisite, otherwise a lot of electronic devices will be in an undetermined state. There isn’t much SuperLab can do about it.