Error 1386 between Labview Quantum Design PPMS

[GD789]

(This is a different problem from http://forums.ni.com/t5/LabVIEW/Controlling-PPMS-from-Labview/m-p/2581885/highlight/true#M777361)

I also check the Quantum Design forum and webpage, but did not find a solution.

My initial guess was that there is something missing with the QDInstrument.dll file, but now I think there might actually be a problem related to the way Labview interacts with the .NET framework. and invoke nodes. For this reason I am posting to the NI Forum. Sorry for the long text, but I try to give a max of info.

I am trying to interact with the ppms from Quantum Design. I use the library  (PpmsMultiVu.zip) attached to this message. It contains an example vi but it requires the QD software to run in parallel.

I get an error 1386 with this error message:

Error 1386 occurred at Invoke Node in OpenQDInstrument.vi->QDInstrument_Example.vi
Possible reason(s):
LabVIEW:  The specified .NET class is not available in LabVIEW.

Interestingly, the error only happens when the QD library is installed on my C drive. It does not matter if it is the Labview2014>instr.lib folder, or anywhere else such as the desktop.

Also if I checked :

View > .NET Assemblies in Memory

It is empty.

If I install the library on a network drive, everything will run nicely, and .NET Assemblies in Memory has one entry

Also if I have two copies of the library, on on the c drive, and the other on the network drive, if I launch the example vi form the c drive, it will still give the error, event if the files are still located at the same place on the network drive.

The library makes heavy use of .net invoke nodes

Earlier a had an "Failed to connect to OLE server " error while working with this library, but this resolved by itself after a computer reboot, without a logical explanation.

Thanks for your input

[GD789]

The library in question

[WestOfEden]

Hello,

I downloaded the library that you attached and extracted it to the instr.lib folder in Program Files. When I tried to run it, I received the OLE server error that you had mentioned earlier, so I didn't see the .NET error. I am going to see if  we can figure this out next week, but its hard to say what the issue is at a glance.

Eden

[dmsilev]

I've used that library fairly extensively to control PPMS systems; I think that error says that there's something wrong with the DLL file that provides the connectivity between LabView and MultiVu. 

Just to check: You do have MultiVu installed on your machine as well as LabView?

In any event, if both the DLL and MV are installed, there's something weird going on and your best bet would be to ask QD directly. Write to the Applications group ( apps@qdusa.com ) and ask them. 

[GD789]

Yes, I have MultiVu installed on the same machine.

At this time I am working with a machine not connected to the PPMS, as I want to use MultiVu in simulation mode while debugging.

I check, if the library is on the network drive, i can run the Example, and change settings in MultiVu.

I'll QD directly

[GD789]

I still have not found a solution for my problem, but I found another discussion with a similar issue;

http://forums.ni.com/t5/LabVIEW/problems-loading-NET-assemblies/td-p/3171168

There are a few interestinc suggestions that I will try.

[GD789 · Accepted solution]

I finally found the solution in this discussion:

http://forums.ni.com/t5/LabVIEW/Cannot-load-v2-0-targeted-Net-assembly-in-LV-2013-Mixed-mode-not/td-...

I needed to creat a config file as described here :

http://digital.ni.com/public.nsf/allkb/4742EB60B64BE22186257BCE0053B8FD?OpenDocument

It is interesting to see that the new "security" feature of .net 4 that was supposed to trust only assemblies saved on the local computer resulted in exactly the opposit results. It was only trusting assemblies NOT on the local disc.

This strange behaviour is most likely due to the fact that my university saves the user profiles on a  central server, and not on the local machine. But the software itself is still saved on my C drive!

I love the security 😉

I hope this explanation will help others with a similar issue.

[GD789 · Accepted solution]

Actually this did not completely solved my problem.

90% of the calls to the .net worked, but I would have random 1386 errors appearing after a few successful calls in a program.

In the QD example found in the library, the error would appear at the ReadField subvi.

the final solution was to change the properties of the QDInstrument.dll file. so that windows forgets that this was downloaded from the internet

If an application has been copied from the web, it is flagged by Windows as being a web application, even if it resides on the local computer. You can change that designation by changing the file properties

It seems that this does not work exactly how it is explained in this description of the property:

https://msdn.microsoft.com/en-us/library/dd409252%28v=vs.110%29.aspx

[phylab]

Thank you. It saved us. We had similar problem connecting with QDPPMS and getting error 1386. Once the properties of the QDInstrument.dll file is chagned it is working nicely. Kudos.