Labview 8.20 Crash using vi's created with import dll wizard

[Noel]

Sorry for the delayed response.   It really sounds like memory is being corrupted.  When memory is overwritten, one possible consequence is an internal error in DSTM.cpp.  I don't want this to sound defensive re: NI products, but it sounds as if the problem is likely to be in the USB driver or the way the driver is being initialized and used.  In general, making a USB driver is very difficult -- especially when dealing with proper handling of system resources like IRPs. They get handed back and forth between the driver and system and any minor mistake will cause a blue screen.

I realize you are experiencing some difference of behavior between different versions of LV.  It is critical to investigate the differences in how the DLL functions are being called -- no matter how small the differences.

As I mentioned before, the Import Shared Library Wizard isn't doing anything that you can't do through manual configuration.  So, I recommend checking the VI differences.

Because USB drivers are difficult, if you or anyone else is considering building a new driver -- I would highly recommend using VISA as the USB interface.  VISA USB is extremely stable and it is very easy to send raw USB packets to a device.  NI has invested several man years of development time into providing VISA USB.  One of the reasons we've made this investment is because we realize that providing a robust USB driver is not trivial.

Regards,
Noel

[Faraclas]

Hi.  We are having similar issues with the PicoScope 3206.  To reiterate our problems, sometimes the dives works, and most times not more than once.  It seems to be a problem with how LabVIEW is closing the device.  We also used the DLL import wizzard but found the included .h file to be woefully inadequate.  However, there was no observed difference between using the VIs from the import wizzard or calling straight from the .dll as in the included LabVIEW example.  If anyone has an update on this or a stable driver for this device we would greatly appreciate it!!

[AndrewAlford]

I found the issue stabilized itself as long as the Picoscope Close is always executied prior to the VI from stopping.

During development this is a pain when debugging, however, once my final app was completed I found no crashes during execution.

The Labview Driver offered by Pico Technologies is poor and does not contain the entire functionality of the scope. Personally I think it is irresponsible of them to advertise a Labvew driver is available.

One way I found to work around the crashing is if I want to abort my code, I unplug the picoscope from the computer.

This is all I've got, if anyone has heard of an improvement please post.