By Blackadder - 5/6/2015
We are facing massive problems with operating our Cedrus RB-830 response pads reliably under Inquisit. Without any indication of reproducibility, our lab computers frequently fail to detect a Cedrus response pad. Our scripts invoke the response pad like this:
<defaults>
/ inputdevice = XID_cedrus
</defaults>
<xid XID_cedrus>
/ product = responsepad
</xid>
All of our lab computers at least once every few days will fail to detect the response pad. The error message is
No XID devices detected. Besure the device is plugged in, turned on (if necessary), and the appropriate driver installed.
There are no preconditions which reliably lead up to the error. It will occur no matter if the computer was just booted up, woken up from hibernation, or had Inquisit successfully detect the response pad once, never, or multiple times before. Sometimes, only restarting the computer solves the problem, at other times trying to run Inquisit again and again until it finally detects the pad will suffice.
On all our computers, the XID device is either assigned to COM5 or to COM7. We have set a baud rate of 115200 and configured all response pads identically. The error occurs on different hardware (Core Duo, Core i5, Core i7), under multiple OS'es (Win7 64bit, Win 8.1 64bit) and with multiple versions of Inquisit 4. With Inquisit 3, we never had any such issues, hence we would assume Inquisit 4 to be the culprit.
How can we help to track down the bug?
Best wishes
Malte
|
By Dave - 5/6/2015
I've added your report to the bug tracker.
To start narrowing things down: Are either SuperLab or Cedrus' Xidon tool ( http://www.cedrus.com/download/files/xidon_1p2.exe ) able to successfully detect the response box when Inquisit is not? Or do they also randomly / occasionally fail to detect the RB-830 on those machines? Thanks!
Beyond that and probably entirely unrelated to the detection issue, I believe the /inputdevice attribute could be simplified to read
/inputdevice = XID
(or to include the port number or device name if multiple XID devices are attached to the machine).
|
By Blackadder - 5/6/2015
Thanks a million, Dave, I just downloaded the Xidon tool an installed it on all of our lab machines. Now let's hope for them to misbehave again.
And thanks for your other advice. I somehow had believed that using the <xid> element was the recommended way to go in newer versions of Inquisit and that its name was to be used as the inputdevice setting. We'll revert to just /inputdevice = xid, then!
I'll post again as soon as we got to use the Xidon tool on an undetected Cedrus box.
Bye, Malte
|
By seandr - 5/7/2015
Hi Malte,
Thanks for reporting this and sorry to hear about the issue. Using the xid element with auto-detection was the "recommended" way to use these devices. The main advantage is that it makes your script portable across machines where the device may be connected to different port numbers.
Obviously, auto-detection is intermittently failing for some reason, so best to fall back on Dave's suggestion. Specifically, you'll want to set /inputdevice = xid<n> where <n> is the port number. If you just specify /inputdevice=xid, we'll have to use auto-detect to find the device.
I'm sure you are busy, but it would definitely be helpful to know if the other tools that Dave sent are able to detect when Inquisit cannot. Of course, we'll try to reproduce the issue here as well.
-Sean
|
By Blackadder - 6/26/2015
Dear Sean and Dave,
we had time to address the issue. When the error occurs, the XIDon tool will also fail to detect the response box. As soon as XIDon sees the box again (e.g., after un-/replugging - which does not always work), Inquisit will, too.
We'll now be fixing all of our lab computers to a specific IRQ and text whether this dispenses with the bug.
Bye, Malte
|
|