Calling legacy C library functions.

How do you call legacy C functions with JNI. This is code that I have access to the libraries and header files but not to the source code. I have written, run and understand how to write native C code for the JNI but have yet to find information on how to call an existing function. I JUST DON'T GET IT! I hope I am not overlooking the obvious and apologize if this is the case. A simple example would be most helpful and apreciated.
Thanks much,
Darrin

Below I am using the simple example from sun and altering it to call legacy code to print to the screen "HelloWorld".
// HelloWorld.c
class HelloWorld {
public native void displayHelloWorld();
static {
System.loadLibrary("hello");
public static void main(String[] args) {
new HelloWorld().displayHelloWorld();
//HelloWorld.h
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class HelloWorld */
#ifndef IncludedHelloWorld
#define IncludedHelloWorld
#ifdef __cplusplus
extern "C" {
#endif
* Class: HelloWorld
* Method: displayHelloWorld
* Signature: ()V
JNIEXPORT void JNICALL Java_HelloWorld_displayHelloWorld
(JNIEnv *, jobject);
#ifdef __cplusplus
#endif
#endif
//HelloWorldImp.c
//Altered to call legacy code that prints "HelloWorld"
#include <jni.h>
#include "HelloWorld.h"
#include <stdio.h>
#include "LegacyC.h"
JNIEXPORT void JNICALL
Java_HelloWorld_displayHelloWorld(JNIEnv *env, jobject obj)
PrintHello( );
return;
//LegacyC.h
//The legacy C code header file
void PrintHello( );
//LegacyCode.c
//The legacy C source code
# include <stdio.h>
void PrintHello( )
printf("HelloWorld\n");
I have tried this and it does not work.
This is just to illustrate what I am trying to do, in reality I do not have the source to the legacy only the library.
Very frustrating.
Could you alter and repost this code to make it work.
Thank you,
Darrin

Similar Messages

  • Calling C wrappered library functions

    Hello,
    I have a C wrappered library where a start task is made on a SO method
    which in turn calls a function in the C library. The process will remain
    in the C function until completed reading a file which can take several
    minutes to hours. During this process, the C function is also updating a
    status structure of various information. Immediately after the start task,
    another start task is called on a SO method to enter an event loop. Every
    10 seconds or so, a call is to be made on another C function from the same
    library to obtain the status results being updated from the first task.
    However, once I attempt at retrieving this status information, the entire
    process comes to a screeching halt. This process is being run on an Alpha
    Server under Unix environment. I have set the library as multithreaded, but
    still can not access the status information nor prevent the first task from
    stopping dead in its tracks. Has anyone else had a similar experience and
    how did you correct this.
    Thanks in advance.
    Wayne

    Hello,
    I have the same problematic than you : call an archive file in c from java.
    But my problem is that I'm new in c.
    Do you have some example to write the wrapper of the .a archive.
    Thks,
    Twentyseven.

  • Sloaris 10 C Library function _rename

    When ever our application calls rename C library function the stack trace disappears and the corresponding thread doest not get any time slice and the thread hangs. This happens every 10 to 15 min once.
    Stack trace when we call rename
    ----------------- lwp# 2 / thread# 2 --------------------
    fedc0a20 _rename  (59cc0, fe9fbd04, 0, fea664d3, fea76c08, 59cd8) + 8
    fea624ac __1cKBCPEncoderGencode6MpnNFormattedData__v_ (59cc0, d0084, fe9fbf28, fea8c1e6, fea76c08, fffef7d2) + dc
    0001dfcc __1cNEncoderThreadDrun6M_v_ (59f50, 1, d0084, fea77134, fe9fbf20, fe9fbf24) + ec
    ff33c680 __1cGThreadKThreadMain6Fpv_1_ (59f50, fe9fc000, 0, 0, 1dee0, 37944) + c
    fedc04ec lwpstart (0, 0, 0, 0, 0, 0)
    Stack trace after calling rename
    ----------------- lwp# 2 --------------------------------
    00000000 ???????? (0, 0, 0, 0, 0, 0)
    We are using the below configuration in the machine.
    SunOS 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire

    When ever our application calls rename C library function the stack trace disappears and the corresponding thread doest not get any time slice and the thread hangs. This happens every 10 to 15 min once.
    Stack trace when we call rename
    ----------------- lwp# 2 / thread# 2 --------------------
    fedc0a20 _rename  (59cc0, fe9fbd04, 0, fea664d3, fea76c08, 59cd8) + 8
    fea624ac __1cKBCPEncoderGencode6MpnNFormattedData__v_ (59cc0, d0084, fe9fbf28, fea8c1e6, fea76c08, fffef7d2) + dc
    0001dfcc __1cNEncoderThreadDrun6M_v_ (59f50, 1, d0084, fea77134, fe9fbf20, fe9fbf24) + ec
    ff33c680 __1cGThreadKThreadMain6Fpv_1_ (59f50, fe9fc000, 0, 0, 1dee0, 37944) + c
    fedc04ec lwpstart (0, 0, 0, 0, 0, 0)
    Stack trace after calling rename
    ----------------- lwp# 2 --------------------------------
    00000000 ???????? (0, 0, 0, 0, 0, 0)
    We are using the below configuration in the machine.
    SunOS 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire

  • 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 advance

    Did 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.

  • Passing arrays with Call Library Function does not work after application builder

    Calling a DLL with Call Library Function which requires an array of data works correctly in Labview, but after building an exe with application builder, the call no longer works.  Dereferecing the pointer in the DLL retuns all 0s and not the actual values.
    Solved!
    Go to Solution.
    Attachments:
    TEST.zip ‏28 KB

    I did not run your code because it is a little unclear to me what it does.
    Two things:
    First, is the DLL you are calling the DLL-ified version of PopUpNames.vi? Then the problem is likely that the panel is not being built into the DLL.
    When LabView builds an application / dll, it strips the front panel and block diagram from all VIs that it doesn't think need to show a panel at run time. This reduces file size and increases code security. The App Builder's panel inclusion logic can be overridden by Build Specifications -> Source File Settings -> Remove front panel. A better method is to put a property node on a control in a window you want to show marking it "visible"; this is sufficient to tell the App Builder it should keep the panel.
    Currently Source File Settings shows "no dependencies" (clearly incorrect---another evil side effect of Express VIs I guess) but if you change the settings as shown below to keep ALL panels, one might hope the App Builder can figure it to keep the panel when it deconstructs the Express VI. (Alternatively convert the Express VI into a regular one.)
    A second comment: I am a bit flummoxed at the larger goal here. You are calling LabView DLL from LabView, which doesn't make a lot of sense, so I assume your larger goal is to call LabView from C or vice-versa. In that case be aware that your DLL is x86 (32-bit) but you are passing 64-bit ints as your pointers. In this case it is 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers calling 32-bit LabView with 32-bit pointers in embedeed in 64-bit containers, so it all works, but if your going to call this from C or whatnot you're going to have to follow that same design.
    When calling C code the LabView Call Library Function does have a "unsigned pointer-sized integer" data type that always appears to be 64 bits in the dev env but which actually passes a 64 or 32-bit int to the DLL depending on the environment. The "pointer sized int" has to be 64 bits in the "LabView" part of the code because LabView's strong typing requires the data type to be determined at compile time. Casting all pointers to the largest data type in LabView makes it possible to write platform-independent code, but down at the Call Library level you still have to put the right number of bytes on the stack.

  • 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
    DAve

    Hi 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/81E9C144190​0FFCE8625748F0055DBB0?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 can I debug the Call Library Function at run-time

    I've written a VI using the CLF to call a DLL which was compiled off-site by another engineer using MSVC. Even though the VI runs without flagging any errors, the VI is not doing what I expect. Is there any way of finding out if the DLL is been called correctly? The first function that is called doesn't return any value, but I think that it should. Does this mean that the DLL is not being called correctly? Note also that the DLL works fine with a JAVA GUI.

    Make sure that you are specifying the proper function prototype in the call library function. If you are slightly off the call will not work properly. Ask the offsite engineer to provide you with this data. Another tip is to build the dll with the option to show front panel when called. You can actually popup the dll like you would a subvi. If you design it with test indicators showing on the front panel that is a great way to determine if it is working. Hope this helps.
    BJD1613
    Lead Test Tools Development Engineer
    Philips Respironics
    Certified LV Architect / Instructor

  • 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

  • Problem in call library function

    Hi,
    I encountered some problems when using call library function node.
    After i select the path in configuration of call library function node, an error message is shown as 1st attachment.
    After i tick and the specified path on diagram, link the path name to the node, and run the program. Another error message is shown as 2nd attachment.
    Is my dll file got problem? Or i have done a wrong setting?
    Here i have attached my dll file.
    The dll file is built by Microsoft Visual Studio 2008.
    Please kindly advise.
    Thank you.
    Attachments:
    picture1.JPG ‏14 KB
    picture2.JPG ‏17 KB
    CodeUtil.zip ‏152 KB

    TanTan wrote:
    Hi,
    Is my dll file got problem? Or i have done a wrong setting?
    It seems to be compiled for WinCE. Assumed that you have Win2000/XP/Vista/7. Check your MSVC build settings.
    Andrey.

  • Problem with Call Library Function. Want to pass a string and return a string, but my compiler does not recognize "CStr" and Labview does not recognize my "char *function()" callout

    Hi, I'm trying to use a .DLL I wrote in Visual C++ .NET. The Call Library Function generates a function prototype of "CStr Parser(CStr arg_raw)"
    but my compiler won't accept this. So I change it to how C normally deals with strings "char *Parser(char *arg_raw). Now the Call Librafy Function does not find "Parser" in my .DLL though it is definitely there!
    Help!
    -Fong

    Hello
    You will need to include extcode.h in your C file. You can find this under ..\LabVIEW\cintools folder.
    The include has all the defines you will need.
    Bilal Durrani
    NI
    Bilal Durrani
    NI

  • 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

  • PDA: Calling library functions - seems to link the stubbed .cpp file instead of the DLL

    I'm having trouble developing a Lab View PDA module that calls a DLL built using Visual C++. The DLL functions correctly when called in a non-PDA VI. My issues seem to be with porting to the PDA.
    My configuration:
    - Lab View 8.5 with the PDA 8.5 module
    - Visual Studio 8.0 with the Windows Mobile 6.0 SDK
    - ASUS 626 PDA with an Intel PXA70 procesor running Windows Mobile 6 Classic
    Following the PPCBatt example code provided with the PDA module, I have:
    - used extern "C" to prevent name mangling
    - placed the DLL built with the Windows Mobile SDK in the \Windows directory on the PDA
    - created a stub Win32 DLL and lib
    - created a stubbed cpp file whose functions only return zero
    - included the stubbed cpp and lib files in the build spec / source files / additional files
    - placed Call Library Function nodes on my PDA VI, selected the function names, set the parameter types
    - built and deployed the executable, both with and without debug
    When I set the library path property of the Call Library Node, the functions appeared in the function name pulldown, but the parameters did not populate. I had to manually add them and set their types. The help page says they would autopopulate when the function was selected.
    I've debugged the VI, and the Library Function Call nodes are being called. It seems the build is linking the code from the stub C file provided in the additional files portion of the source files property page, instead of adding hooks to call the DLL on the PDA. As a test, I changed an output parameter in one of the functions in the stubbed cpp file - the changed value showed in the front panel indicator.
    What am I doing wrong?
    Dan

    Hi Dan,
    I'm not sure if I understood you problem fully. When calling external code with LabVIEW PDA, the DLL acts as a stub DLL with the correct function prototypes for the C code that you want to call. Here's a Knowledge Base article that might help explain about calling External Code in LabVIEW PDA.
    Regards,
    Stanley Hu
    National Instruments
    Applications Engineering
    http://www.ni.com/support

  • 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,
    Boris

    Hello 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 KB

    Hi,
    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,&nbsp; I wrote a labview routine to perform a multiple tau autocorrelation on a large array of integers.&nbsp; A multi tau autocorrelation is a way to reduce the computation time of the correlation but at the expense of resolution.&nbsp; You can taylor the multitau correlation to give you good resolution where you need it.&nbsp; 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.&nbsp; I need to actually do the the correlation on probably 2 billion or more points of data, which would take days.&nbsp; So then I tried using labview's AutoCorrelation.vi which calls a library function.&nbsp; It could do a linear autocorrelation with 4 million points in less than a minute.&nbsp; 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.&nbsp; 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.&nbsp; With say 2million points, the fit would take too long.&nbsp; The interesting thing here is that simply extracting the 1024 point from the linear autocorrelation function takes a significant amount of time.&nbsp; Is labview really that slow?So, my questions are...&nbsp; if I rewrite my multitau autocorrelation function in C and call it using a call library function node, will it run that much faster?&nbsp; Can I achieve the same efficiency if I use a formula node structure?&nbsp; 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.&nbsp; 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.&nbsp; Thanks for any help.
    MultiTauAutocorrelate.vi:
    http://forums.ni.com/attachments/ni/170/185730/1/M​ultiTauAutocorrelate.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(pDispatchT​able->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&colon; \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&colon; \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

Maybe you are looking for

  • Replication of BP and Sales order from CRM to R/3

    Hello everyone, I have a peculiar condition in my hands.The requirement is to replicate 10 business partners from crm to R/3 ,then the next 4 Business partners need not be replicated and then the next three replicated..How do we do this kind of repli

  • TS3297 keep getting error code 5002 when attempt to purchase music

    code 5002 when attempting to buy music

  • 10.4.6 Bugs

    Hey, I have an ibook G3 and I was wondering if anybody else who uses this system has had trouble with the latest sys. update. I haven't updated yet, I am just wondering if I should anticipate a certain issue. Also, I have a ipod mini, has anybody had

  • Windows 7 freezes on files copy operation on Macbook Pro 15" 2013 Late

    Hi, I use Windows installed via BootCamp on my Macbook Pro 15" 2013 Late with 512GB SSD. I installed all Apple drivers, but my laptop freezes(all windows stop responding) on a copy a lot of small files from one folder to another. After 2-5 min window

  • Facebook and iPhoto problems

    Hello and have a new year full of joy and happiness!!!!! I have problems using iPhoto from facebbok. When i am in facebook and especially in my page and i try to upload a photo, Finder opens and i choose iPhoto library. After that i click "open" and.