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.

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!

  • When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time it is called?

    When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
    I have a time critical real time application, in which I use a piece of DLL function developed by C++.  It is OK?  Could any senior developer assure me?
    Thank you in advance.
    Solved!
    Go to Solution.

    qing_shan61 wrote:
    When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
    Once
    qing_shan61 wrote:
    I have a time critical real time application, in which I use a piece of DLL function developed by C++.  It is OK?
    OK
    Be sure that all DLL calls are thread safe (do not perform calls in UI thread).
    Also for real-time application you need real-time OS.
    Andrey.

  • Use call library function node

    I try to use call library function node to call a function in DLL and retrieve info stored in the C structure data type, can I do it? If yes, how ? Thanks.

    Have a look at the article Configuring the Call Library Function Node

  • LabVIEW PDA reports COREDLL.DLL error when using Call Library Function Node

    I'm trying to build a LV PDA app that calls an external DLL file built using embedded visual C. When configuring the Call Library Function node I select the stub DLL, configure the I/O parameters and select OK. When the configuration dialog closes I get the following error:
    LabVIEW: LabVIEW.exe - Unable to Locate Component
    This application has failed to start because COREDLL.DLL was not found. Re-installing the application may fix this problem.
    I do not get this error when using the configuration dialog in the example VIs.
    Any suggestions as to the cause and/or the solution?
    Thanks,
    Ryan

    Hello -
    When you create a PDA VI that calls a DLL, you must include the .c or .lib file that corresponds to the DLL. Take a look at these documents:
    LabVIEW PDA Module Build Errors with VIs that Call DLLs
    Why Do I Receive Errors When Calling a C++ DLL from a Call Library Node Using the LabVIEW PDA Module...
    How To Call External Code in LabVIEW PDA for Palm OS
    H
    ow To Call External Code in LabVIEW PDA for Pocket PC
    Hope this helps!
    S Vences
    Applications Engineer
    National Instruments

  • Using Call Library Function Node To Return C++ Structure Informatio​n

    Hi everyone.  This question is for all you LabVIEW gurus out there.
    I am trying to call a function from a .dll to get information from a structure about a device (FT232H chip).  I am using the "Call Library Function Node" to do this in LabVIEW.  My issue is I do not know how to set up the "Call LIbrary Function Node" parameter for a C++ structure.  How do I set up the pointer to FT_DEVICE_LIST_INFO_NODE structure using the "Call Library Function Node" so that I can read back the device information?
    The details of the C++ function and the structure are below.
    Thanks for everyone's help!
    The C++ function is the following:
    FT_STATUS I2C_GetChannelInfo (uint32 index, FT_DEVICE_LIST_INFO_NODE *chanInfo)
    In = index (Index of the channel)
    Out = *chanInfo (Pointer to FT_DEVICE_LIST_INFO_NODE structure)
    The pointer to the FT_DEVICE_LIST_INFO_NODE is defined as:
    typedef struct _FT_DEVICE_LIST_INFO_NODE {
    ULONG Flags;
    ULONG Type;
    ULONG ID;
    DWORD LocId;
    char SerialNumber[16];
    char Description[64];
    FT_HANDLE ftHandle;
    } FT_DEVICE_LIST_INFO_NODE;

    Dennis/Nathan,
    I tried to set up the "Call Library Function Node (CLFN)" correctly in order to read out Device Information from a FTDI Chip (FT232H) but when I run the VI LabVIEW crashes on me always.
    I have attached the code.  For the FT_DEVICE_LIST_INFO_NODE structure I passed into the "CLFN" a constant cluster of all the structure elements and then I set up the node to:
    Type: Adapt to Type
    Data format: Handles by Value
    I think LabVIEW crash may have something to do with the fact that the output of the dll function is using a pointer to a structure.  With the Handles by value Data format I am unable to set the Pointer to structure.
    Can you please take a quick look at the code to see if I am setting the CLFN up correctly?
    Thanks!
    Once again, here are the C++ Code Details:
    FT_STATUS I2C_GetChannelInfo (uint32 index, FT_DEVICE_LIST_INFO_NODE *chanInfo)
    In = index (Index of the channel)
    Out = *chanInfo (Pointer to FT_DEVICE_LIST_INFO_NODE structure)
    The pointer to the FT_DEVICE_LIST_INFO_NODE is defined as:
    typedef struct _FT_DEVICE_LIST_INFO_NODE {
    ULONG Flags;
    ULONG Type;
    ULONG ID;
    DWORD LocId;
    char SerialNumber[16];
    char Description[64];
    FT_HANDLE ftHandle;
    } FT_DEVICE_LIST_INFO_NODE;
    Attachments:
    FT_I2C_GetChannelInfo.vi ‏14 KB

  • Failed to run parallel path when using call library function node in LV2009

    I have a problem with two parallel paths not being run in parallel on LabView 2009.
    See the image below.
    This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.
    The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.
    This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.
    Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.
    Is there some limit on parallel threads that is different in 2009 than in other versions ?
    Or is there some other problem in 2009 that might cause this problem ?
    My labview version is 9.0f3 (32-bit).
    Regards,
    Rob

    I've just installed the DETT tool and checked what the different versions of LabView do.
    In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.
    In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.
    So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...
    When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.
    I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.
    To answer Ben's question: "What thread does a modal VI run in?":
    In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.
    In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.
    Thanks,
    Rob

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

    A 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

  • 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

  • Crash "DAbort 0x37C03D in MemoryMana​ger.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.

  • Problem configuring dll in call library function node

    Hi all,
    I need help on configuring an external dll into labview. I used import shared library wizard with dll’s header file and got almost all functions (tested, works OK.) except ones with pointer arguments. And I am trying to configure the rest myself. dll belongs to a laser unit to configure, read and save data etc. Definition for one of the functions in the dll is below.
    GetCurState(HANDLE hDev, SLOTSELECT SlotSelector, pPOS pposLaser,pPOS pposLsrRes,pPOS pposEncoder,PFLOAT pulBeamStren,PULONG
    pulSamples,PTRIGSTAT pTrigstat); 
    And from documentation
    typedef union {
        DOUBLE dPosition;
        LONGLONG llPosition;
        LONG lRawPos;
        } POS, *pPOS;
    typedef WORD TRIGSTAT, *PTRIGSTAT;
    typedef FLOAT *PFLOAT;
    typedef ULONG *PULONG;
    I acquire device handle hDev from other function in the dll (and also used them with function with no pointer arguments).
    I tried Adapt to Type or Numeric 8-byte double for function parameters and tried wiring numeric, numeric array  control and indicator for above parameters in trhe union with no success. Function returns no error but sometimes labview crash.
    I read about using union in labview and it was saying to use largest element in size in a union, so I guess the question is what do I wire to a pointer type argument/parameter.  For example do I connect a numeric control and indicator to both a pass by Value and pass by Pointer to Value?
    Thanks,

    Yes, for a union you'd use a datatype that corresponds to the largest element in the union. In you case you had a DOUBLE (64-bits), LONGLONG (64-bits), and LONG (32-bits). Thus, you'd use a 64-bit value, such as  DBL control. For the pointer you'd need to use the size of the pointer that the compiler was using. If your DLL is a 32-bit DLL then you'd use a 32-bit integer. If your DLL is a 64-bit DLL then you'd use a 64-bit integer. Note that just because your union has a LONGLONG, it does not necessarily mean you have a 64-bit DLL. For instance, LabVIEW has 64-bit integers, even in the 32-bit version.

  • Using variants in Call Library Function Node parameters

    Can I use Call Library Function Node to send variant data?
    Attached is a VI. Here's the C code:
    int MM_FUNC mmDaqDll_407DB
        ( IN char *pcUdlPath
        , IN char *pcTableName
        , IN void *pvData
        int nStat = 1;
        //System:bject *varData = ((System:bject *)vData);
        MessageBox(NULL, pcUdlPath, pcTableName, 0);
        return nStat;
    } // mmDaqDll_407DB()
    I get the void pointer. I was hoping for a solution that did not use void*.
    What is the best way to pass void data to a DLL?
    Attachments:
    DaqDllMon407DB.vi ‏18 KB

    Hi Mefitzpatrick,
    Here is a similar forum that addresses this issue:
    http://forums.ni.com/ni/board/message?board.id=170&message.id=48886&requireLogin=False
    They mention using the Adapt to Type property of the function node inputs, have you tried this?
    Let me know if this doesn't answer your question.
    Sappster

  • 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

  • Call Library Function Node not Supported

    Hai,
    I have question to ask to NI members. I get an error said " Call Library Function Node 'LVASPT_WA.*ptDecimationFilterH':Node not supported". I use the call library function node in the FPGA.VI in my design. My question is, is it the function cannot used in FPGA.VI? I try to search a similar thread and find the manual but still can't find the answer. Anyone please clarify it to me. Thanks in advance.

    You cannot use Call Library Function Node in FPGA. The FPGA is hardware - it has no way to call an external library. If it is not immediately obvious why it's impossible for the FPGA to call a DLL, you should spend some time understanding what a FPGA is.
    You can integrate FPGA code written outside the LabVIEW environment, but that's not the same as calling a DLL.

  • Call Library Function Node produces error in Windows 7

    Hi,
          I've created a simple program using LabVIEW 8.5 that uses calls in winscard.dll to read and write to a Smart Card.  I use Call Library Function Node to call functions in C:\Windows\System32\winscard.dll.  This program works without a problem in Windows XP both within LabVIEW 8.5 and once it is compiled.  I am also able to get this program to run without a problem when I run it in LabVIEW 2011 on a Windows 7 machine.  However, when I run the program compiled with LabVIEW 8.5 on Windows 7, the first call I make to a function in the DLL returns Windows System Error 2 (file not found).  Subsequent calls to other DLL functions return errors about invalid handles, which makes sense. 
    Can I compile the project in LabVIEW 2011 and save it back to a LabVIEW 8.5 compatible project file?
    Thanks,
    Jason Mazzotta

    Bannu wrote:
    Hi All,
    I am also having the similar issue. I have a VI, developed in LV2010 on Windows XP machine with a dll call using "Call Library Function Node".
    It is working fine in all WindowsXP machines but not in Window7 PCs.
    Getting Error when i tried to open in Windows7 machine:
    Error loading "DLL path....". Invalid access to memory location.
    Please let me know how to make this working on both machines [XP and Win7].
    Thanks,
    Soumya
    Way to little information to say anything useful about it. Attach your VI, explain what it should do, explain what the DLL is you try to call! You don't call your mechanicien saying your car doesn't start and expect him to diagnose the problem over the phone either with that much information.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

Maybe you are looking for