Fatal internal error: "extfuncdlg.cpp", line 2212

[stefanoc]

Dear all,
  I'm facing a problem designing a Call Function Node Vi in order to access a DLL. Using LabView 8.2 I obtain the error message reported on the subject of this post. The error raises only at the moment of the Vi creation because, creating the same under linux and then changing the name of the .so library to the .dll library, it works perfectly. So it is not a "real" problem, there should be some sort of erroneus control during the creation. From the log (that I attach in the following), I see that the problem could be related to the return type. I defined the return type for the VI as Signed 32bit Integer that should be the correct one since in the DLL the return type is an enumerator.

Here is the log of the error:

.\diagram\extfuncdlg.cpp(2212) : DAbort: Invalid Return Type
$Id: //labview/branches/Europa/dev/source/diagram/extfuncdlg.cpp#26 $
0x00A1F581 - LabVIEW <unknown> + 0
0x0055FDBC - LabVIEW <unknown> + 0
0x00C47531 - LabVIEW <unknown> + 0
0x00C497C6 - LabVIEW <unknown> + 0
0x004CCB39 - LabVIEW <unknown> + 0
0x00565209 - LabVIEW <unknown> + 0
0x005B859C - LabVIEW <unknown> + 0
0x006C2D7D - LabVIEW <unknown> + 0
0x00C46D4F - LabVIEW <unknown> + 0
0x00C4796D - LabVIEW <unknown> + 0
0x00C497C6 - LabVIEW <unknown> + 0
0x004CCB39 - LabVIEW <unknown> + 0
0x004D7C95 - LabVIEW <unknown> + 0
0x004DF19A - LabVIEW <unknown> + 0
0x7739C3B7 - USER32 <unknown> + 0

Thanks in advance,
Stefano.

[carlo&gt;]

Hi stefanoc,

Your problem seems to be, effectively, a bug that recquires to be fixed. Doing some researches I found a couple of documents that whitnessed similar (but not identical) problems when using Call Library Node function in LabVIEW.

Please, can you post a copy of the dll and the precise steps needed to reproduce your crash? In that way we can further investigate the problem trying to find a solution.

However, the workaround you've found of passing from .so to .dll seems to be, right now, the best way to face the problem.

I'll wait (if you can) your post.

Have a nice day

carlo>    

[stefanoc]

Hi Carlo,
  thanks for your reply. In the attached zip file you can find the DLL together with the relevant header files.
In order to reproduce the problem you can simply create a new Call Library Node Vi and then try to connect it to a function contained in the DLL. Just after having selected the function from the combo box that shows all the function exported by the DLL you should get the error.

Cheers,
Stefano.

[carlo&gt;]

Hi Stefano,

I sent an official document about your issue at the US R&D. They're working on the problem.

Thanks for your kindness and for the precision in describing the problem and in workarounding it.

NI is proud of having customers as you!

Have a nice day 

carlo>

[Elizabeth W]

Hi Stefano,

Would it be possible for you to post the new dll that you were able to get working?  I am trying to find a workaround to this same error but do not have access to the source code for the dll so I cannot create a .so file on a Linux machine.

Thanks in advance!

Regards,

Elizabeth L.

Applications Engineer

National Instruments

[stefanoc]

Dear Elizabeth,
  I added the .so version of the library to the zip file. If you really need th esource code of the library I prefer to send them to you in a different way rather than posting them on the public forum.
Let me know.

Best regards,
Stefano.

[Elizabeth W]

Hi Stefano,

I have tried renaming the file libCAENVME.so.2.6 included in the previously attached zip file to a libCAENVME.dll but this does not work.  Perhaps I am misunderstanding the workaround.  How did you get that to work?  I would really appreciate your help.

Best regards,

Elizabeth L.

National Instruments Applications Engineer

[stefanoc]

Hi Elizabeth,
  I try to explain better the workaround I found. The problem is that Labview crashes when we try to define a call to the function inside the DLL using the user interface under the windows operating system. What I found is that using labview under Linux I can define the VIs that call the functions inside the .so library (that is the same as a DLL in Windows) without causing the crash. Then I get the VIs created in Linux, I copy them on a Windows machine and I rename the name of the file in the user interface from libCAENVME.so to CAENVMELib.dll. In this way Labview does not crash and the VI works fine. So, in my opinion (but I only imagine it since I don't know the Labiew source code), the problem is related to the user interface or to the code that link the VI to the function call and it is not a problem of compatibility with the library.
Let me know if you need further details.

Best regards,
Stefano.

[JordanH]

Elizabeth,

Did you ever succeed in getting this fix to work?
I tried it but had no luck.  I got a Windows error saying that the file is not a valid windows image and then a LabVIEW error stating that "Some system capacity necessary for operation is not enabled. The file 'libCAENVME.dll' is not a valid LabVIEW file."


Jordan

[Elizabeth W]

Hi Jordan,

Actually, Stefano and I have been working on this issue.  The reason this crash occurs is because the CAEN dll is returning a data type that is unsupported for the Call Library Node.  Stefano told me last week that he is going to work on seeing if he can update the library to resolve this issue.  I will update you as soon as I hear back from Stefano about whether or not he is successful with this.  Please let me know if you have any other questions!