11-14-2013 08:32 AM
Here are images of updated code. In the first screenshot I use the close reference vi. The second screeshot is where the error happens. The error happens when it tries to OpenDevices, and never reaches the case structure.
11-14-2013 12:18 PM
Does the USB class or OpenDevices() encapulsate native code for the USB hardware?. It is quite possible, if there is an issue with that interface, for it to effectively take down the LabVIEW environment. To para-phrase this in a crude way - by LabVIEW calling the method you describe, you are effectively asking LabVIEW to trust that the method will return the calling thread at some point and not perform an activity that will force a lock, terminate or abort the thread (at an OS level) or any other un-controlled event that results in LabVIEW being unable to access the thread properly. This can cause all manner of problems in the environment (dont' forget that LabVIEW does not run in a managed environment like the CLR).
Welcome to the wonderful world of integration!
I was a betting man then this would be where I would look. Source for the USB class would help but if you're unwilling or unable to share, then I would debug the call in Visual Studio at run-time to see what is happening inside.
11-14-2013 01:58 PM
Is the .dll file the source? This is the first time I am using .NET so I really have very little idea of what is going on.
11-14-2013 02:23 PM
Unfortunately the dll is not the source - however it is often possible to recover the source from the compiled dll file (with unobfuscated .net anyway). Your best bet is to approach the developer/company who provided the .dll file and enquire. Without the source and Visual Studio you have slim options for debugging the root cause further.