calibration error message

1
We're trying to calibrate a monitor on a Dell Precision 390 running Windows XP Service Pack 3.

The PR-650 is connected to a usb port via an Ultra U12-40958 USB to DB9 and DB25 Parallel Adapter with XP drivers installed. Device manager recognized the adapter, and we assigned it to COM5 to correspond with the default port in PR650init and CMCheckInit.

When we try to run the calibration, or CMCheckInit on it's own, we get the following error:

Error in function OpenSerialPort: Usage error
Error opening serial port device COM5 - The serial port is already open, close it first! (5) [EBUSY EPERM]. Could be a permission problem as well.

??? Error using ==> IOPort
Usage:

[handle, errmsg] = IOPort('OpenSerialPort', port [, configString]);

Error in ==> PR650init at 64
hPort = IOPort('OpenSerialPort', portNumber, handshakeCode);

Error in ==> CMCheckInit at 130
stat = PR650init(portNameIn);

We have tried manually closing COM5 using fclose, and get verification that it is closed. However, on running CMCheckInit again, it still thinks the port is open.

Does anyone have any suggestions for how to fix this?
2
Error code 5 is "ERROR_ACCESS_DENIED":

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx

So it is not the case that the port is already open, but for some reason you can't access it. Maybe something misconfigured in the device settings control panel?

-mario

--- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
>
> We're trying to calibrate a monitor on a Dell Precision 390 running Windows XP Service Pack 3.
>
> The PR-650 is connected to a usb port via an Ultra U12-40958 USB to DB9 and DB25 Parallel Adapter with XP drivers installed. Device manager recognized the adapter, and we assigned it to COM5 to correspond with the default port in PR650init and CMCheckInit.
>
> When we try to run the calibration, or CMCheckInit on it's own, we get the following error:
>
> Error in function OpenSerialPort: Usage error
> Error opening serial port device COM5 - The serial port is already open, close it first! (5) [EBUSY EPERM]. Could be a permission problem as well.
>
> ??? Error using ==> IOPort
> Usage:
>
> [handle, errmsg] = IOPort('OpenSerialPort', port [, configString]);
>
> Error in ==> PR650init at 64
> hPort = IOPort('OpenSerialPort', portNumber, handshakeCode);
>
> Error in ==> CMCheckInit at 130
> stat = PR650init(portNameIn);
>
> We have tried manually closing COM5 using fclose, and get verification that it is closed. However, on running CMCheckInit again, it still thinks the port is open.
>
> Does anyone have any suggestions for how to fix this?
>
3

Hi Stuart,
As a diagnostic test, try using a free terminal emulator to talk to the PR-650.  I use Zterm on OS X to test serial port interfaces and there are similar programs for Windows.  In the terminal emulator set the the rate, baud, and parity etc. parameters to match the PR-650 specifications and set the com port to match your system configuration.   Reboot the system first to be certain that you have cleared residual state from your previous attempts under MATLAB.  If the terminal emulator fails and especially if it gives a similar error to what you have seen using the PTB, then you have excluded anything running in MATLAB as a possible cause this failure.

Using the terminal emulator also gives you an easy way to test with the USB adapter assigned to different COM ports, just in case the choice of COM ports makes a difference. 
   
- Allen



On Jan 21, 2013, at 8:18 PM, Mario wrote:

 



Error code 5 is "ERROR_ACCESS_DENIED":

http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx

So it is not the case that the port is already open, but for some reason you can't access it. Maybe something misconfigured in the device settings control panel?

-mario

--- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
>
> We're trying to calibrate a monitor on a Dell Precision 390 running Windows XP Service Pack 3.
>
> The PR-650 is connected to a usb port via an Ultra U12-40958 USB to DB9 and DB25 Parallel Adapter with XP drivers installed. Device manager recognized the adapter, and we assigned it to COM5 to correspond with the default port in PR650init and CMCheckInit.
>
> When we try to run the calibration, or CMCheckInit on it's own, we get the following error:
>
> Error in function OpenSerialPort: Usage error
> Error opening serial port device COM5 - The serial port is already open, close it first! (5) [EBUSY EPERM]. Could be a permission problem as well.
>
> ??? Error using ==> IOPort
> Usage:
>
> [handle, errmsg] = IOPort('OpenSerialPort', port [, configString]);
>
> Error in ==> PR650init at 64
> hPort = IOPort('OpenSerialPort', portNumber, handshakeCode);
>
> Error in ==> CMCheckInit at 130
> stat = PR650init(portNameIn);
>
> We have tried manually closing COM5 using fclose, and get verification that it is closed. However, on running CMCheckInit again, it still thinks the port is open.
>
> Does anyone have any suggestions for how to fix this?
>


4
Hi Mario and Allen (long time since NYU!),

Thanks for the tip on the emulator. We do need to better isolate the problem.

To Mario's point, we did get a bit further since my post by getting a different adapter. We believe that there may have been a problem with the previous one. We no longer got the IOPort error, but running PR660init gave us this:

>> global g_useIOPort
>> g_useIOPort = 1;
>> PR650init('COM4')
ans =

The adapter was confirmed connected to COM4 in the device manager.
Starting from CMCheckInit obviously failed to carry through as well.

This was on an ACER running Windows 8 with a StarTech ICUSB232 (containing a PL 2303 chip, which Mike at Photo Research says is the chip they prefer).

S


--- In psychtoolbox@yahoogroups.com, "Allen W. Ingling" wrote:
>
>
> Hi Stuart,
>
> As a diagnostic test, try using a free terminal emulator to talk to the PR-650. I use Zterm on OS X to test serial port interfaces and there are similar programs for Windows. In the terminal emulator set the the rate, baud, and parity etc. parameters to match the PR-650 specifications and set the com port to match your system configuration. Reboot the system first to be certain that you have cleared residual state from your previous attempts under MATLAB. If the terminal emulator fails and especially if it gives a similar error to what you have seen using the PTB, then you have excluded anything running in MATLAB as a possible cause this failure.
>
> Using the terminal emulator also gives you an easy way to test with the USB adapter assigned to different COM ports, just in case the choice of COM ports makes a difference.
>
> - Allen
>
>
>
> On Jan 21, 2013, at 8:18 PM, Mario wrote:
>
> >
> >
> > Error code 5 is "ERROR_ACCESS_DENIED":
> >
> > http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx
> >
> > So it is not the case that the port is already open, but for some reason you can't access it. Maybe something misconfigured in the device settings control panel?
> >
> > -mario
> >
> > --- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
> > >
> > > We're trying to calibrate a monitor on a Dell Precision 390 running Windows XP Service Pack 3.
> > >
> > > The PR-650 is connected to a usb port via an Ultra U12-40958 USB to DB9 and DB25 Parallel Adapter with XP drivers installed. Device manager recognized the adapter, and we assigned it to COM5 to correspond with the default port in PR650init and CMCheckInit.
> > >
> > > When we try to run the calibration, or CMCheckInit on it's own, we get the following error:
> > >
> > > Error in function OpenSerialPort: Usage error
> > > Error opening serial port device COM5 - The serial port is already open, close it first! (5) [EBUSY EPERM]. Could be a permission problem as well.
> > >
> > > ??? Error using ==> IOPort
> > > Usage:
> > >
> > > [handle, errmsg] = IOPort('OpenSerialPort', port [, configString]);
> > >
> > > Error in ==> PR650init at 64
> > > hPort = IOPort('OpenSerialPort', portNumber, handshakeCode);
> > >
> > > Error in ==> CMCheckInit at 130
> > > stat = PR650init(portNameIn);
> > >
> > > We have tried manually closing COM5 using fclose, and get verification that it is closed. However, on running CMCheckInit again, it still thinks the port is open.
> > >
> > > Does anyone have any suggestions for how to fix this?
> > >
> >
> >
>
5
--- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
>
> Hi Mario,
> I didn't mean to be disparaging by using the word mess, just to indicate that I don't really understand the hardware details sufficiently to make sense of it. I fully appreciate the work of you and the others who do.
>

The output is quite cluttered. The problem is that we need it for debugging problems, or to prevent people from unknowingly screwing up their data collection on the many broken systems out there, so we can't really cut it down. But if you know of better formulations for messages, feel free to provide improvements as patches. It's difficult for me to judge this, because i know that the messages mean.

> We were running CalibrateMonSpd on OS X 10.4.11 with R2008a, Apple Cinema Display. I think a big part of the problem was misunderstanding the prompt "Which HD display (0 = none, 1=Bits++, 2=DataPixx/ViewPixx) and thinking the correct input was 1 or 2.
>
> After reading the stuff on the wiki, clearly should have been using 8 bit for that machine.
>
> My problem was a "stupid user" problem.

Good. I like problems that solve themselves :-)
-mario

>
> --- In psychtoolbox@yahoogroups.com, "Mario" wrote:
> >
> >
> >
> >
> >
> > --- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
> > >
> > > Put the windows issue aside for now and acquired a Mac for the calibration.
> > > PR650 communication was successful but got the following in the mess of PTB INFO that was in the control window (the program seemed to hang after the initial screen stimulus came up).
> > >
> >
> > I love it how those who call it a mess are usually the ones who need it most urgently to resolve their issues.
> >
> > > PTB-INFO: OpenGL-Renderer is ATI Technologies Inc. :: ATI Radeon HD 2600 OpenGL Engine :: 2.0 ATI-1.5.48
> > > PTB-INFO: Renderer has 256 MB of VRAM and a maximum 238 MB of texture memory.
> > > PTB-INFO: VBL startline = 1600 , VBL Endline = 1645
> > > PTB-INFO: Measured monitor refresh interval from beamposition = 16.632633 ms [60.122771 Hz].
> > > PTB-INFO: Will use beamposition query for accurate Flip time stamping.
> > > PTB-INFO: Measured monitor refresh interval from VBLsync = 16.631834 ms [60.125659 Hz]. (50 valid samples taken, stddev=0.018318 ms.)
> > > PTB-INFO: Small deviations between reported values are normal and no reason to worry.
> > > PTB-INFO: Support for fast OffscreenWindows enabled.
> > > LoadIdentityClut: Info: Could not use GPU low-level setup for setup of pixel passthrough. Will use fallback method.
> > > LoadIdentityClut: Info: If you have an AMD/ATI GPU, you may get this working by loading the PsychtoolboxKernelDriver
> > > LoadIdentityClut: Info: on OS/X or using a Linux system properly setup with PsychLinuxConfiguration.
> > > BitsPlusPlus:GPU-Rasterizertest: Warning: glVertex2i() command draws at wrong position (Offset -1, 0)!
> > > OpenWindowBits++: Applying corrective horizontal offset of 1 pixels for buggy graphics card driver. Will hopefully fix it...
> > > Set up radiometer and hit any key when ready
> > >
> > > Appears that there was a second key input prompt after the screen was up that the operator running the calibration missed?
> > >
> >
> > Who knows? You don't tell what script you're actually running or what your display setup is. You can always do a dry run where you type PsychDebugWindowConfiguration before running your script, so you can see the mess while the script is running and check if you are missing any important messages.
> >
> > > Also, does it look to you that the LoadIdentityClut issues were resolved or not? I can't tell.
> >
> > It tells you it couldn't use the low-level method, which is the robust one, and instead used a fallback method, which is not as bullet-proof. It also tells you how you can enable the reliable low-level method. Of course all the messyness makes it difficult or uninviting to read.
> >
> > With the fallback method, the only way to check if your system operates correctly is to switch your Bits+ (i assume) to Mono++ mode and run BitsPlusIdentityClutTest for a visual diagnostic test. Or you have to write your own test for other Bits+ modes to check for proper behaviour.
> >
> > -mario
> >
> > >
> > > Thanks.
> > >
> > > --- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
> > > >
> > > > Hi Mario and Allen (long time since NYU!),
> > > >
> > > > Thanks for the tip on the emulator. We do need to better isolate the problem.
> > > >
> > > > To Mario's point, we did get a bit further since my post by getting a different adapter. We believe that there may have been a problem with the previous one. We no longer got the IOPort error, but running PR660init gave us this:
> > > >
> > > > >> global g_useIOPort
> > > > >> g_useIOPort = 1;
> > > > >> PR650init('COM4')
> > > > ans =
> > > >
> > > > The adapter was confirmed connected to COM4 in the device manager.
> > > > Starting from CMCheckInit obviously failed to carry through as well.
> > > >
> > > > This was on an ACER running Windows 8 with a StarTech ICUSB232 (containing a PL 2303 chip, which Mike at Photo Research says is the chip they prefer).
> > > >
> > > > S
> > > >
> > > >
> > > > --- In psychtoolbox@yahoogroups.com, "Allen W. Ingling" wrote:
> > > > >
> > > > >
> > > > > Hi Stuart,
> > > > >
> > > > > As a diagnostic test, try using a free terminal emulator to talk to the PR-650. I use Zterm on OS X to test serial port interfaces and there are similar programs for Windows. In the terminal emulator set the the rate, baud, and parity etc. parameters to match the PR-650 specifications and set the com port to match your system configuration. Reboot the system first to be certain that you have cleared residual state from your previous attempts under MATLAB. If the terminal emulator fails and especially if it gives a similar error to what you have seen using the PTB, then you have excluded anything running in MATLAB as a possible cause this failure.
> > > > >
> > > > > Using the terminal emulator also gives you an easy way to test with the USB adapter assigned to different COM ports, just in case the choice of COM ports makes a difference.
> > > > >
> > > > > - Allen
> > > > >
> > > > >
> > > > >
> > > > > On Jan 21, 2013, at 8:18 PM, Mario wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Error code 5 is "ERROR_ACCESS_DENIED":
> > > > > >
> > > > > > http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382%28v=vs.85%29.aspx
> > > > > >
> > > > > > So it is not the case that the port is already open, but for some reason you can't access it. Maybe something misconfigured in the device settings control panel?
> > > > > >
> > > > > > -mario
> > > > > >
> > > > > > --- In psychtoolbox@yahoogroups.com, "stuartfuller952" wrote:
> > > > > > >
> > > > > > > We're trying to calibrate a monitor on a Dell Precision 390 running Windows XP Service Pack 3.
> > > > > > >
> > > > > > > The PR-650 is connected to a usb port via an Ultra U12-40958 USB to DB9 and DB25 Parallel Adapter with XP drivers installed. Device manager recognized the adapter, and we assigned it to COM5 to correspond with the default port in PR650init and CMCheckInit.
> > > > > > >
> > > > > > > When we try to run the calibration, or CMCheckInit on it's own, we get the following error:
> > > > > > >
> > > > > > > Error in function OpenSerialPort: Usage error
> > > > > > > Error opening serial port device COM5 - The serial port is already open, close it first! (5) [EBUSY EPERM]. Could be a permission problem as well.
> > > > > > >
> > > > > > > ??? Error using ==> IOPort
> > > > > > > Usage:
> > > > > > >
> > > > > > > [handle, errmsg] = IOPort('OpenSerialPort', port [, configString]);
> > > > > > >
> > > > > > > Error in ==> PR650init at 64
> > > > > > > hPort = IOPort('OpenSerialPort', portNumber, handshakeCode);
> > > > > > >
> > > > > > > Error in ==> CMCheckInit at 130
> > > > > > > stat = PR650init(portNameIn);
> > > > > > >
> > > > > > > We have tried manually closing COM5 using fclose, and get verification that it is closed. However, on running CMCheckInit again, it still thinks the port is open.
> > > > > > >
> > > > > > > Does anyone have any suggestions for how to fix this?
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>