How to fix .NET error 1172 "Unable to cast object of type: 'System.ComponentMode

[colby10291]

I am working on integrating a SDK - provided by AutoLab Metrohm - into a LabVIEW project. They provided examples files for me to follow, but I cannot seem to get the examples working correctly. I have identified the source of the error, but do not know how to resolve the issue. 

The main VI returns the error shown in the mainVI.png. I opened up this subVI and took a closer look to discover that the 'connect' Invoke Node was the location where the error is returned. 

In case you can't read the .png error, it says the following:

"Error 1172 occurred at Property Node (Arg :1) Error accessing property EcoChemie.Autolab.Sdk.AutolabConnection.IsConnected, (System.ArgumentNullException: Key cannot be null.
Parameter name: key)

Possible reason(s):

LabVIEW: A .NET exception occurred in an external assembly. For information about correcting this error, copy the following exception (in bold), and search the Microsoft Developer Network (MSDN) Web site or the Web for a possible explanation.
System.ArgumentNullException in [TN#5] FRA example (A).vi"

I am attempting to run this code on Windows 10, .NET version 4.7.2, LabVIEW 16.0f2 32-bit, and the sales rep at Autolab informed me that the code was written for .NET 4.0. I have tried to install 4.0 on my computer, but the installer detects my current version and terminates the installer. I have tried disabling .NET 4.7.2 using the "Turn Windows features on or off" option, restarting my computer, and re-running the installer; no success.

Aside from editing the original code used to compile the .dll, is there anything else that I can do to fix this issue? At the moment, I just need to prove that I can control this device through LabVIEW as soon as possible because our deadline for ordering is the end of this week.

Thanks for your help!

[tyk007]

You are describing two exceptions. I think the one you are receiving first is in the title of the post; the second one (an error thrown probably by a Dictionary-related type) is probably as a result of continuing after receiving the first.

Framework 4.7.2 is highly backwards compatible with Framework 4.0 and the CLR is the same - so I suggest it is unrelated to the Framework at all. Make sure to re-enable that again. Frameworks 4.x are in-place updates for that reason which is why the installer refuses to continue.

Can you zip your project (including the assembly(s) and AutoLab SDK) so that we can investigate further?

[colby10291]

Thank you for your incredibly quick reply!

I have re-enabled the Framework on my computer, and I have attached the .zip file, provided by AutoLab, with all the example files and assemblies as you requested. I am running a PGSTAT204, if that helps. 

Let me know if I am missing anything!

[tyk007]

Obviously without the hardware I get an exception stating that there is no valid instrument.

Can you probe your Connect.vi when running and establish the source (ie which node calling the Instrument object) of the error being generated? Is it occurring on the property set of "EmbeddedExeFileToStart" or on an earlier call such as property get "AutoLabConnection" or property set "HardwareSetupFile"? The .NET nodes do not execute if there is an incoming error and simply pass that error onto the output of the node.

[colby10291]

Sorry for the delay.

If I understand your question correctly, you would like me to probe the connect.vi to determine what block causes the error, specifically? I have set up a probe on every error wire in the chain inside the connect.vi and have identified the first time that an error code is returned. The error first occurs at the invoke node called "connect" (see probe 13 in connectVI.png attached)

Is this what you were asking me to do? I apologize for the confusion.

[tyk007]

Can you copy here the entire content of the "source" element of the error cluster (you can copy the text from the probes "Explanation" textbox).

[colby10291]

SOLVED

I have managed to get the code working correctly!

To get the VI working, I had to open it using the LabVIEW project window. It was that simple. However, I am a little confused why this resolved my issue. I have never written code using a LabVIEW project before, but I assume that some dependencies were loaded (or at least pointed to) by the project folder, somehow?

Thank you for taking the time to help me!

[tyk007]

My bad, I had assumed you opened the project file and then ran the relevant example VI. 

LabVIEW Projects are designed to help manage ... well projects. They are basically essential for any real form of development beyond "just one VI" and have the added benefit, in your example, of providing the .NET CLR Fusion component alternative search paths for assemblies. If you just open the VI directly without a project then the LabVIEW executable folder (ie Program Files) is used as a base search path.

If you plan to do any work in LabVIEW I would strongly suggest always (always, always!) using a LabVIEW project, even if you only have a handful of VIs. If you have never used them before it is well worth your time getting to know them better; there is a lot in the LabVIEW help around that.