Call library function node function
你好, Labview版本為6.1,
做一簡單的dll檔, 用call library function node 出現function not found in library錯誤,
不知道錯誤為何? 附上附檔,請幫忙解惑,謝謝
Attachments:
test.zip 5 KB
You have a *.cs file so most llikely are generating a .Net assembly, not a Win32 PE shared library. As such you need to use the .Net functions in LabVIEW to interface to it, not the Call Library Node.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions
Similar Messages
-
Call library function node: function not found in library
I'm using Labview 6.1 and Windows XP. I am trying to open some code, but it opens up with a broken arrow. The error is Call Library Function Node:function not found in library. Tried to configure the node, but no change. Moved the DLLs to various directories (keeping them together) but again no change.
This code has been compiled and is working fine. I'm just trying to run the source code to make some modifications. Any suggestions?
Thanks
CarlosVThanks for the suggestions. Tried it but had the same results. The library I'm using is hpe1413_32.dll.
One thing I forgot to mention....doing a configure on the node, it comes up with the library: hpvscp32.dll and the function: hpe1413_error_message
The function doesn't exist in the library. So I set the path to hpe1413_32.dll which does contain the function.
After closing the configuration window and opening it up again, the library shown is hpvscp32.dll
From what I can tell, there are three libraries involved:hpe1413_32.dll, hpe141332v.dll, and hpvscp32.dll
Thanks again.
Carlos -
Call library function node - function not found
When creating a DLL I get a the Labview error "Call Library Function Node "LabviewReceiverDLL.dll:readDataJ1939Data' Function not found. Everything looks correct to me and this used to work, though I've changed computers since then.
This is the beginning of my C++ code just to show my function name. I've also attached the Call Library Function Window to show my setup.
Thank you in advance for your help.
#include"StdAfx.h"
#include<iostream>
/* Call Library source file */
extern"C"__declspec(dllexport)unsignedint readDataJ1939Data(unsignedint, unsignedint, unsignedchar, unsignedchar* canData, unsignedchar* path);
unsigned int readDataJ1939Data(unsignedint ulTimeStamp, unsignedint ulIdentifier, unsignedchar uiDataCount, unsigned char* canData, constchar* path)
Solved!
Go to Solution.
Attachments:
Call Library Function.png 192 KBYou mention that you have changed computers and that it used to work before.
Could it be that there is another (older) copy of the DLL on this computer, and LabVIEW is loading the wrong one?
The simplest way to check is to close your VI and delete the one you are expecting it to use. Then open the VI again; if LabVIEW doesn't ask you where the DLL is, it is loading it from somewhere else.
Batya -
Resizeing an array of LStrHandles within Call Library Functio Node crashes SubVI.
Hello,
I try to resize an array of LStrHandles within a shared library. Here the C-code - attached a picture of the calling SubVI:
/* Call Library source file */
#include <stdio.h>
#include "extcode.h"
/* Typedefs */
typedef struct {
long dimSize;
LStrHandle elt[1];
} TD1;
typedef TD1 **TD1Hdl;
long strArray(TD1Hdl arg1);
long strArray(TD1Hdl arg1)
long err=0, count=2;
err = DSSetHandleSize((UHandle)arg1, sizeof(long) + count*sizeof(LStrHandle));
if(err) {
printf("ERROR: 'DSSetHandleSize()': %ld\n", err);
return err;
(*arg1)->dimSize = (*arg1)->dimSize;
return noErr;
I know there are a lot of threads, I read some and also tried the provided source code but somehow LabVIEW crashes. I don't know if it is valueable but when I change the following line it does not crash:
(*arg1)->dimSize = (*arg1)->dimSize;
Thanks for any help,
Johannes
OS: RedHat
LV: 8.2 Prof
Message Edited by [email protected] on 03-11-2009 12:26 PM
Solved!
Go to Solution.
Attachments:
subvi-resize-stringarray.jpg 7 KBTo be honest I'm not fully sure why that would crash but proper dealing is a lot more complicated than what you have done. The crash probably happens not in the C fucntion but on return of the function as LabVIEW tries to display the data. DSSetHandleSize() does not initialize the area it allocates additionally so there is likely garbage which LabVIEW then tries to interpret as string handles and consequently crashes.
You should also use NumericArrayResize() whenever possible as it takes care of various complications that can be hard to deal with on multi platform programs. NumericArrayResize() does use internally DSSetHSzClr() which initializes additional memory to 0. That would avoid the crash since LabVIEW does interpret NULL handles as the default for the according datatype, which would be here an empty string.
#include "extcode.h"
#if IsOpSystem64Bit
#define uPtr uQ
#else
#define uPtr uL
#endif
typedef struct {
int32 dimSize;
LStrHandle elm[1];
} TDStrArr, **TDStrArrHdl;
MgErr MyArrayFunc(TDStrArrHdl arr)
int32 count = 4;
LStrHandle p;
MgErr err = noErr;
/* The array could be non empty so dispose of any elements in it that are bigger than what we need */
for (i = (*arr)->dimSize - 1; i >= count; i--)
p = (*arr)->elm[i];
if (p)
DSDisposeHandle(p)
(*arr)->dimSize = i + 1;
/* resize the array handle to get enough space */
err = NumericArrayResize(uPtr, 1, (UHandle*)&arr, count);
if (err)
return err;
/* Fill in the data as desired */
for (i = 0; !err && i < count; i++)
p = (*arr)->elm[i];
#if !complicated
err = NumericArrayResize(uB, 1, (UHandle*)&p, 1);
#else
if (p)
err = DSSetHSzClr(p, sizeof(int32));
else
p = DSNewHClr(sizeof(int32));
if (p)
(*arr)->elm[i] = p;
else
err = mFullErr;
#endif
if (!err)
err = LStrPrintf(p, "%ld", i);
(*arr)->dimSize = i;
return err;
Rolf Kalbermatter
Message Edited by rolfk on 03-11-2009 08:40 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions -
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 KBA 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. -
CALL Library Function Nodeで呼び出したDLLの解放
CALL Library Ｆunction NodeでDLLを叩いた後、
LabVIEWを終了するまで呼び出したDLLが解放されません。
解放する方法は有りますでしょうか？
OS：Windows XP
LV：プロフェッショナル開発システム 8.5.1
行いたい事
ある特定のパスにあるDLLを叩いて計測器を制御しており、
同じルーチンで類似型を制御したいのですが、
・どちらも同じパスの同名DLLでなければならない
・同名DLLは中身が違う
となっております。
つまり
1.計測器Aを制御する為にC:￥TEMP￥A.DLLを叩く
2.計測器Bを制御する為にC:￥TEMPをC:￥_TEMP等にリネームし、
B.DLLが入ったフォルダをC:￥TEMPとしたいが、A.DLLがLVで
ロックされていて出来ない
といった状態です。
どなたかご享受頂けないでしょうか。MEPHISTO 様
平素より弊社ディスカッションフォーラムをご利用頂きまして誠に有難うございます。
日本ナショナルインスツルメンツ技術部 黒須と申します。
LabVIEW 8.2以降のバージョンよりDLLを動的に呼び出すことが可能です。
[LabVIEWでDLLを動的にロード・アンロード] 大変申し訳ございませんが英語での文献となっております。
http://digital.ni.com/public.nsf/allkb/77594203D78D12278625729100758BE5?OpenDocument
こちらの設定はライブラリ関数呼び出しノードの構成画面でダイアグラムでパスを指定という項目にチェックを入れていただくことで、
DLLのファイルパスを指定してあげることができます。
DLLをアンロードする際には空のファイルパスもしくは無効パス指定関数を配線することでDLLを開放することができます。
記事にございます例では選択関数を用いてロード・アンロードを使い分けております。
ライブラリ関数呼び出しノードのヘルプ≫ライブラリ関数呼び出しをクリックしていただきますと、ライブラリ関数呼び出しダイアログボックスの説明がありまして、
そこでライブラリ名またはパスという項目でこちらに関しての説明もございますので併せてご確認ください。
よろしくお願いいたします。
技術部 黒須 -
How to call a C pointer from call library function node
I have a client/server application which the client I am trying to develop using Labview. When I use to communicate the server and the client using the program provided by the manufacter, the system works perfectly.
Now, I am trying to develop a system using labview, because I need to get another things.
I have the DLL provided by the manufacter and the .h too, so I can check the functions parameters. One of these functions needs to be called using a struct element. Probably, the function's DLL instantiates the elements of this struct. I use the call library function node to do it.
When I receive the data, the function returns to me the struct that I passed as a parameter before, and then I can read all the elements of the struct, except the string element that returns nothing. The struct elements that are numerical, I can read them perfectly.
Another thing that is important to say, is that the string data was not returned in fact by the DLL function that the system calls. I have to pass a pointer (I use it as unsigned 16 in Labview, but I tried before as string and unsigned 8) as a parameter, and this pointer will point to the memory location that the string is. When I try to read what is returned by the function, I can read nothing. The same function returns that the size of data that is returning is 17 bytes.
How can I solve it?
Thank you in advanceDid you take a look at the example that ships with LabVIEW that shows how to do all sorts of data passing to DLLs. I believe your situation is one of the examples listed. You can find the example VI in the "<LabVIEW install directory>\examples\dll\data passing" directory.
-
Window doesn't close wheh Call Library Function Node set to Run in Any Thread
This is a problem regarding Call Library Function Nodes running in the UI thread or any thread.
I have a camera which has its own API supplied as a dll. I have created a set of VI wrappers which each call a function in the dll through a Call Library Function Node.
Initially each CLFN was set to 'Run in the UI thread' (the default).
To start the camera streaming images I call (through a CLFN)
ICubeSDK_Start(int CamIndex, Hwnd, ImgHandle, bool Preview, bool callback);
If Preview = True then the image is displayed in a preview window.
If ImgHandle = NULL a default preview window
is used.
In the CLFN definition I define:
ImgHandle as a U32
Preview as a I32
To stop the camera streaming images I call
ICubeSDK_Stop(int CamIndex)
In the actual implementation I set ImgHandle = 0 (NULL) and Preview = 1 (true).
This all works fine, and a preview window is opened and images displayed. When I call ICubeSDK_Stop the preview window is closed.
However, I would prefer to set the CLFN to 'Run in any thread' because
a) when run in the UI thread the preview window randomly gets sent to the back when I switch focus between open VI windows (presumably because it is in the same thread as the VIs)
b) I don't want to put unnecessary stuff in the UI thread
c) my (naive?) understanding is that it is safer to run in any thread
So I have set all CLFNs to 'Run in any thread'
When I do this the preview window opens OK, and behaves like any other non LabVIEW controlled window in terms of focus. But when I call ICubeSDK_Stop() the preview window does not get closed properly, it just shows a blank image. I can't close it manually, there is no X in the corner and no option to close it from the taskbar. To get rid of it I have to close the LabVIEW project it is spawned from, which often results in a crash. It does appear as a separate item in task manager but if I 'end process' it, LabVIEW closes (and often crashes) as well.
If I change only the CLFNs that call the Start and Stop functions back to 'Run in the UI thread' then it all works fine again, except that the preview window gets sent to the back randomly as before.
So, what do I have to do to get the preview window to close properly if I set the CLFN to 'Run in any thread'.
Alternatively, is there a way to close the window programmatically (ie force it to close) after I have called ICube_Stop.
Thanks
DAveHi Dave,
The "Run In UI Thread" switches from the thread the VIs currently executing in to the user interface thread. If you select "Run in Any Thread", the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the User Interface thread.
Before you configure the Call Library Function Node to run in any thread, you have to make sure that the code is thread safe. Code is thread safe when it does not store any global data (e.g. global variables, files on disks, etc.), does not access any hardware, does not make calls to any functions, libraries or drivers that are not thread safe.
Unfortunately, since you said that your DLL accesses hardware, it is not recommended to use "Run in Any Thread." This is probably why you are seeing the crash.
If your preview window gets sent to the back you can programmatically bring it forward. Here is an example of how this can be done: http://decibel.ni.com/content/docs/DOC-4551
If you want to completely close the window down you can do so as described in this link: http://digital.ni.com/public.nsf/allkb/81E9C1441900FFCE8625748F0055DBB0?OpenDocument
I also thought you might find this useful: http://zone.ni.com/devzone/cda/tut/p/id/3009
I hope this helps.
Regards,
Mahdieh G
Applications Engineer
National Instruments UK&Ireland -
How to use Call library function node for a function in dll with VOID data type
Hi All,
I would like to ask for your kind help,
I am facing an issue with the call library node.
I have a C++ function(stdcall), which has void as data type
error code XXXX(hwnd, lID, getValue, *void data1, *void data2)
the data1 and data2 types are always changing depending upoin the value of "getValue".
Primarily i can use call library node multiple times and adapt each node according to the data types of data1 and data2, and extract the values and use in the code. Here is no issue. Real question is:
My question:
How can i just use one time call library node and make a case depending upon the "getvalue", which will control the data type of data1 and data2. Here i really looking for solutions.
My trials:
i used varaints as input to the call libray node for data1 and data2, and selected Parameters in call libraby node as " Adapt to type". here labview just crashed.
i really appreciate your feedbackand suggestions.
Thanks
Kutbuddin
Solved!
Go to Solution.
Attachments:
Clipboard02.jpg 103 KBA variant is a very specific LabVIEW datatype (really a C++ type object internally) and trying to pass that to a function, which excepts a flat memory pointer there, for sure will crash very quickly.
As to endianess, yes Unflatten will be able to adjust for endianess, which in this case however is most likely exectly NOT what you want. So make sure that the you select native type for the endianess input on Unflatten from String. LabVIEW internally works with whatever is the native endianess, as will most likely your C++ DLL. The platform independent big endian format does only come into play when you receive data streams over some streaming interface like a network connection. Here it is desirable to use an endian format that is independent from the actual platform that generates and consumes the data stream. LabVIEWs default endianes is big endian here.
But as long as you pass data directly to native components like DLLs there is no difference in endianess between what LabVIEW uses and what those components use.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions -
Call library function node in a loop
Hello All,
I am currently using a call library function node in a while loop which calls a third party dll to process and recieve some data.
My question is, if I am using this function in a while loop, what exactly happens?
Does the dll get called in each loop iteration, or does it keep the called dll loaded in memory and just pass the values to it to process data?
Also, if the answer to the above question is that it will make calls to the DLL in each iteration, how can we keep it loaded in memory always? I mean, if the DLL is a .NET application DLL, I believe the main .NET application which uses this DLL won't do multiple calls to the dll, rather it will keep it loaded in memory.
Thanks
FraggerFox!
-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
"What you think today is what you live tomorrow"Hi,
the DLL will stay in memory as long as there is a program running which has not closed (unloaded) the DLL.
Doing repetitive calls to the DLL is irrelevant in this context. LV opens the DLL as soon as needed and will only unload it when there is no VI in memory which has a CLN to that DLL...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome -
Call Library Function (DLL) Node Configuration
This issue was discussed few times on this forum (see for example http://forums.ni.com/ni/board/message?board.id=170&message.id=182911 ), but I still have a problem.
My question is - how to define the call to DLL without to specify its full path in order to be able to change the directory path without to change all calls to DLL functions within VI.
So, I did:
1. I put my DLL and my VI in the same directory.
2. I defined this directory in VI search path. This directory also defined as enviroment variable.
3. I use only one call to DLL in this specific VI (just as example in order to simplify the problem).
4. I define only DLL name without the path in CLF Node.
But, every time when I close CLF Node configution window, the program search for the DLL, find it and put full DLL path inside.
I will be very thankful if anyone can help me to overcome this problem.
Best regards,
BorisHello Boris,
To sum up the previous posts, when you specify the DLL when configuring the Call Library Function
node, internally LabVIEW stores in the VI either 1) the name of the
DLL, or 2) a relative path from the VI to the DLL (including the name
of the DLL). What's displayed in the dialog (in 'Library Name or Path'
field) is either 1) the name of the DLL, or 2) an absolute path that is
formed by appending the DLL's relative path to the VI's absolute path.
In
case 1, LabVIEW uses the Windows system search paths to load the DLL.
That is, it looks for the DLL in \windows\system32 folder, then if not
found there, it uses the folders specified in the PATH environment
variable, etc.
In case 2, LabVIEW tries to load the DLL from the
computed absolute path (VIs current path combined with the relative
path to the DLL that LabVIEW stored internally). And if not found
there, LabVIEW uses the VI Search Path (that can be set from Tools »
Options in the category of Paths).
So even though LabVIEW automatically puts an absolute path to the DLL
in the Call Library Function Node, as long as you will specify the
correct folder for the DLL in the VI Search Path, you should be Ok. However, if you want to
have a fixed location for the DLL, then it is best to keep it in the
\windows\system32 folder, and specify just the name of the DLL when
configuring the Load Library Function node (this way LabVIEW will not
automatically turn it into an absolute path).
Also, these knowledge base articles might be helpful:
Why Does My VI Prompt for My DLL Every Time I Open It?
LabVIEW Searching for a DLL Used in the Call Library Function Node
My Stand-Alone Executable Cannot Find My DLL, Even Though I Have Specified the Path for the DLL
Hope this helps and good luck with your application!
Shakhina P.
NIC -
Calling a library function node much faster than labview code?
Hi, I wrote a labview routine to perform a multiple tau autocorrelation on a large array of integers. A multi tau autocorrelation is a way to reduce the computation time of the correlation but at the expense of resolution. You can taylor the multitau correlation to give you good resolution where you need it. For instance, I require good resolution near the middle (the peak) of the correlation, so I do a linear autocorrelation for the first 64 channels from the peak, then I skip every second channel for the next 32, then skip every 4th channel for 32 more, then skip every 8th for 32 channels... etc.
Originally, I wrote my own multitau calculation, but it took several hours to perform for just 1024 channels of the correlation of around 2million points of data. I need to actually do the the correlation on probably 2 billion or more points of data, which would take days. So then I tried using labview's AutoCorrelation.vi which calls a library function. It could do a linear autocorrelation with 4 million points in less than a minute. I figured that writing my code in C and calling it using a call library function node would be faster, but that much faster?
Finally, I wrote some code that extracts the correlation data points that I would've got from my multitau code from the linear correlation function that I get from the AutoCorrelation.vi. Clearly this is not optimal, since I spend time calculating all those channels of the correlation function just to throw them away in the end, but I need to do this because the final step of my procedure is to fit the correlation function to a theoretical one. With say 2million points, the fit would take too long. The interesting thing here is that simply extracting the 1024 point from the linear autocorrelation function takes a significant amount of time. Is labview really that slow?
So, my questions are... if I rewrite my multitau autocorrelation function in C and call it using a call library function node, will it run that much faster? Can I achieve the same efficiency if I use a formula node structure? Why does it take so long just to extract 1024 points from an array?
I've tried hiding indicators and this speeds things up a little bit, but not very much.
I'll attach my code if you're interested in taking a look. There is a switch on the front panel called 'MultiTau'... if in the off position, the code performs the linear autocorrelation with the AutoCorrelation.vi, if in the on position, it performs a multitau autocorrelation using the code I wrote. Thanks for any help.
Attachments:
MultiTauAutocorrelate.vi 627 KBHi,
The C routine that AutoCorrelation.vi is using is probably a higly optimised routine. If you write a routine in LabVIEW, it should be less then 15% slower. But you'd have to know all ins and outs of LabVIEW. How data is handled, when memory is allocated, etc. Also note that the AutoCorrelation.vi has years of engineering behind it, and probably multiple programmers.
It might even be possible that the c code uses an algorithmic improvement, like the Fast Fourier Transform improves speed on the Fourier Transform. I think the autocorrelation can be done using FFT, but that isn't my thing, so I'm not sure.
For a fair comparation, posting the code in this forum was a good idea. I'm sure together we can get it to 115% or less of the C variant. (15/115 is just a guess, btw)
I'm still using LV7.1 for client compatibility, so I'll look at the code later.
Regards,
Wiebe.
"dakeddie" <[email protected]> wrote in message news:[email protected]...
Hi, I wrote a labview routine to perform a multiple tau autocorrelation on a large array of integers. A multi tau autocorrelation is a way to reduce the computation time of the correlation but at the expense of resolution. You can taylor the multitau correlation to give you good resolution where you need it. For instance, I require good resolution near the middle (the peak) of the correlation, so I do a linear autocorrelation for the first 64 channels from the peak, then I skip every second channel for the next 32, then skip every 4th channel for 32 more, then skip every 8th for 32 channels... etc. Originally, I wrote my own multitau calculation, but it took several hours to perform for just 1024 channels of the correlation of around 2million points of data. I need to actually do the the correlation on probably 2 billion or more points of data, which would take days. So then I tried using labview's AutoCorrelation.vi which calls a library function. It could do a linear autocorrelation with 4 million points in less than a minute. I figured that writing my code in C and calling it using a call library function node would be faster, but that much faster?Finally, I wrote some code that extracts the correlation data points that I would've got from my multitau code from the linear correlation function that I get from the AutoCorrelation.vi. Clearly this is not optimal, since I spend time calculating all those channels of the correlation function just to throw them away in the end, but I need to do this because the final step of my procedure is to fit the correlation function to a theoretical one. With say 2million points, the fit would take too long. The interesting thing here is that simply extracting the 1024 point from the linear autocorrelation function takes a significant amount of time. Is labview really that slow?So, my questions are... if I rewrite my multitau autocorrelation function in C and call it using a call library function node, will it run that much faster? Can I achieve the same efficiency if I use a formula node structure? Why does it take so long just to extract 1024 points from an array?I've tried hiding indicators and this speeds things up a little bit, but not very much.I'll attach my code if you're interested in taking a look. There is a switch on the front panel called 'MultiTau'... if in the off position, the code performs the linear autocorrelation with the AutoCorrelation.vi, if in the on position, it performs a multitau autocorrelation using the code I wrote. Thanks for any help.
MultiTauAutocorrelate.vi:
http://forums.ni.com/attachments/ni/170/185730/1/MultiTauAutocorrelate.vi -
Call library function node with array of clusters using array data pointer
Hello all.
I am writing a LabVIEW wrapper for an existing DLL function.
The function has, as one of its parameters, an array of structs. The struct is very simple, containing two integers. I am using the call library function node to access it.
In Labview I created an array of clusters, where the cluster has two 32-bit integers as its members. So far, so good.
Now I have to pass this in to the Call Library Function Node. Here I am running into trouble.
I have used The topic in LAVA and The topic in the knowledge base as my primary sources of information, though I have read a bunch of forum topics on the subject too.
I do understand that I could write a new function which takes as a parameter a struct with the size as the first member and an array as the second, and I might just do this and have it call the regular function, but I was hoping to do it more simply.
According to the C file which LabVIEW generates for me from the CLFN when I choose "Adapt to Type" and "Array Data Pointer", the prototype it is expecting is:
int32_t myFunc(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
And the prototype of the function in my DLL is
int borland_dll myFunc(DWORD handle, usint channel,
int FIFOnumber, struct mStruct *data, int numWords, int *actualLoaded, int *actualStartIndex);
This looks like a match to me, but it doesn't work (I get garbage in data). From the topic in LAVA referenced above, I understood that it would work. It does not.
If I cast data to the pointer-to-pointer I get when I generate c code by wiring my struct to a CIN and generating, then I seem to get what I expect. But this seems to work when I choose "pointers to handles" too, and I would expect array data pointer to give a different result.
Is there any way to get this to work directly, or will I have to create a wrapper? (I am currently using LabVIEW 2011, but we have customers using 2009 and 2012, if not other versions as well).
Thank you.
Batya
Solved!
Go to Solution.OK, here is more detailed information.
I have attached the VI.
This is the code from the "C" file created by right-clicking the CLN and creating a "C" file.
When the parameter in the CLN is set to "array data pointer":
/* Call Library source file */
#include "extcode.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, void data[], int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
When the parameter is "pointers to handles":
/* Call Library source file */
#include "extcode.h"
/* lv_prolog.h and lv_epilog.h set up the correct alignment for LabVIEW data. */
#include "lv_prolog.h"
/* Typedefs */
typedef struct {
int32_t control;
int32_t data;
} TD2;
typedef struct {
int32_t dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
When the parameter is set to "handles by value":
/* Call Library source file */
#include "extcode.h"
/* lv_prolog.h and lv_epilog.h set up the correct alignment for LabVIEW data. */
#include "lv_prolog.h"
/* Typedefs */
typedef struct {
int32_t control;
int32_t data;
} TD2;
typedef struct {
int32_t dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
#include "lv_epilog.h"
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex);
int32_t Load_Transmit_FIFO_RTx(uint32_t handle, uint16_t channel,
int32_t FIFOnumber, TD1Hdl *data, int32_t numWords, int32_t *actualLoaded,
int32_t *actualStartIndex)
/* Insert code here */
As to the DLL function, it is a bit more complicated than I explained above, in the current case. My VI calls the function by this name in one DLL, and that DLL loads a DLL and calls a function (with the same name) in the second DLL, which does the work. (Thanks Rolfk, for helping me with that one some time back!)
Here is the code in the first ("dispatcher") DLL:
int borland_dll Load_Transmit_FIFO_RTx(DWORD handle, usint channel, int FIFOnumber, struct FIFO_DATA_CONTROL *data, int numWords, int *actualLoaded, int *actualStartIndex)
t_DispatchTable *pDispatchTable = (t_DispatchTable *) handle;
int retStat = 0;
retStat = mCheckDispatchTable(pDispatchTable);
if (retStat < 0)
return retStat;
if (pDispatchTable->pLoad_Transmit_FIFO_RTx == NULL)
return edispatchercantfindfunction;
return pDispatchTable->pLoad_Transmit_FIFO_RTx(pDispatchTable->handlertx, channel, FIFOnumber, data, numWords, actualLoaded, actualStartIndex);
borland_dll is just "__declspec(dllexport)"
The current code in the DLL that does the work is:
// TEMP
typedef struct {
int control;
int data;
} TD2;
typedef struct {
int dimSize;
TD2 data[1];
} TD1;
typedef TD1 **TD1Hdl;
// END TEMP
int borland_dll Load_Transmit_FIFO_RTx(int handlertx, usint channel, int FIFOnumber, struct FIFO_DATA_CONTROL *data, int numWords, int *actualLoaded, int *actualStartIndex){
struct TRANSMIT_FIFO *ptxFIFO; //pointer to transmit FIFO structure
usint *pFIFOlist; //pointer to array of FIFO pointers to FIFO structures
int FIFOentry, numLoaded;
usint *lclData;
usint nextEntryToTransmit;
// TEMP
FILE *pFile;
int i;
TD1** ppTD = (TD1**) data;
TD1 *pTD = *ppTD;
pFile = fopen("LoadFIFOLog.txt", "w");
fprintf(pFile, "Starting Load FIFO with %d data words, data pointer 0x%x, with the following data: \n", numWords, data);
for (i = 0; i < numWords; i++) {
fprintf(pFile, "%d: control--0x%x, data--0x%x \n", i, data[i].control, data[i].data);
fflush(pFile);
fprintf(pFile, "OK, using CIN generated structures: dimSize %d, with the following data: \n", pTD->dimSize);
for (i = 0; i < numWords; i++) {
fprintf(pFile, "%d: control--0x%x, data--0x%x \n", i, pTD->data[i].control, pTD->data[i].data);
fflush(pFile);
// END TEMP
if ((handlertx) <0 || (handlertx >= NUMCARDS)) return ebadhandle;
if (cardrtx[handlertx].allocated != 1) return ebadhandle;
pFIFOlist = (usint *) (cardrtx[handlertx].segaddr + cardrtx[handlertx].glob->dpchn[channel].tr_stk_ptr);
pFIFOlist += FIFOnumber;
ptxFIFO = (struct TRANSMIT_FIFO *)(cardrtx[handlertx].segaddr + *pFIFOlist);
//use local copy of ptxFIFO->nextEntryToTransmit to simplify algorithm
nextEntryToTransmit = ptxFIFO->nextEntryToTransmit;
//on entering this routine nextEntryToLoad is set to the entry following the last entry loaded
//this is what we need to load now unless it's at the end of the FIFO in which case we need to wrap around
if ( ptxFIFO->nextEntryToLoad >= ptxFIFO->numEntries)
*actualStartIndex = 0;
else
*actualStartIndex = ptxFIFO->nextEntryToLoad;
//if nextEntryToLoad points to the last entry in the FIFO and nextEntryToTransmit points to the first, the FIFO is full
//also if nextEntryToLoad == nextEntryToTransmit the FIFO is full and we exit without loading anything
if (( (( ptxFIFO->nextEntryToLoad >= ptxFIFO->numEntries) && (nextEntryToTransmit == 0)) ||
( ptxFIFO->nextEntryToLoad == nextEntryToTransmit)) && (ptxFIFO->nextEntryToLoad != INITIAL_ENTRY)){
*actualLoaded = 0; //FIFO is full already, we can't add anything
return 0; //this is not a failure, we just have nothing to do, this is indicated in actualLoaded
numLoaded = 0;
lclData = (usint *)data; //must use 16 bit writes to the module
//conditions are dealt with inside the for loop rather than in the for statement itself
for (FIFOentry = *actualStartIndex; ; FIFOentry++) {
//if we reached the end of the FIFO
//if the module is about to transmit the first element of the FIFO, the FIFO is full and we're done
//OR if the module is about to transmit the element we're about to fill in, we're done - the
//exception is if this is the first element we're filling in which means the FIFO is empty
if ((( FIFOentry >= ptxFIFO->numEntries) && (nextEntryToTransmit == 0)) ||
((FIFOentry == nextEntryToTransmit) && (FIFOentry != *actualStartIndex) )){
*actualLoaded = numLoaded;
//set nextEntryToLoad to the end of the FIFO, we'll set it to the beginning next time
//this allows us to distinguish between full and empty: nextEntryToLoad == nextEntryToTransmit means empty
ptxFIFO->nextEntryToLoad = FIFOentry;
return 0;
//we reached the end but can continue loading from the top of the FIFO
if ( FIFOentry >= ptxFIFO->numEntries)
FIFOentry = 0;
//load the control word
ptxFIFO->FifoData[FIFOentry * 3] = *lclData++;
//skip the high of the control word, the module only has a 16 bit field for control
lclData++;
//now put in the data
ptxFIFO->FifoData[(FIFOentry * 3) + 2] = *lclData++;
ptxFIFO->FifoData[(FIFOentry * 3) + 1] = *lclData++;
numLoaded++;
//we're done because we loaded everything the user asked for
if (numLoaded >= numWords) {
*actualLoaded = numLoaded;
ptxFIFO->nextEntryToLoad = FIFOentry+1;
return 0;
//if we reached here, we're done because the FIFO is full
*actualLoaded = numLoaded;
ptxFIFO->nextEntryToLoad = FIFOentry;
fclose (pFile);
return 0;
As you can see, I added a temporary diagnostic with the structures that were created in the "Handles by value" case, and print out the data. I see what is expected, whichever of the options I pick in the CLN!
I understood (from the information in the two links I mentioned in my original post, and from the name of the option itself) that "array data pointer" should pass the array of data itself, without the dimSize field. But that does not seem to be what is happening.
Batya
Attachments:
ExcM4k Load Transmit FIFO.vi 15 KB -
How to implement a callback function using LabView's Call Library Function Node?
I am trying to call a fuction from a SDK.dll library using the Call Library Function Node. The SDK was provided to
me and I do not have the source code, just the .dll and .h files.
The SdkSetPropertyEventHandler function has a callback fuction as one of its parameters. How do I implement the
callback using the CLF node? I am a good LabView programmer but this is my first time using the Call Library
Function Node. I have read all the info I can find on NI's web site and the discussion board but cannot figure
this one out. I am using LabView 8.6.
The SDK.h deacribes the function as:
// Function: SdkSetPropertyEventHandler
SdkError SDKAPI SdkSetPropertyEventHandler(
SdkCameraRef inCameraRef,
SdkPropertyEvent inEvnet,
SdkPropertyEventHandler inPropertyEventHandler,
SdkVoid* inContext );
// Description:
// Registers a callback function for receiving status
// change notification events for property states on a camera.
// Parameters:
// In: inCameraRef - Designate the camera object.
// inEvent - Designate one or all events to be supplemented.
// inPropertyEventHandler - Designate the pointer to the callback
// function for receiving property-related camera events.
// inContext - Designate application information to be passed by
// means of the callback function. Any data needed for
// your application can be passed.
// Out: None
// Returns: Any of the sdk errors.
A separate header file called SDKTypes.h contains the following data:
typedef SdkUInt32 SdkPropertyEvent;
typedef SdkUInt32 SdkPropertyID;
typedef void SdkVoid;
typedef struct __SdkObject* SdkBaseRef;
typedef SdkBaseRef SdkCameraRef;
SdkPropertyEventHandler
typedef SdkError ( SDKCALLBACK *SdkPropertyEventHandler )(
SdkPropertyEvent inEvent,
SdkPropertyID inPropertyID,
SdkUInt32 inParam,
SdkVoid * inContext );
Thanks for your help.
Alejandro
Solved!
Go to Solution.alejandroandreatta wrote:
I am trying to call a fuction from a SDK.dll library using the Call Library Function Node. The SDK was provided to
me and I do not have the source code, just the .dll and .h files.
The SdkSetPropertyEventHandler function has a callback fuction as one of its parameters. How do I implement the
callback using the CLF node? I am a good LabView programmer but this is my first time using the Call Library
Function Node. I have read all the info I can find on NI's web site and the discussion board but cannot figure
this one out. I am using LabView 8.6.
Basically you do not do that. LabVIEW does not know pointers and certainly not function pointers. What you should do instead is writing a C DLL that implements the callback and also exports a function to be called by LabVIEW that translates between the callback and a LabVIEW user event. Look for PostLVUserEvent() here on the NI site to find examples how to do that.
Rolf Kalbermatter
Message Edited by rolfk on 02-11-2009 08:00 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions -
Strange problem of calling library function node in labview 2010 and 2011
one year ago,I develop a program to usb device data and it works well,in labview 8.6 or 2009(win xp).Recently, When I test
the program in labview 2010 and labview 2011(win xp).,the program always crash immediately.I check the program and find main
problem is in call library function node. In my program,I use labview 2009 library for the USBExpress driver for
Silicon Labs USB MCU's from:https://decibel.ni.com/content/docs/DOC-9522,for example, 2 functions SI_OPEN and SI_READ
can not work well.
the header definition of SI_OPEN and SI_READ is:
SI_STATUS WINAPI SI_Open(
DWORD dwDevice,
HANDLE* cyHandle
SI_STATUS WINAPI SI_Read(
HANDLE cyHandle,
LPVOID lpBuffer,
DWORD dwBytesToRead,
LPDWORD lpdwBytesReturned,
OVERLAPPED* o = NULL
the SI_STATUS is equivalent to int type.
orignally, for HANDLE * in SI_Open, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass pointer to value.
for HANDLE in SI_Read, the parameter type in call library function node is numeric, data format is unsigned 32 bit integer ,and pass value.The program works well in labview 8.6&2009,however,crash in labview 2010 &2011.
later,I debug the program, for HANDLE *, I choose parameter type in call library function node as adapt to type, data format is point to Handles.for HANDLE, I choose parameter type in call library function node as adapt to type, data format is Handles by Value.Crash not happend in labview 2010&2011,however,it cannot read any data from from USB device correctly as before.I can not find the reason.
Dear friends,I need your help to answer the problem. Thank you.Based on the help page it looks like it should execute asynchronously.
The thing in the description that leads me to believe they execute asynchronously is that you can configure the library to run as a multi-threaded operation.
Please take a look here to see the difference between synchronous and asynchronous execution.
Since the code even has the ability to be multi-threaded, you can consider it as running in parallel to your other code.
Any data returned is passed to the thread that called that function.
Cory K
Maybe you are looking for
-
I did the iTunes update yesterday and now I am getting this message when I try to open iTunes - "This copy of iTunes is corrupted or is not installed correctly. Please re-install iTunes. (-42037) Can anybody help me out resolving this?
-
How to activate an InfoObject in background in target system
Hello, after I made changes to an characteristic InfoObject in development system I have activated it in background, this has run the background job IOBJ_ACTIVATE. When I transported the IO change and activation into the test system, the IO has been
-
Adobe is cheating me...! N
-
Is there a way to delete my deleted messages? I'm hearing that for $30 anyone can pay to have your text message history retrieved from your phone records?
-
I have a droid phone and am trying to send email from there to eprint and won't work. Anyone know wh
Anyone out there know the answer, I have a droid and sent email from my phone to eprint and it won't work. Works from my home computer, any idea