VI analyzer: Wire under object test fails with Call Library Function Nodes

Hi,
If I wire a Call Library Function Node with an ErrorIn and an ErrorOut, the VI Analyzer Test "Wire under Object" fails always with two occurrences per Call Library Function Node.
A double click to the occurrence highlights the error lines connected with the call... node.
The test does not fail, if the error lines are not connected.
Thanks!
H
Solved!
Go to Solution.

This became a problem when Call Library Nodes got error terminals (and optional path terminals) in LabVIEW 8.20. I should be able to get a fix in to VI Analyzer Toolkit 2010.
Thanks for taking the time to report the bug.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Similar Messages

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

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

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

How to use structure pointer with Â« Call Library Function node Â» in LabVIEW

I use GetTimeZoneInformation from kernel32.dll. It definition is :
DWORD GetTimeZoneInformation( LPTIME_ZONE_INFORMATION lpTimeZoneInformation );
Where
lpTimeZoneInformation
[out] Pointer to a TIME_ZONE_INFORMATION structure to receive the current time-zone parameters.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettimezoneinformation...
I don't know how to set this parameter with my cluster based on the TIME_ZONE_INFORMATION structure.
Your help will be appreciate
Thanks
INKSPEC

INKSPEC wrote:
I use GetTimeZoneInformation from kernel32.dll. It definition is :
DWORD GetTimeZoneInformation( LPTIME_ZONE_INFORMATION lpTimeZoneInformation );
Where
lpTimeZoneInformation
[out] Pointer to a TIME_ZONE_INFORMATION structure to receive the current time-zone parameters.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettimezoneinformation...
I don't know how to set this parameter with my cluster based on the TIME_ZONE_INFORMATION structure.
Your help will be appreciate
Thanks
INKSPEC
If creating a wrapper DLL which does the conversion for you is not an option (I think it won't since that would require C programming and if you knew C programming you wouldn't ask this here) then you will have to create a byte array of appropriate length and just configure the Call Library Node to pass this array as an Array of unsigned bytes and as C pointer.
On return you will have to copy out the interesting data at the right position.
First the length of this structure would be:
typedef struct _TIME_ZONE_INFORMATION {
LONG Bias; 4
WCHAR StandardName[32]; 32 * 2
SYSTEMTIME StandardDate; 8 * 2
LONG StandardBias; 4
WCHAR DaylightName[32]; 32 * 2
SYSTEMTIME DaylightDate; 8 * 2
LONG DaylightBias; 4
} TIME_ZONE_INFORMATION
Total 172 bytes
Now the fun part will be to actually get out the information. There are a number of difficulties.
First the strings are 16 bit Unicode so if you are interested in them you will have to call a different Windows API function WideCharToMultiByte function to convert the 16bit Unicode string into an ASCII string. For this part there has been a post here:
http://forums.ni.com/ni/board/message?board.id=170&message.id=123821&requireLogin=False
For the LONG values you would pick 4 bytes at the appropriate offset from the array through the Array Subset function and then typecast it into an int32 and pass that through the Swap Bytes and Swap Words functions to reverse the LabVIEW Big Endian byte swapping in the Typecast function.
The SYSTEMTIME is a structure with eight 2 byte integers so it would be best to use Array Subset again to extract 16 bytes at the correct offset, typecast this into a cluster with eight int16 numerics and pass it through Swap Bytes too.
You see accessing such API functions in LabVIEW directly can get easily quite a mess and that is the reason why creating a wrapper DLL to convert properly between LabVIEW datatypes and C datatypes gets soon the easier solution if you need to interface with more than one or two functions taking such complicated data structures.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Call Library Function Node: library not found or failed to load

Hello,
I had a VI that could not find some of the dll functions it needed. It works on one machine and not on another. So foolishly I copied the dll in question from the working machine and pasted it over the one on the non-working machine.
Now all my math functions are broken on the machine I copied the dll too. The error is "Call Library Function Node: library not found or failed to load"
And if I try to relink in the VI I get "Error loading C:\National Instruments\LabVIEW 8.2\resource\lvanlys.dll" A dynamic link library (DLL) initialization routine failed."
I tried a repair labview and that did not help.
I tried uninstall and reinstall labview and that did not help!
Please help me fix this!
Version 8.2
dll: C:\National Instruments\LabVIEW 8.2\resource\lvanlys.dll
Jim

What library did you first copy?
Also lvanlys.dll depends on the Intel Math Kernel Library that gets installed in a different location "C:\Program Files\National Instruments\Shared\MKL".
This Intel Math Kernel Library again depends on the Visual C runtime libraries. Most likely you replaced one of those runtime libraries somehow and now the Math Kernel Library (MKL) fails to initialize which causes thelvanlys.dll to fail its load.
Without a good view on your system and what other NI software you have installed it is very hard to recommend a good way of proceeding. There are various versions of the MKL used by various versions of NI products and just deleting the entire MKL folder might get you into trouble with other NI tools.
Deinstalling everything from NI, deleting the entire National Instruments folder and then reinstalling what you need would be the most safe proceeding.
And next time don't just copy some Visual C runtime libraries between machines. Their dependencies are complicated at the least and simply not graspable by us mere mortals. Use the according C runtime installer for the version you need as that installer will take care of installing the right versions of C runtime components and registering everything proberly so you do not usually run into problems with other applications using different versions of the C runtime.
Message Edited by rolfk on 03-01-2010 10:26 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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.

DIO Port Config & DIO Port Write Block Diagram Errors (Call Library Function Node:library not found or failed to load)

Hi Guys, need help on this.
I have this LabVIEW program that used to work on the old computer.
The old computer crashes most of the time, so I upgraded the computer
and used its Hard Drive as slave to the new computer.
I have no idea where are its installers since the guy that made the program
is not in my department anymore.
I downloaded all the drivers needed from NI: NIDAQ9.0, NIVISA,NI488.2,
and drivers of some instruments needed in the setup. I'm using LabVIEW8.2.
Everything's fine until I open the LabVIEW program for our testing.
Here goes the error:
   DIO Port Config
   DIO Port Write
Block Diagram Errors
   Call Library Function Node: library not found or failed to load
Attachments:
ErrorList.JPG ‏200 KB

Honestly, I'm a newbie on Labview. I just want this old program to run on the new computer.
The guys that installed the drivers on the old computer are no longer here in my department.
And I have no idea where the drivers are. So I just downloaded the drivers needed for my hardware and instruments.
Here's my hardware: (cards: PCI-DIO-96, PCI-GPIB), (instruments: SCB100,E4407B, HP83623, HP3458, HP8657)
OS: Windows XP Pro
By the way, I have unzipped the TraditionalDAQ drivers. First I tried the 7.4.1, but installation error appeared.
I thought maybe the installer is corrupted, so I downloaded the 7.4.4 and unzipped it.
But, still same installation error appears. I don't understand, both TraditionalDAQ drivers have same installation error.
Now I have tried the DAQmx8.7.2 driver, bu still the DIO Port Config and DIO Port Write have errors.

Call Library Function Node 'Wrapper.Create': Library not found or failed to load. using windows 7 64 bits

Dear all
I try to interface my spectrometer (NIRquest from ocean optics) using labview on my 64 bits cumputer using windows 7.
I have absolutely no problem to run the spectrometer with the program dedicated to the spectrometer (called Spetrasuite).
I've installed "OmniDriverSPAM-1.66-win64-development-installer.exe" and everything went right.
When I select a VI in LabView (e.g."wrapper_create.vi") from the wrapper.llb, LabView returns an error :
"Call Library Function Node 'Wrapper.Create': Library not found or failed to load."
I chek the call library function, but everyting seems to be right :
I use LabView 8.6.1 and my others *.vi are running perfectly...
Do you have any idea from where does the problem comes ?
Thank you very much

Hello Flanguy,
In addition to smercurio_fc's feedback I can confirm that LabVIEW 8.6.1 doesn't exist in 64-bit version.
Officially, LabVIEW 8.6.1 doesn't support Windows 7 either.
The minimal version of LabVIEW you would need to both support Windows 7 and exist in 64-bit version is LabVIEW 2009 64-bit or any 64-bit versions which are more recent.
In the two links (1 & 2) you can find more background information.
Kind Regards,
Wouter
National Instruments Belgium

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&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

Using an external DLL with "Call Library Function"

Hi!
I am trying to use an external DLL which is used from Visualbasic & Delphi:
http://www.keb.de/common/tools/KEBCOMDriver.zip
the protKEB.dll accesses the serial port to control an KEB frequency
inverter.
Unfortunatly there is no prototype header file for the DLL (no help on that
from KEB).
I only have a VisualBasic example program which works with the DLL.
(Unfortunatly I am no Visual basic expert)
To initialize the com port I have to use the function: setprotproperties &
getprotproperties
they are declared as:
'Setting the protocol properties
'ctrl is a pointer to a data structure of type tProtProperty
Declare Sub setprotproperties Lib "protkeb.DLL" (ctrl As Any)
'Reading the protocol properties
'ctrl is a pointer to a data structure of type tProtProperty
'the desired protocol is entered in ctrl.prottype before calling
Declare Sub getprotproperties Lib "protkeb.DLL" (ctrl As Any)
and tProtProperty is:
Public Type tProtProperty
ProtType As Long 'Type of Protocol (tProt)
TimeOut As Long 'ALL protocols
Baudrate As Long 'ANSI, HSP5
Comport As Long 'ANSI, HSP5
Flag As Long 'ANSI, HSP5: 01 = Sendslow
/ IP: 01 = UDP
Port As Long 'IPort number
Txtlen As Byte 'IP : length of following
text or 0
txt As String * 100 'IP : IP-Address or name
(maximum length)
End Type
I already tried to use a cluster with tProtProperty entries as an Input for
the function
setprotproperty in a call library function with:
Parameter Type : Adapt to type
Data Format: Pointer to Handle
but I always get an "exception within external code....."
What am I doing wrong?
How does a cluster & a "call library function node" look like that works?
Any help is really appreciated!
thanks
tom
,-Thomas Kerberger Physikalisch-Technische Bundesanstalt-.
| Abbestr.2-12 D-10587 Berlin fon: +49-30-3481338 |
| mailto:[email protected] fax: +49-30-3481386 |
`--------Labor 7.33 Messung thermischer Energie---------'

Thomas,
LabVIEW cannot call a DLL that has structures directly, you will need to create either a wrapper DLL or CIN that will take in all of the data individually construct the structure, and send it to the DLL function.
For more information on what a cluster looks like in native code, I would suggest creating a simple cluster, creating a Call Library Function Node on the block diagram with a cluster input. Then right-click on the Call Library Function Node and choose "Create .c file". This will generate the data structure for the cluster and give you a better feel for it. I would then suggest going to the Using External Code in LabVIEW manual that can be found in the LabVIEW Bookshelf (Start»Programs»National Instruments»LabVIEW 6»LabVIEW Manuals or »LabV
IEW 6.1»Search the LaBVIEW Bookshelf).
There is also the following: Developer Zone: Passing a Variety of Data Types from DLL to LabVIEW.
Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

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

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 multiple functions from same dll with call library function

hi,
i am working on a project in wich we need to make a UI to read out a sensor network.
the UI should be usable in any project, but every node needs a different piece of code depending on the type of sensor with wich it is equipt.
so i need to be able to call different pieces of code when i need them, and still be able to use the UI in future projects with possibly new types of node we now don't have.
so someone told me to use DLL's, cause then i would be able to call the code i need the moment i need it.
but i have never worked with DLL's (just learned about this option 3 day's ago) so i have a question.
i know i can dynamicly change the DLL i call with the call library function, but can i dynamicly change the function i call from that DLL ?
or do i have to put a new call library function for each function i want to call, even if its from the same DLL ?
kind regards,
stijn

nazarim wrote:
ok so there is no (easy and ubderstandable) way for me to dynamicly change wich function i want to call from a certain DLL.
but now i started wondering, the path on the call library function is not ment to dynamicly change a DLL
but it does work so, if i am carefull, can i use it for that purpose or will labview give me a series of problems once i start using it in larger programs ?
Thepath on the Call Library Node can be used to load a different DLL. Obviously since you can't change the function name your other DLL would have to export exactly the same function name and of course with the same parameters. This is seldom the case so it is not the main use of the path input to the Call Library Node. It's main use is as indicated to load DLLs at runtime rather than at load time of a VI. So that an application can run even when the DLL is missing, until the moment the functionality from that DLL is needed.
If you can make sure that all your DLLs export the same function name with the same parameter you can use the Call Library Node to call into different DLLs through the path input. If however you would need to call different function names you would have to resolve to some DLL which does do the dispatching and invocation using LoadLibrary() and GetProcAddress(). But unless you need to go with DLLs for some reason using the Call By Reference Node can give you an even more flexible approach.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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

Probel with call library function: I have a dll based on a complicated struct data type. How can I pass this structure?

The data type is
typedef enum {false, true} bool;
typedef float flt4;
typedef double flt8;
typedef int i32s;
typedef unsigned int i32u;
typedef short int i16s;
typedef unsigned short i16u;
typedef signed char i08s;
typedef unsigned char i08u;
struct t_UnwrapData {
struct {
i08u flags;
i16u unwrap_m;
i08u weight_m;
} status;
flt4 *ph2pi;
flt4 *weight;
flt4 *gamma;
flt4 *phase;
i08u *flags;
i08u *neigh;
i32s neighOfst[8];
i32s r,c;
i32s x0,y0,xSz,ySz;
flt8 unwTime;
flt4 binCut;
Please Could someone help me suggesting how I pass this dat
a type to call library function?

Hi Setu,
Here is a solution that I have been playing to return back an array of clusters
typedef struct
int32 dimSize;
uInt8 array[1];
} LVU8;
typedef LVU8 **LVU8Hdl;
typedef struct
U32 DeviceId;
U32 VendorId;
U32 BusNumber;
U32 SlotNumber;
LVU8Hdl SerialNumber;
} LVDEVICE_LOCATION;
typedef LVDEVICE_LOCATION **LVDEV_LOC_HANDLE;
typedef struct
int32 dimSize;
LVDEVICE_LOCATION cluster_array[1];
} LVDEV_LOC_ARRAY;
typedef LVDEV_LOC_ARRAY **LVDEV_LOC_ARRAY_HANDLE;
LVPLX_API void GetAllDevices(LVDEV_LOC_ARRAY_HANDLE cluster_array)
int i,j;
int numDevices = 3;
DSSetHandleSize(cluster_array, sizeof(int32)+3*(sizeof(LVDEV_LOC_ARRAY)+(sizeof(int32)+16*sizeof(L
VU8))));
(*cluster_array)->dimSize = 3;
(*((*cluster_array)->cluster_array[0]).SerialNumber)->dimSize =16;
(*((*cluster_array)->cluster_array[1]).SerialNumber)->dimSize =16;
(*((*cluster_array)->cluster_array[2]).SerialNumber)->dimSize =16;
for(i=0; i<3; i++)
((*cluster_array)->cluster_array[i]).BusNumber = i;
((*cluster_array)->cluster_array[i]).VendorId = i*5;
for(j=0;j<16;j++)
(*((*cluster_array)->cluster_array[i]).SerialNumber)->array[j] = (10*j)+i;
The code doesnt do much but returns back 3*cluster which the array in my cluster is sized for 16. The problem I've been having , was ensuring I have allocated enough memory to handle the complete structure. This works for me, now all I have to do is put the real code in which get my array of data from the instruments.
Hope it helps
Regards
Ray Farmer
Regards
Ray Farmer

Can i use DLL file created by Fortran with the call libary function node

Can i use a DLL created by Fortran (Compaq Visual Fortran) with the call library function node in labview. If yes how do i create the DLL file if i have the Fortran code.
Thanks

Yes! Maybe these old post will help:
http://forums.ni.com/ni/board/message?board.id=170&message.id=88786
http://forums.ni.com/ni/board/message?board.id=170&message.id=109150
Good luck!
Message Edited by altenbach on 03-21-2006 02:35 PM
LabVIEW Champion . Do more with less code and in less time .

VI analyzer: Wire under object test fails with Call Library Function Nodes

Similar Messages

Maybe you are looking for