Greetings everyone, this thread is closely related to this one: https://forums.ni.com/t5/LabVIEW/Controlling-an-Addi-Data-CPCI-3009-via-LabVIEW/m-p/3361295#M989039
But since the issue has shifted quite a bit, I believe it is best to have its own, more descriptive thread. After digging a bit, I found what might be the solution to my problem, an installer containing a .dll that I could, theorically, use to command the card from LV via dll invokes. I have digested every bit about the topic I could find, but I have hit a brickwall again. I can open the reference to the dll just fine, but when I try to use an invoke node, I get an "error 1172 System.EntryPointNotFoundException."
I have attached the project folder, which contains the dll as well. Originally it claimed it could not find the required dll, so I set one with the name constructor node wants, and one with the name invoke node wants, but they're in essence the same, just different names. I am attempting to call the open board with an empty string, which since I do not have the card in this system, should return either a -1 (not available identifier) or -2 (board not available), but instead I get the error. I have even attempted to uninstall and reinstall the .net framework, with no success in the problem whatsoever. Is there something else I am missing?
The .zip contains:
-A barebones project with just a build and call VI
-The include folder with the .h file (unsure if needed, unused so far)
-The .net based dll folder found
-The documentation regarding the properties that can be accessed.
Shall you require the whole package (just examples in C and the such) it can be found here: ftp://addi-data.com/
I used the CD option (the big 294MB file), but directory also lists a 3009 option which I am unsure what does.
Solved! Go to Solution.
I found some links about the subject, take a look at them if you haven't
I also suggest you search for that error on Microsoft and changing .NET (either upgrade or downgrade)
Hey there, thanks for the advice, tho I had already seen those and they don't shed much of a light in the subject, since my dll does not (at the moment) reside in a network drive, and I preemptively called it from the project folder. I however found out that the solution was laughably simple.
Turns out the dll must also reside in c:/windows/syswow64 (or sys32 if for some reason you still have a 32 bit OS) in order for LV to be able to correctly call it. Crazy right? But as soon as I copied it to the system folder, it worked.