Fork of HCFR Started - What's needed? - Page 44

That looks good, if you run ColorHCFR as a 32bit application (maybe there is some sort of compatibility mode you can turn on?) it should work.

tried all the way back to winxp sp3. getting the error

That's the error you get when the winusb driver is not being used to open the port. I'll have to get hold of a win7 machine and find a driver installation that works.

you may want to look at how v 3.0.0.0 handled the i1pro.

thanks zoyd

Hello John,

I´m in trouble getting my Spider4 not detected by the hcfr software

I have installed HCFR 3.0.4.0
I running Win7 64bit.
runned : spyd4en.exe
I finally created a spyd4cal.bin (folder: user/roaming/color)
- how gonna use that ..bin?
stil in the HCFR the spyder is not to choose
??

followed those rules
dont connect the spyder
install datacolor software,
installed HCFR,
executed the spyd4en.exe (double click)
File spyd4cal.bin created finally there: c:\\Users\AppData\Roaming\color\
reinstalled Datacolor
pluged spyder4 into USB
deinstalled the spyder4 driver
unpluged and pluged in the spyder4
found the spyder in the device manager...
cant update the driver with the hcfr driver (where to find????)
restarted the pc several times
in the HCFR software no spyder to chose.
the spyder driver is telling me:
C:\Windows\system32\Drivers\dccmtr.sys
C:\Windows\system32\WdfCoinstaller01001.dll
Port_#0002.Hub_#0004

this does not work:
http://sourceforge.net/p/hcfr/wiki/Spyder%204/
cd c:\program files (x86)\HCFR Calibration\Tools



This drives me crazy, just one little step before beeing able to start first calibration

I hope you could help me.
Thanks

Can we run the old and new version on the same PC to compare? HCFR runs fine from a folder without proper installation?

thx

bob

yes, no problem.

Hey Zoyd,

I'll install this on my Win7/64 machine and see if it works with the i1Pro.

Does this version include the latest (post 3.0.0.4 release) i1Pro code that JohnAd had in Git? I compiled and have been using some of his later 3.0.0.4+ code and it works for the i1Pro, but JohnAd didn't release it because of issues with simultaneously connected meters.

-JD

yes, this is the current 3.0.4.0 source from sourceforge so multiple meters work fine after making the driver update. I used i1pro 2 and D3 at the same time without any issues but it was on winxp.

I'm getting the same error that Vega509 displayed above. I'm using the libusb instead of the winusb driver, but that shouldn't matter:


Did you download the code from the Zip file or Git? The 3.0.4 version I compiled was from the latest files in Git and that was where the i1Pro was working, but not with simultaneous meters.

I´m in trouble getting my Spider4 not detected by the hcfr software

It works

what was my trouble?

CMD
I followed now the more clearer steps down to the folder
C:
cd program files (x86)
cd HCFR Calibration
cd Tools
make a dir to check if you are in the right folder!
execute just typing the following!

spyd4en.exe –v -S u
(here it was important that there are blanks after the .exe and each other...... .exe_-v_S_-u)

Here I could clearly see that my PC is writing something into the machine
following steps:
- rebooting
- deinstalled Datacolor, Spyder 4
- pluged in Spyder4 again
- in the hardwaremanager, install the right driver
?
Where?
- Folder: Windows (C:) / Program Files (x86) / HCFR Calibration / Drivers

Thats it
my mistake was that I typed always in CMD "Programm" instead of Program

Now my HCFR is working with the spyder very easily

I git cloned the code. the i1 pro requires that winusb be loaded along with libusb-1.0A in the version that supports multiple meters.
Edited by zoyd - 1/29/13 at 2:45am

> I made a change in the D3 meter code that has stabilized it quite a bit.
> Simply setting the baseline integration time to a larger value (1.5 sec
> which is the default for CM for low light conditions) did the trick. I don't
> know anything about git and merging in new code etc. so here is a
> standalone package with the change.

I'm sure it did, but you're throwing away one of the major advantages of the D3, it's speed.

It would help if you could download the latest ArgyllCMS development snapshot at http://www.argyllcms.com/Argyll_dev_src.zip and check the stability on your test case using spotread (ie. "spotread -yr"). I've tweaked the refresh display code to up the integration time to 0.4 seconds minimum, and also change the crossover from period to frequency measurement mode to improve consistency for refresh type displays such as plasmas. If you don't want to or can't compile the source, you can find an MSWin binary at http://www.argyllcms.com/disptools.win32.zip. [ It's always better to try and fix these sorts of problems upstream.]

Speed is still quite good but I agree that further optimization is beneficial. I'll fold the Argyll changes into the HCFR d3 code and test it directly.

Any comment on the i1pro driver issue? In John's multimeter argyll wrapper the only way I can get the usb "open" api to work is by forcing the winusb driver to load ( WINUSBCO_DEV in the inf) I saw you made a note somewhere about the i1pro not being happy with winusb but so far I have not seen problems operationally.
Edited by zoyd - 1/29/13 at 4:43am

Folding the latest driver improvements in might not be entirely straightforward, since I've made a lot of changes to the instrument access library API aimed at improving its operation in a GUI environment, although it would be possible with some effort to extract the specific i1d3 stuff and apply it back.

I'm not aware of any i1pro issues - yes there was a problem a while back with having more than one instrument open at a time, but from the feedback I got from JohnAd I thought that had been sorted out. The way ArgyllCMS is structured it's not actually possible to open more than one instrument from a single application (although perfectly possible to open more than one instrument using more than once instance of an application), so it's not easy for me to test this particular aspect.

A lot of the issues people have, seem to be in not understanding that ArgyllCMS needs to use different system USB drivers than the instrument manufacturers software. I'm not sure how clear the HCFR doco is on that. I've certainly put a step by step in the Argyll documentation: http://www.argyllcms.com/doc/Installing_MSWindows.html

Okay, I'll try that if I have time tonight. I have 32 and 64 bit Windows 7 machines to test this on if needed.

I installed the winusb driver on Win 7 64 from the HCFR libusb folder and the i1Pro displayed a "can not start device" message in Device Manager. I couldn't access it from any of the HCFR versions, so I reverted back to libusb.

Edit: Same error in Win 7 32 bit. My guess is the problem is with the inf file.
Edited by jdbimmer - 1/29/13 at 9:15pm

There is some esoteric usb com problem with the i1pro. The current status is:

1. Initial version 3.0.0.0 of the argyll wrapper code works fine with the i1pro but supports only one meter at a time and doesn't support the d3 or colormunki.
2. Versions >3.0.0.0 which support multiple meters (including the d3/colormunki) but throws an error in icoms when trying to open the i1pro. Spotread works fine.
3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.
Edited by zoyd - 1/30/13 at 4:15am

If spotread works fine, then there is something particular in either the way HCFR is using instlib, or some difference to the ArgyllCMS V1.4 code. Is there a specific error message in the 2nd case ? (ie. instlib debug output). I'm not sure why switching to winusb would make any difference, nor why winusb would be restricted to win32xp (certainly winusb is used for some instruments in ArgyllCMS V1.4 on 32 and 64 bit Vista & Win7).

yes, the specific error is:


Some googling led me to force loading of the winusb driver, particularly this post

"Remember that when using libusb on
Windows (unless you are using a WinUSB WCID device [1] on Windows 8),
you must install a relevant compatible driver, which currently means
WinUSB for libusb-1.0."

and

"USB_API_UNSUPPORTED (which is not an error code, but an API value used
internally) simply means that, while a device was found, it is not using
the WinUSB driver so we can't access it."

NTx86.5.1_Device = "LIBUSB0_DEV" ; 32 bit WinXP
shouldn't that actually be:

NTx86.5.1_Device = "WINUSBCO_DEV" ; 32 bit WinXP

works like a charm
Edited by Losha - 1/30/13 at 11:36am

we know, that was established back in this post. The inf in that package is already modified so that the i1pro will work with winxp using the winusbco_dev driver line.

I'm not sure how HCFR is packaged - in the ArgyllCMS V1.4 package the Microsoft WinUSB installables for 32 and 64 bit are included and used in the driver instalation.

Hmm. It's hard to know why this is the error - it means that the libusb code couldn't identify the system driver being used by the device, which is strange because it will recognize WinUBS, libusb0 and HidUsb.

[ArgyllCMS V1.5 beta drops libusb and WinUSB completely, and uses the libusb-win32 (libusb0) system driver, and simplifies the device setup by using a single .inf file.]

HCFR uses the ArgyllCMS V1.4.0 libusb1 folder for driver installation and most of the meters have infs that load winusb_dev but the i1pro.inf looks like this:

I also tried the V1.5 inf and get the same error as above.

If HCFR is using the same instlib code as ArgyllCMS V1.4, then I don't understand how it is possible for spotread to work and HCFR to get this type of error. There must be some inconsistency between the instlib and/or libusb code in HCFR to cause this. Having both on the same machine provides the perfect situation to track down what that difference is :-)

That's never likely to work - V1.5b doesn't install WinUSB and doesn't install libusb1A.dll, etc.

There is some cross compatibility if the libusb0.sys is the driver used by an instrument, but idealy the old V1.4 driver should be removed and the V1.5b one freshly installed, and the V1.5b instlib/applications used with it.

yep, when John updated the libusb code to handle multiple meters something broke.

maybe a question that has been answered already, but why not go back to the windows / x-rite drivers like version 2 had?

Because the point of creating an open source project was so that the code could be published (no copyright issues) for everyone to work on.

You can do anything you like or course - if you can rustle up the expertise and time to do it :-)

To use the manufacturers drivers entails someone R.E. the API's to their driver system and testing and maintaining the result. While some of the older instruments have known DLL API's, the newer instruments have differences, and are harder to access if you use X-Rite's install, since they have moved to a server architecture. Some hybrid Argyll/OEM instrument access approach is theoretically possible, but it would be ugly to organize.

The fact that ArgyllCMS spotread works indicates that there is probably a trivial bug in the HCFR code in regard to the i1pro. If no-one is prepared to look into that, then I see little hope of proceeding with a larger task such as reverting to using the manufacturers drivers.

awesome! I'll definitely play around with it this weekend and report back.