LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1172: Invoke Node Error on a VI that previously worked

Solved!
Go to solution

I have a Labview program that is meant to set the temperature of the PPMS (Physical Property Measurement System from Quantum Design Inc.) through QDInstrument.dll (also from Quantum Design). The image of the VI is attached. It has previously worked but now I get an error 1172: Invoke Node Error calling method QuantumDesign.QDInstrument.QDInstrumentFactory+QDInstrumentBase.SetTemperature, (System.ArgumentNullException: Key cannot be null.
Parameter name: key) <append><b>System.ArgumentNullException</b> in settemp.vi. 

 

I have already tried to run Labview and MultiVu (the program for the PPMS) as administrator. This has not resolved the error 1172. 

 

I am using NI Labview 2017 (32-bit), updated a few months ago, and I don't remember if this VI worked on this version, though I know it has worked from the previous year version of Labview. I'm not sure if it's the issue of the newer version or an update from Windows, and I'd be surprised if this is an issue of the location of the dll since this VI has worked previously. 

 

Thanks for your time. 

0 Kudos
Message 1 of 8
(4,845 Views)

I'm afraid you'll need to give us a lot more to go on if you need targeted advice. LabVIEW can certainly find the assembly that your call in the picture is referencing based on the exception content - basically that assembly has thrown an exception related to not finding something in a Dictionary but that doesn't help us figure out the actual root cause. Some generic questions to fill in the picture:

  • OS, bitness and version?
  • .NET Framework versions installed?
  • Can you access the PPMS (using another application - is that "MultiVu"?) and does that work correctly? ie can we rule out a driver or connectivity issue unrelated to LabVIEW
  • Do you have a sample project that demonstrates the issue - can you zip and upload this please (including the PPMS drivers)? An image is not very helpful
0 Kudos
Message 2 of 8
(4,820 Views)

The OS is Windows 10 Pro, 64-bit Version 1703, with the .NET 4 framework. The program for the PPMS, MultiVu, runs fine, though I'm not sure if this is an issue of Labview and MultiVu communication (though this would be surprising since the VI has worked before and no file locations have changed). I have included the llb, the settemp.vi, and XDAQGlobals.vi, which appears when I double-click on the refnum. 

Download All
0 Kudos
Message 3 of 8
(4,815 Views)

Quick tip - Rule #1 when working with .NET in LabVIEW is to always use a LabVIEW project. Yes you can get away with it for a while or for a quick test but eventually it bites you in terms of finding the right versions of .NET assemblies or being able to pass the project along to the next person. 

 

I will look into the LabVIEW source you provided but you might also want to check that the assembly load path is actually correct eg. see below (you didn't provide the assembly or relevant dependencies in your upload).2018-10-12 07_25_10-Win10x64 NI2018 - VMware Workstation.png

 

Also the source you provided doesn't seem to have an entry point - when is the .NET object "PPMS Ref" created? It might be a static class but you really need to upload all the assemblies (zipped) in that "old ppms files" path.

0 Kudos
Message 4 of 8
(4,794 Views)

Here is the folder that is under the"old ppms files", as the size of the zipped folder for "old ppms files" is too large to upload to here. I can upload more folders in the "old ppms files" if the VI needs to call out something.

 

I'm not sure when the actual PPMS Ref was created as the VI was made by someone else. I'd be surprised if this was a load path issue, as this VI ran fine a couple of months ago and the file locations have not changed since. The only change I can think of was a few Microsoft updates and updating LabVIEW from 2016 to 2017. 

 

Thanks for your patience, I'm still a beginner at LabVIEW so I'm a bit slow at trying to comprehend this kind of stuff.

0 Kudos
Message 5 of 8
(4,782 Views)

OK. In that folder "XDAQ_PPMS" there is a readme telling you how to use the instrument driver VIs that happen to be in that folder. Have you read through this?

 

Unfortunately I don't have access to LabVIEW at the moment (poor timing - that ship just sailed) but I have some ideas you could try.

 

Based on what you posted my suspicion is that you need to perform some Initialization first before calling any other methods that retrieve data. The readme file says that in order to use the LabVIEW API wrapper you need to call the "OpenQdInstrument" VI; this implies that you need to make a similar call to the assembly.

 

I realise you are trying to use the QDInstrument.dll assembly directly and not use the provided LabVIEW wrapper VIs however I would suggest you use the provided VIs in the LLB:

  • Copy "QDInstrument.dll" and "QDInstrument.llb" into the same folder as that project you originally posted (with the settemp.vi)
  • Create a LabVIEW project and add both these files in. Also add your original VI (settemp).
  • Use the VIs in QDInstrument.llb as the readme describes (Open, followed by SetTemperature etc.). There is no specific Close, instead use what the readme suggests and add a Close Reference node.

Try this and let us know how you go.

0 Kudos
Message 6 of 8
(4,777 Views)

Out of curiosity, have you attempted using the VI's published here? I use these when working with the PPMS here. 

 

https://jrfriedman.people.amherst.edu/ppms-labview.html 

0 Kudos
Message 7 of 8
(4,681 Views)
Solution
Accepted by topic author laura2018

I had to contact Quantum Designs (the providers for the dll) and they weren't too sure but they believe that a Windows update led to some problems with the dll itself. I let the applications engineer remotely control the computer and they downloaded a new version of the dll. But since the VIs used the old version (which meant we had to replace every VI with the new version), he used the old version again which worked for some reason. We aren't too sure why this worked, or what could even cause a problem in the first place for a previously working VI to give an error message other than from some issue from an update, but now it works! Thanks guys for your time and help 🙂

Message 8 of 8
(4,656 Views)