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

Similar Messages

Can Prelude use the MXF preview files instead of the full size files?

It takes forever to load and view my full size MXF files from an XDCamHD disk. (It can also cause Prelude to crash) It seems like it would be very helpful to be able to view the tiny preview files contained in the "Sub" folder. You could quickly review your media, decide which files to transfer and then do so with the originals. Has anyone been able to see those files in the Prelude Ingest window? I only see the file icon, not the video media.
I had been using the Sony XDCam Transfer App with Final Cut, but am now trying to create a better workflow all inside Adobe software.

Hi AEDave -
Thanks for your post.
Wanted to share that we have been working on the performance with the XDCAM optical disc thumbnail load times (as well as other performance enhancements for this format). We are seeing a nice improvement on that front in our recent testing. And as Wes mentioned above we are also looking into how to best handle the proxy files the camera generates as well. Just wanted you to know we have improvements in the works for your workflow!
Thanks -
Michael

Where is pointer pointing to in Call Library Function

I am using Call Library Function (FillString) to call a function in a DLL. I set Parameter 1 to:
Parameter: arg1
Type: Array
Data Type: signed 32-bit Integer
Dimension : 1
Array Format: Array Data Pointer
so the Function Prototype below in the Call Library Function dialogbox is written as:
void FillString(long *arg1);
At the same time, in the block diagram , there is a "input param" (array of int32) and "output param" (array of int 32)
I wonder, when the program is in the DLL FillString function and using arg1 pointer, does "arg1" point to the data in "input param" arry or the data in "output param" array? I don't quite understand, since normally C programs have only one return value, while the Call Library Function returns a value for every input parameter. Is the "output param" a different variable, or the same as "input param" (i.e., the same physical memory address)?

Hi LyLee,
if you know how many elements you need, create an array with this number of elements by using the "initialize array" function and connect it to your dll node. The output shall contain your data. If you have a string its the same. Create an empty string with the size you need. See the attached example picture.
Mike
Attachments:
Unbenannt.PNG ‏3 KB

Call library function windows 95

Hi everyone,
I have a problem with the call library function, I have a program that inputs a parameter to the call library function and it all works ok
on a windows 2000 machine but the customer is using windows 95 and LabView 5.0.
When I run the VI on the customers machine (win 95)the output of the call library function is always the same.
Do you guys have any clue why that is happening?
See attached file for the code and more info.
Info on the program:
The dll file connects to an database and checks that the unit under test is at the right station in the production line.
The database connection and everything else works but SFDC_Check always comes back with a zero.
Thanks for the help and taking the time.
Best regards /Johan Lindberg
Best Regards
Johan

Sorry here is the attached file:
Best Regards
Johan
Attachments:
SFDC.zip ‏124 KB

Call Library Function "Function prototype" incorrect

Why does the same DLL file produce difference function prototypes?
I inserted the call library function node in my VI directly. However it has the incorrect function prototype.
This call library function node I copied from the “Goodness of Fit.vi”. This has the correct function prototype.
Solved!
Go to Solution.

The DLL file DOES NOT produce prototypes at all. That is up to you! Look at the parameters tab for both of your examples, you will see that for the second one, someone has already filled in the prototype information. When making a new DLL call, you will need to know the correct prototype to apply, this is usually obtained from the .h (header) file.
Charles Chickering
Architecture is art with rules.
...and the rules are more like guidelines

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

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

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!

The call library function require us to define the type of parameter that w are using.The type of parameter in cludes numeric, array, string,waveform and adapt to type.I would like to know more about waveform and adapt to type.

In the labview manual, there is very little mention about the use of waveform.How is this waveform being called and can i have an example to see how this work.
Also in the adapt to type paramete, what does this parameter do and in what circumstances do we need to use it.The manual say something about the use of this parametr.It says that scalar elements in arrays or clusters are in line.For example a cluster containing anumeric is passed as pointer to a structure containing a numeric. What does this statement mean?
Can i imply t
hat if my input is a struct, can i use a adapt to type parameter to overcome this incompatibility?Can i also have an example to let me have a better idea.thank you

I'm going to share my experience with the "Adapt to Type" parameter.
Attached to this message is an example. The attachment is a zip file with three files: a dll, a c file and a vi written in LabVIEW 6. The dll contains a function that return a structure with 3 values (like the coordinates of a point in space, that is, (x, y, z)). You can see how the function was constructed by looking at the c file.
In LabVIEW, I created a cluster with the same three parameters. Then, I configured the call library function following the function prototype as in the c file. For the point variable I use "Adapt to Type".
I hope this can give you a head star.
Best regards;
E. Vargas
www.vartortech.com
Attachments:
pointexample.zip ‏63 KB

Call library function will not retain change of directory for the library.

I have created a call to a dll made in Visual C++. Everything works fine. I then configure the vi to call the a newer version of the library that is in another directory. The Call Library Function dialog box updates with the new path. I click the OK button. Then configure the vi again to very my change took and it is back to the original path to the library.
Why can I not change where to find the library? I am sure that I can make a new vi an input all the parameters again, but I have many parameters and calls to the same dll. Making new ones each time the location of the dll changes is not an option.
Thanks for your help.
Attachments:
code.zip ‏106 KB

If you have more than one VI accessing the same DLL, then you can't
change the DLL location without unloading all the other VIs first. This
is because Windows will always look first for the DLL in memory, before
even attempting to load it from disk. And if another VI makes use of
that DLL it will be still kept in memory.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

An exception occured within the external code called by a Call Library function Node

Good Morning,
I built a VI that contains Matlab nodes in Labview 8.0. I made an executable and gave it to a colleage to use who is running Windows XP. I see in the folder C:\Program Files\National Instruments\Shared\LabVIEW Run-Time that she has 7.1 and 8.0 run time engines installed.
On Friday the executable ran great on her machine. Today, when she tried running it I received the following error. "LabVIEW: An exception occured within the external code called by a Call Library Function Node. This might have corrupted LabVIEW's memory. Save any work to a new location and restart LabVIEW. 'my vi' was stopped at node 0x0 of subVI "NI_AALBase.lvlib:Real A x B.vi:1". This error occured after part of the program ran properly. More specifically, two of the matlab nodes ran perfectly. I am unsure about the third because the program stopped too early. I do have to multiply two matrices using the subvi Real A x B. Is this causing the error?
I also saw this error when I installed it on another computer. However I do not see this error when I run the executable or the main vi on my machine I know there are other discussions on this topic, however I do not know why it would affect some machines and not others. Also, I do not know why it would work on Friday and not on Monday. Should I have checked the box that said "Enable Debugging" under the advanced section when building the executable?
If anyone could help, I would be very appreciative.
Thanks,
-Richard

molecularvisions wrote:
Good Morning,
I built a VI that contains Matlab nodes in Labview 8.0. I made an executable and gave it to a colleage to use who is running Windows XP. I see in the folder C:\Program Files\National Instruments\Shared\LabVIEW Run-Time that she has 7.1 and 8.0 run time engines installed.
On Friday the executable ran great on her machine. Today, when she tried running it I received the following error. "LabVIEW: An exception occured within the external code called by a Call Library Function Node. This might have corrupted LabVIEW's memory. Save any work to a new location and restart LabVIEW. 'my vi' was stopped at node 0x0 of subVI "NI_AALBase.lvlib:Real A x B.vi:1". This error occured after part of the program ran properly. More specifically, two of the matlab nodes ran perfectly. I am unsure about the third because the program stopped too early. I do have to multiply two matrices using the subvi Real A x B. Is this causing the error?
This is most likely an error with the use of the Call Library Node, but not in the Real A x B.vi itself. This is a VI that comes with LabVIEW and has been tried and tested many times and unless your LabVIEW installation is messed up simply shouldn't fail in such a way on its own.
However you do include Matlab code somewhere and that might be more likely to cause this. Are you using the built in MathScript node or some other way to communicate directly to a Matlab DLL or such?
Are you using anywhere Call Library Nodes that you have created or that did at least not come standard with LabVIEW?
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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.

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.

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

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

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

Similar Messages

Maybe you are looking for