CS320 with Labview 8.5 -> No USB devices detected

REF: Cscope Control Driver LV8.llb with associate FTD2XX.dll

I never been able to run the ""Simple scope example.vi"" because the vi ""FT_Get numb USB Devices.vi"" returns always 0 device detected.
In this vi the function ""FT_ListDevices"" in the FTD2XX.DLL returns 0 for both outputs parameters -> (I32) Return and (I32) pnumdevices.

Need Help.

Harold

REF: Cscope Control Driver LV8.llb with associate FTD2XX.dll I never been able to run the ""Simple scope example.vi"" because the vi ""FT_Get numb USB Devices.vi"" returns always 0 device detected. In this vi the function ""FT_ListDevices"" in the FTD2XX.DLL returns 0 for both outputs parameters -> (I32) Return and (I32) pnumdevices. Need Help. Harold

I have the same ""no Cleverscope found"" problem running ""Simple scope example.vi"" from ""Cscope Control Driver LV8.llb"" with Labview 8.2 and the latest (v6430) firmware and USB drivers. However, the LV7.1 library recompiled with Labview 8.2 (and using QuickUSB.dll from the Cleverscope installation directory) seems to work fine, so I'm content at the moment. The revision date of the LV8 library is a year and a half behind the LV7.1 library on the Cleverscope website, which probably has something to do with it.

Dan

I have the same ""no Cleverscope found"" problem running ""Simple scope example.vi"" from ""Cscope Control Driver LV8.llb"" with Labview 8.2 and the latest (v6430) firmware and USB drivers. However, the LV7.1 library recompiled with Labview 8.2 (and using QuickUSB.dll from the Cleverscope installation directory) seems to work fine, so I'm content at the moment. The revision date of the LV8 library is a year and a half behind the LV7.1 library on the Cleverscope website, which probably has something to do with it. Dan

I did also recompile the 7.1 LLB and after minor fixes everything work fine.
I front new problems.
It seems that there is no post trig capability (start a delayed acquisition after an external trig) and a flexible multiples records feature (more than 4000 acq )

Thank you for your Email

I did also recompile the 7.1 LLB and after minor fixes everything work fine. I front new problems. It seems that there is no post trig capability (start a delayed acquisition after an external trig) and a flexible multiples records feature (more than 4000 acq ) Thank you for your Email

Hello Harold,
We covered this point in an email to you. The start and stop times define the capture period relative to the trigger. So if you set start at 104.2ms and stop at 104.6ms you will capture 400us of signal, with a 104.2ms post trigger delay. Similarly if you used start = -8.6ms and stop = -7.2ms you are capturing 1.4ms of signal, starting 8.6 ms before the trigger. Note that for post triggered situations, we have a 10ns counter counting the post trigger delay, which means you can get use the whole frame for capturing just the bit you want. However for the pre trigger scenario we must capture samples all the way to the trigger so the frame that is captured actually goes from the start time to 0 secs.

We do all our programming in 7.1, so sometimes 8.0 and 8.2 (and as soon as we get round to it 8.5) lag behind. We have built the application in 8.5 (there are some advantages) but the install changed from 33 Mbyte zipped to 280 Mbyte zipped. This is a significant problem. If anyone knows how to reduce the 8.5 compiled size we would be grateful to know how to do it. (We need to include the Runtime library in the installer).

Hello Harold, We covered this point in an email to you. The start and stop times define the capture period relative to the trigger. So if you set start at 104.2ms and stop at 104.6ms you will capture 400us of signal, with a 104.2ms post trigger delay. Similarly if you used start = -8.6ms and stop = -7.2ms you are capturing 1.4ms of signal, starting 8.6 ms before the trigger. Note that for post triggered situations, we have a 10ns counter counting the post trigger delay, which means you can get use the whole frame for capturing just the bit you want. However for the pre trigger scenario we must capture samples all the way to the trigger so the frame that is captured actually goes from the start time to 0 secs. We do all our programming in 7.1, so sometimes 8.0 and 8.2 (and as soon as we get round to it 8.5) lag behind. We have built the application in 8.5 (there are some advantages) but the install changed from 33 Mbyte zipped to 280 Mbyte zipped. This is a significant problem. If anyone knows how to reduce the 8.5 compiled size we would be grateful to know how to do it. (We need to include the Runtime library in the installer).