.NET error 1172

[merty]

Warning: LabVIEW Beginner here

Problem Description :
-I'm using equipment which has a DLL which I would like to access with LV2009SP1
-The DLL works with .NET V3.5
-I'm using Windows 7 with .NET V4.0 and V3.5 installed, recently updated
-I'm receiving Error 1172, the .NET Exception, and cannot initialize commands
(I can't seem to get a RefNum for the device)

-I've tried pointing the constructor to the dll several times
-The code is relatively simple, and is attached
-Image also attached with the simple part of the code that's tripping the error

Note:  I've communicated successfully with the device before with the same LV version and OS, but after moving and updating the DLL I'm having this issue.

Thanks for anyone's time, help, and patience!

[mikeporter]

Is this error occuring on the first iteration of the loop? Are you sure that you are using the DLL correctly? Have you talked to the vendor?

Mike...

[nathand]

Is this a subVI, or the top level? If it's top level (the VI on which you hit the run arrow) then you need a .NET constructor for the class, instead of the class refnum control. That gets you an actual instantiation of the class, rather than a control of the appropriate reference type that doesn't refer to anything. The one exception is a static class, in which case you still don't need the class refnum control (and you also don't need a constructor).

[merty]

Replying to both NATHAND and MIKEPORTER, (thank you both so much for your input)

MIKEPORTER,

Please see attached. 
It does occur on the first call, or first loop iteration (i=0).  Because I've gotten this to work before with an older version of the .dll, and because the vendor doesn't really support LV applications (they provide a stand alone software), I haven't tried contacting the vendor. Regarding the old .dll, this also doesn't work currently, so I don't think that the new .dll is the issue.

NATHAND,

Please see attached. 
Although it is a 'get instance' subvi, which is why the refnum was there in the last block diagram, I'm trying to use it for troubleshooting and testing as a stand alone (I will replace the 'constructor' with the refnum control after I figure out how to get the right call to the .dll in the top level vi), basically I thought I could point it to the .dll all the same, which is what I had shown in the last appraoch. You mentioned 'it doesn't refer to anything', but I can pointed it to the .dll, or so I'd thought.
In the new attachments you can see I've tried the constructor approach, but this causes another issue: THIS CLASS CONTAINS NO PUBLIC CONSTRUCTORS.  When I got it to work a couple years ago, I don't remember using the constructor either...

Might anyone have any other thoughts?

Thanks a ton,

[mikeporter]

The first problem to fix is the constructor issue. There is a check box that let's you only see classes that are creatable.

Mike...

[nathand]

Mike - I think that option is only for ActiveX objects, because when you browse for a constructor, of course it shows only creatable objects.

Merty - the class control has the correct data type - it can only refer to a .NET object of the type selected from the DLL - but it doesn't refer to an actual instance of that object, which is why I said it doesn't refer to anything. You need to create (using a constructor) or somehow otherwise obtain a reference to a specific instance of the desired .NET object.

[merty]

Thank you both greatly for your input.

NATHAND-
The best way I've identified is to create the control, refer it to the .dll, and select the method from the list available, as the constructor won't allow me to reference the method I need (...Base.TubeInterface).  The method I need is shown (...Base.TubeInterface), which I know is the required one to create an instance, in order to access the other features.

Would trying to get the methods with the C++ approach be a good option to try (again, I know .NET has worked in the past, but I'm running short of ideas)? Is it very likely to be an issue with the .NET installed in Windows 7? I have tried updating both V3.5, needed for the .dll, and V4, which I believe is needed for labview .NET code, and they seem to be installed correctly.

Any other suggetions?

I'll also mention that the .dll is currently in a subfolder from where the top level .vi and .lvproj are stored.

Many kind thanks.

[nathand]

Well, you can try removing the class control entirely and see if that works; if it's a static class, the property node it will use the single static instance.

By the way, there's no need to check if a Boolean is equal to true, instead wire the Boolean value directly.

[merty · Accepted solution]

I've got my program back up and running, but I didn't exactly solve this issue. There is nothing wrong with the coding I've posted, i.e. no 'constructor' necessary- its works with a .NET reference constant or control after referencing the .dll, timing is fine, etc.  I identified that the problem is with the .NET version the .dll was written in having incompatibility with LV2009SP1. I suspect that the .dll I was attempting to use would have worked fine with a newer version of LabVIEW.  I solved my woes by simply downgrading the old .dll, which I was using before.  In otherwords, I never got the new .dll to work with LV2009SP1's .NET.

Some possible explanation of this are below:

https://www.ni.com/en/support/documentation/bugs/09/archived--labview-2009-and-2009-sp1-known-issues... (LabVIEW constructor node cannot load dlls written in .net 4.0)

https://www.ni.com/en/support/documentation/bugs/09/archived--labview-2009-and-2009-sp1-known-issues... (Explanation of the known issue)

I think the new .dll which I was unable to grab with LV2009SP1 was written with a different .NET version than the previous, whereas the previous was, I believe, in .NET V3.5.  Even though the articles allude that 3.5 could pose an issue in LV2009, it seems to be an exception.

If I decide the new .dll is absolutely necessary, I will try upgrading to the latest LV, it seems they've worked this out.

(If it ain't broke, don't fix it)

Thank you both for your ideas.