The original driver didn't work with Multicore CPUs, so i wrote a new one.
Sorry if that one was missing in the last zip file.
I don't have the LeCroy anymore (I sold it and switched back to my old TDS754D because i was sick of re-calibrations all the time)
The original driver didn't work with Multicore CPUs, so i wrote a new one.
The original driver didn't work with Multicore CPUs, so i wrote a new one.
Will you refresh my memory and give a little technical background on the issue that you fixed? I remember there being a discussion about the problem somewhere but I can't find it anymore.
with ingowien driver, the original driver (front panel) will work in WinXP, but other drivers (fan controller etc) will not get resources allocated, but still functional. but to allocate resources nicely, your driver need to be installed, but Front Panel still nasty in WinXP if no ingowien driver. so both of your driver and ingowien's will make a nice combo for more functional drivers in WinXP/Win7.
I still am not sure why dxl's front panel driver didn't work with my hardware, maybe my I/O board is slightly different. But you have to be aware that there have been versions of dxl's .zip files with and without his modified driver. If you install the incorrect one, you'll end up with the original Lecroy drivers installed by the Win7 .inf file which would explain the front panel issues. Just check the date of the .sys files. If LecAladdinFrontPanel.sys is from 2011 as the other .sys files it's the original Lecroy driver.
So in my opinion the fan controller driver is always the same, the difference for XP might be that if it's installed with the original Lecroy .inf file, memory resources are assigned through the LeCAladdinMFResfilter.sys while with dxl's modified Win7 .inf file memory resources are directly assigned by the PNP manager through the VaryingResourceMaps. That's why you don't see the memory resources as the Windows PNP manager doesn't get them from the .inf file. Instead the are (invisible for the PNPMgr) passed from the filter driver down to the function drivers. Seems to be a bad workaround for non-PNP multifunction devices from the Win95/NT4/W2k days.
But in the device manager, there is a COM3 device, which does not load properly,
Edit: As You can see, on my acquisition board, all parts for the GPIB interface are populated, except the connector. Is there any use in haveing GPIB present?
that sounds super tedious esp the learning how to speak and read chinese. maybe you can be a supplier for worldwide? otherwise, the supply from digikey/mouser/element14 will make any derivative product using that connector quite expensive.
Edit: As You can see, on my acquisition board, all parts for the GPIB interface are populated, except the connector. Is there any use in haveing GPIB present?
If you personally need to get something from China, you can show me the desired item and I will do it prime cost, but only for you personally.
can you get closer snapshoot picture of the ICs involved? in case someone want to do the mod. maybe adding those chips, enabling GPIB in SW will do the trick? about bottlenecking the card, let the modder decide if update rate is more important, or GPIB functionality is.
can you get closer snapshoot picture of the ICs involved? in case someone want to do the mod. maybe adding those chips, enabling GPIB in SW will do the trick? about bottlenecking the card, let the modder decide if update rate is more important, or GPIB functionality is.I think U16 should be an crystal oscillator.