Calling DLL using "Call library function"

I am trying to combine labview with my previous fortran functions using Intel Visual Fortran 12.1 and labview 2012 by below steps.
1. Compile Fortran functions as DLL file.
2. Call Fortran function from LabView via "Call library function"
In step 2, DLL file without linker option "/DLL delayimp.lib" cannot be loaded. That is "delay load" is needed for DLL file.
Are there any limitation or constraint in Call library function?

Hi Vishnu,
There's no problem using the Malloc function in C and call it as a DLL in LabVIEW.
But LabVIEW has a different memory management than C.
It is probably not recommended to allocate array memory in C for labVIEW arrays
You can use initialize array in LabVIEW instead.
Good luck
Van L
NI Applications Engineer

Similar Messages

Call a special function in the dll using Call Library Function Node????

Dear all,
I am calling a special function in the dll using call library function node. There is a input parameter that it is a enum type in this function. I don't know how to deal this parameter for calling this function.Has anybody solved this problem?Please advise!
I am appreciated of you anytime.

Most of the times an enum is just a U8/U16/U32, internally so probably you can call it with just a U8/U16/U32 or something. For the correct value you have to look at the definition.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

Using the Library function node?

I am using a Library Function Node to call a DLL function. It works perfectly on one computer and Labview 8 but on another computer with Labview 7.1 it does not work.
It crashes everytime it hits this node call.
The problem is that, even after I define the node call to a specific function in a DLL, when the VI is running it defaults to an old DLL and function that is no longer in the syetem. Why does it default to this old call and how can I break the default so it calls the proper function that is define in the node setup defintion.

Hi irfocus,
I am not sure why the the Call Library Function Node is defaulting to what you had created before, but one suggestion I have that may fix this problem is deleting the one that is already in place and creating a new one from scratch that references the DLL you actually want. This should keep the new configuration.
Eli S.
National Instruments
Applications Engineer

Passing Variant to dll using call library function node

Hi,
Using LV2012
I have a dll that the following prototype:
SetTestResult(LPCTSTR Serial, int Test, int Result, VARIANT measuredValue);
How can I pass the Variant to this node when my variant can be either int or float.
I have tried "ToVariant" function but it is not sending data and gets error 1517 on LabView. For configuration parameters for variant I have used ActiveX type and datatype as activeX Variant Pointer.
So for call library function node my prototype looks like this:
int32_t SetTestResult(CStr Serial, int32_t Test, int32_t Result, VARIANT *measuredValue);
Can someone help me understanding What am I doing wrong here please?
Thank you,
Hiren
Hiren Patel

Hello Hiren,
Posting your code (even without the DLL) would definitely make it easier for people to point out potential issues. Here is an example that demonstrates passing an ActiveX variant to a DLL built in CVI, I would suggest cross-checking the way the Call Library Function Node has been configured.
Example:Transferring an ActiveX Reference Pointer to a CVI DLL
http://zone.ni.com/devzone/cda/epd/p/id/3343
Regards,
Tom L.

Crash "DAbort 0x37C03D in MemoryManager.cpp" when calling DLL with "Call Library Function Node"

Hi all,
I would like to work with a LabVIEW program that I did not programm by myself.
In this programm an external DLL needs to be called. in the Momente this dll ist called with the "Call Library Dunction Node" LabVIEW crashes with this Error Message:
DAbort 0x37C03D in MemoryManager.cpp
Attached is the entire Log.
The programm runs on the computer of the original programer.
I have never handeled with DLLs or something like that before, so I have absolutely no idea how to rsolve this problem.
Thanks for your help!
Attachments:
lvlog.txt ‏2 KB

A DLL can be compiled by different compilers. By "generic" C DLL, i refer to ANSI C (so no C++, no Borland C or something else).
My question is raised as parameters, esp. arrays and strings, can lead to this behavior when used in the wrong way (including "Calling Convention").
Also, interfacing with the LV memory manager can lead to crashes like this, but this wouldn't be a "generic" DLL as it binds to LV (due to LV API calls).
Without a better knowledge on the DLL and its functions, there is not much we can help you with.
Where does the DLL come from?
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Calling DLL using LabVIEW 7.1

so, i have this DLL which might be compiled using Visual Studio 2003 or Visual Studio 2005.NET.
question is: Can i call DLL functions using LabVIEW 7.1? has anyone tried it and has any issues loading the DLL?
i think i have everything right, as far as the configuration of 'Call Library Function Node' is concerned, but i get the
'error loading DLL - application has failed to start because application config is incorrect'.
can you please verify if .NET is not causing me issues? i think DLL assembly should be the same wheather it's VStudio6
or .NET, but can anyone confirm that's not the issue? Thanks...

Yes.
If you dll is generated by C/C++, using Call Library Function node.
If it is generated by .net, using constructor node.
http://forums.ni.com/ni/board/message?board.id=170&message.id=206959#M206959

To call webmethods using RFC(Remote Function Module)

Hi Sap Group.
i have got a situation on how to call the webmethods using Remote Function Module ,i know that there should be rfc destination created in sm59 already,so can i use the same existing rfc destination which was used to call webmethods with another scenario in my interface.
can anybody help me in this.
regards.
Varma

Hi Naina,
Normally RFC are synchronous, they do have return parameter as export parameter.
If return parameter is missing then , you can create Wrapper RFC.
Wrapper RFC:
It is nothing but you just create BAPI in SE37 transaction with Return parameter as export parameter and make it remote enabled by clicking on Radio button.
Under source code, CALL BAPI which XI has to call.
Thats it!
I hope this helps.
Let me know if any help required.

Error when building DLL using Keithley library

I'm trying to build a Labview Shared DLL of my VI's, however I'm using Keithley's KPCI-PIO24 Labview driver. When I include any of their library calls into my DLL, I will get a "LABVIEW.LIB was not called from a Labview process". I have mass compiled all the Keithley libs but this hasn't helped. Any ideas??
Bob Wirth

I am not 100% sure but I beleive that the KPCI line of drivers are DOS based. I know that Keithley's GPIB driver is DOS based. I am not sure about the labview drivers. This may have some effect on building a DLL. You may have to settle for building a llb instead of a DLL.
- tbob
Inventor of the WORM Global

TS3406 I am unable to see an incoming call and use call waiting if I am on a phone call!

Sprint says its an Apple Problem... Anyone else having this happen?

Call Waiting is a carrier feature, contact the carrier to troubleshoot.

Changin Passwd using PAM Library functions

We wrote code that uses "pam_chauthtok" to change password on Solaris 7 machine. However we get "dlopen" error when we run the code.
We even changed the PAM.conf and added a line that loads pam_pwmgt.so.1 but still failed to make it work.
Unable to figure out, Please help.
Thanks,
cldev.

Did you find any solution to this problem

Using call library function on a dll file created in an old version of labview

So I'm trying to update an old labview program to work in labview 2012. Everything converted over just fine but labview will always crashoverwrote some while using a library function in a DLL that was compiled using labview 8.5. Labview exits, stating that it vital memory area. It passes an array of data to the library call and an empty array for output. I thought I could get around this problem by changing my code to initialize the array being passed in so that it would be large enough to hold all the expected output. Now instead of overwritting areas of memory it shouldn't, I get a pop up message that says:
fatal internal error
memorymanager.cpp line 406
8.5.1.f5
So it appears because I don't have the ability to recompile the DLL file it runs off of the 8.5 runtime instead of the more recent one. Is there any thing I can do about this?

rjpierce wrote:
So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with.
Your problem most likely is that you try to pass native datatypes to the DLL function? That only can work if the caller and callee use the same LabVIEW runtime engine. Otherwise the memory block created in the memory manager of the caller will be accessed by the memory manager in the callee and bad things happen. Instead you should define the DLL function to use standard C datatypes (Pointer to C array) and also make sure to allocate the according buffer in the caller for all output array parameters.
An even more elegant way would be to completely abandon the DLL approach and call the according functions directly in LabVIEW. Then you won't have the problems about mismatched runtime engines. Passing C array pointers to a DLL is less performant than passing native datatypes, but if you use native datatypes you have to make sure the DLL is compiled in the same LabVIEW version as the one you call it from.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Does a reentrant dll call monopolize the calling thread?

If I understand thing correctly, threading for a dll call is the same as threading for a vi whose execution priority is set to subroutine.
To review threading in subvis:
(1) the thread in which a subroutine-execution-priorty-vi call is made is monopolized by the subroutine-execution-priorty-vi since labview cannot time slice the thread.
(2) if the subroutine-execution-priority-vi is not reentrant, then other threads that call the vi may be suspended because they are competing for the same code resource.
(3) if the subroutine-execution-priority-vi is reentrant, then other threads may call the vi simultaneously. However, within any particular thread the vi must complete because of point (1).
In
sum, the OS timeslices between the threads, and labVIEW timeslices within the threads. If a vi's execution priority is set to subroutine, then the thread under which it is running is monopolized by the vi. Yes?
A reentrant dll call would be equivalent to a reentrant subvi call in which the subvi's execution priority is set to subroutine. Yes?
If the above is correct then this should also be correct:
Using an API call to return the thread ID, you could use the the thread ID at the front and back side of a dll call, as well as in a message library function callable from a dll, to theoretically message labVIEW upon the dll return. The message would be uniquely identifiable because a dll call cannot be superceded by another dll call from within the same thread. Yes?
I'm not saying that it would be particularly efficient to do so, only that it could be done. And depending on the messaging, it could be a useful option in the dll call configuration dialog box.
In consider
ation of "magic",
Kind Regards,
Eric

Eric,
I'm not sure I understand exactlly what you are trying to do here.
If you want LV to react to a dll error, why don't you just pass a return
code that's not zero? Then, back in LV, read the return code. If it's not
zero, create an error, and pass this to the rest of the code. The rest of
the code is (or should, following good programming practise) has an error
in, and the code will not execute if the input error is TRUE. It does not
even have to be the return code, it could be any input value. The input
values can be changed in the code, and the modified value is returnd to
LabVIEW.
If you want to generate an error, and put it into a buffer to be read later
on in LV, you'll have to synchronise the code. This is the consequence for a
construction like this, and is the same for several windows API's
(GetLastError, etc.). the buffer will stay in memory, untill all instances
of the dll are released from LV memory.
BTW: A dll could create another thread. This thread can run on the
background, like the good old TRS's in dos. (A thread like this could even
call a LabVIEW VI that is build in a dll, just like any other api.)
BTW: A thread created by a dll can be made to be automatically released when
the thread is detatched, or when the process is detached. This is important,
because LV will crash if the dll is removed from memory, but the thread is
not stopped properly.
Regards,
Wiebe.
"Eric6756" wrote in message
news:[email protected]...
> Greg,
>
> As I think I lost you in the point of this line of questions, let me
> back up.
>
> A couple of week ago I asked the following question, "Is there a
> labVIEW library call that can be made from a dll to tell labVIEW to
> abort the calling vi thread?" To that question you made the following
> statement:
>
> "... and I doubt that there is a function to do that from a DLL as the
> DLL could be arbitrarily deep down the stack and the function called
> would have to magically find the VI that it wants to abort. And don't
> forget that DLLs can be called by multiple VIs at the same time."
>
> You seem to be saying here that what I'm asking for is not possible.
> And having thought about this for a while, I didn't understand why
> not.
>
> For the moment I'm going to ignore the caveat you just put into the
> dll calling presumptions I've made and assume the dll is going to
> execute synchronously within a thread. As the original question
> suggests, the objective here is to message labVIEW from a dll to
> provide the same functionallity as a CIN, namely return an error code
> to labVIEW from a dll.
>
> A library function could do this as follows:
>
> First, the library function would have two modes; set error, and
> return error
>
> (1) set error:
>
> 1.1 get the set error caller thread ID from API
> 1.2 get the passed in error
> 1.3 store the error and associated thread ID locally
>
> (2) return error
> 2.1 get return error caller thread ID from API
> 2.2 locate the error, if any, associated with thread ID
> 2.3 return the error and clear it locally
>
> Now, if a dll encountered an error that it wanted labview to deal
> with, it would call the error function to set the error code. When
> the dll call returns control to labVIEW, labVIEW could call the
> function to return the error. This of course works only if the dll
> call is synchronous within a thread. Obviously, if the dll releases
> the thread before it returns, then more than one dll call can be made
> from the thread and the presumption that an error could be uniquely
> associated with a thread is itself an error.
>
> Having looked at your reply again, I think though your answering a
> different question than I asked. I just wanted a function to message
> labVIEW to abort the vi chain, I don't want to abort a vi chain from
> within the dll. It is a feature of CIN calls which I wanted in dll
> calls.
>
> That a dll call may not be synchronous within a thread throws a wrench
> in the works. Apparently I've just chased down a dead end.
>
> Hey, but thanks for the wrench...
> Kind Regards,
> Eric

Calling Dlls from LabVIEW

LabVIEW Gurus:
I am working with some software engineers who have no experience in LabVIEW. Unfortunately I have little experience in C/C++ to make sense of their inquiry.
Basically we are dealing with “Data Marshalling”. I will call a DLL and issue a command (string) and get back a 2-D array and an integer. So far so good.
The C/C++ programmer requested that I provide them with a pointer/memory address in which they will store data, so I can read it once the dll returns the array and integer. I browsed through the example online http://decibel.ni.com/content/docs/DOC-1690 and thought that if I wanted to read from the dll, the process is a simple as calling the appropriate function and configure the parameter (no pointers needed).
So, is there a specific way that they need to write the C/C++ code to be used in LabVIEW? Or what else to I have to take into consideration?
Thank you,
Santiago

That example is pretty simplistic as it only deals with integers. In this case no pointers are required since everything is returned by value. When you're dealing with arrays, however, you need to deal with pointers. If you open the Example Finder (Help -> Find Examples) and search for "dll" you will see the "Call DLL" example. That contains many examples of how to call DLL functions with a wide variety of datatypes. I strongly suggest looking at that example. There is also a chapter in the LabVIEW Help on calling DLLs (Fundamentals -> Calling Code Written in Text-Based Progamming Language).
You have 2 things to consider:
You're dealing with arrays - this means you typically need to pre-allocate the memory in LabVIEW, and it sounds like that's what the DLL expects you to do. This amounts to using the Initialize Array function to create your 2D array of the appropriate size and datatype.
You may be dealing with a C++ DLL. LabVIEW can only interface to C DLLs. This doesn't mean that you can't create a DLL in C++, but it does mean that the C++ programmers need to add an extern "C" modifier to the function calls, otherwise you get name mangling, and LabVIEW won't be able to call the DLL. The DLL programmers should know what that means.

Asynchronuous functions don't work in a C# dll used by a CVI application

Hello,
I have an existing application written with CVI 9.0.1, which have to interact with a C# 2010 dll (which doesn't have any window) via a CVI<->.net wrapper (created using the usefull .net controller of CVI).
This C# dll uses asynchronuous functions, like NetworkStream.BeginRead() and EndRead() functions of a System.Net.Sockets.TcpClient object for example.
These asynchronuous functions work fine when the C# dll is used by a C# application (having a main window) or when the C# dll is converted in a standalone C# program (having a main window with buttons, to call its methods, just to try), but asynchronuous functions don't work when my C# dll is called by my CVI application (which is my goal): execution stays inside NetworkStream.BeginRead() for example (for the concerned thread).
NetworkStream.BeginRead() can be successfully bypassed by using the synchronuous function NetworkStream.Read() instead, but the C# dll uses others asynchronuous functions wich have no associated synchronuous functions.
Here is a portion of C# code (I don't have the source code for the Snmp object ; got_trap() method is never called when asynchonuous calls don't work):
public void run() // the thread
Snmp snmp = null;
try
  snmp = new Snmp(true);
  snmp.NotifyListenPort = 162;
  snmp.NotifyRegister(null, null, new NotifyCallback(got_trap), CB_DATA_);
  isActive = true;
  Thread.Sleep(Timeout.Infinite);
Thinking it could be a problem with window messages which could be not processed (in the C# dll), I tried to replace the Thread.Sleep(Timeout.Infinite) instruction, in the code where the asynchronuous management take place, by a window creation plus my Win32 window message loop, but asynchronuous functions don't work better (whereas my loop seems to successfully process messages):
Form myForm = new Form(); // an empty window
myForm.Show();
int bRet;
MSG msg = new MSG();
while ((bRet = GetMessage(out msg, IntPtr.Zero, 0, 0)) != 0)
    if (bRet == -1)
       // handle the error and possibly exit
    else
      switch (msg.message)
      default: // everything else
        TranslateMessage(ref msg);
        DispatchMessage(ref msg);
        break;
Any idea ?
Thank you,
rvfr.
Solved!
Go to Solution.

Solved: in fact, the snmp assembly that I was using just needed to be dotNet registered.
rvfr.

Calling dll method from oracle forms

Hi,
This is my first post in this forum. I don't know whether this is the right place to post this topic here.
i wana call DLL method from the button click event of my form.
I new to oracle development any help will be greatly appreciated.

Calling DLL using form 6i
Regards,

Calling DLL using "Call library function"

Similar Messages

Maybe you are looking for