Call library node in builded exe - path problem

Hi!
I have builded an EXE with the App. Builder. In my application I use the Call Library Node, and call functions from a DLL.
I give the path of the dll with the "Current VI path", than strip the path, and add the DLL-s name. So in the CallLibNode I check the "specify path on diagram" option.
It works when I run my application on a PC that has the LV 8.5 installed.
But when I install my app on a PC that does not have it, just my setup installs the Runtime Engine onto it, it does not work, and I get errors.
Which is the proper way to give the DLL-s path, if I want my app run on any PC that does not have LV installed?
Thanks:
Waszil

Does the executable run correctly on the development machine? If not I would imagine it is a problem with how you are referencing the dll.
Have you installed all necessary support libraries you may be using throughout the program on the target machine? Are you able to confirm that the error messages are referencing to the dll not being found?
It sounds like you are referencing the dll correctly. When compiled, the dll is put into the 'data' directory within the root directory, so make sure that is there on the target pc
Message Edited by yenknip on 08-04-2008 10:42 AM
- Cheers, Ed

Similar Messages

Included DLLs path, call library node

Hi,
somebody handed me a DLL I want to use (specifically, from compiled with
matlab) in Labview. The problem is that the DLL has dependencies upon the
matlab c math library functions.
So in Labview I can add a call library node for the dll, but it still
complains about not finding the matlab library functions. What do I need to
do to let Labview know where I have these libraries stored?
-joey

It sounds like your LabVIEW code is successfully calling your .dll It is then the .dll's responsbility to find the files it needs, and ideally the documentation with the .dll or with Matlab should answer this question. After LabVIEW calls your .dll, the code in the .dll is the code in charge of what happens. There is a good chance that the .dll is only programmed to find the files it depends on at a given relative or absolute path which is no longer correct wherever you have copied it to.. if you control the code for the .dll, particularly the error message, this is a good reason to have the file not found error message explain where it was trying to look (i.e. be specific)
If this program is something you just need to run and not distribute, maybe you should just
browse for the .dll from the Call Library node in the location where Matlab creates it... if it doesn't even work there, you will definitely need to find out how the Matlab .dll is supposed to work.
If you can call a .dll from Matlab, try moving it and then calling it from Matlab again, and check whether any Matlab environment path settings are being used or assumed in the .dll code.
Good luck

Using header files with call library node

I am writing an application for Palm PDA, and I use call library node to insert some C code written in Codewarrior 9 for PalmOS.
For some reason, when I build the program for the Palm the builder does not recognise the functions declared in my header files.
Please help me with this problem and tell me how do I create a header file in Codewarrior so the builder can include it in the Palm application!!!

Hello
Can anyone help me out? I am trying to use a chart with a Sliding Region of intrest function.
I would like to be able to zoom in on the RIO and have the ability to zoom back out.
I would also like to be able to set the initial mid point setting of the RIO slider. The original file was using the delta T (psec) control to do this.
I have only been experiementing with this number to see what value works. If someone could explain what is going on with that control it would help.
I noticed that when I move the RIO slider to the left all the way the value goes negative, I am not sure if the program stops reading the value
at zero or not.....
When you run the select RIO Rev 4 vi set the DATA COL to PLOT to 1 to see the correct data
Thanks in advacne
Tim C.
1:30 Seconds ARRRGHHH!!!! I want my popcorn NOW! Isn't there anything faster than a microwave!
Attachments:
Sliding ROI Rev 4.zip ‏111 KB

Call Library Node

Hi,
I have experienced some problem (refer to my attachment) in running my LabVIEW program as an EXE file. However, such error did not appear when the program in running as llb format. I suspect it has something to do with the configuration of the Call Library Node.
Please kindly advice. Thanks
LCM
Attachments:
error_vi.bmp ‏681 KB

Jack J. wrote:
Have you tried
recreating the EXE. It might just be a problem of VI corruption. Also
try copying the dll that you are using into the same directory as the
executable. Again, these are general suggestion. Since the message says
that the error is occuring within the dll, it might be something more
than just the configuration of the call library node. If you want to send me the dll and example program, I can try it out here. Regards, Jack J.
Applications Engineer National Instruments
That
sort of errors almost always means either a wrong Call Library Node
configuration or setup or a bad DLL itself. The fact that it doesn't
crash in the development environment is just bad luck and I really mean
here BAD. Since the application has a different runtime setup (no edit
features of the devlopment environment and such and smaller VI code)
the chances that a bad memory access corrupts some vital data for
LabVIEW are different and most often higher. Your DLL still corrupts
memory even in the development environment but happens to do so by
chance in an area LabVIEW doesn't care for that particular application.
A seemingly small change to the VIs could change that at any time and
make your program crash even in the development environment. Check out
the call library node and make sure you have configured everything
accordingly. A common error here could be that the DLL expects a string
or array buffer of a specific size and you pass in a to small string or
array. Even a single byte such as for the terminating zero character of
strings can be and sooner or later will be already fatal here.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How do I fix a Call Library node with an unwired or bad terminal?

I am currently working on a program that's designed to both send and recieve analog data to/from a BNC 2090. Somewhere along the line, LabVIEW came across a problem in the Call Library Node in the Create AO Channel.vi. Because of this, most of the important subVI's don't work anymore. I've attached the file I'm working on. How would I go about fixing this unusual problem?
Solved!
Go to Solution.
Attachments:
voltageex.vi ‏230 KB

mecheng86 wrote:
I am currently working on a program that's designed to both send and recieve analog data to/from a BNC 2090. Somewhere along the line, LabVIEW came across a problem in the Call Library Node in the Create AO Channel.vi. Because of this, most of the important subVI's don't work anymore. I've attached the file I'm working on. How would I go about fixing this unusual problem?
Maybe Just maybe the problem is that dynamic data type cast
the DAQ assistant is set for continuous samples and "Use Waveform timing" is checked. you have a scalar DBL wired to the assistant for data. Just where do you think Samples per channel and dt are going to be coming from? Kind of hard to get them from the Size(Y) and dt components of a scalar.
Jeff

Call library node - using a structure with dll

Hi folks.
I was hoping to recieve some help or advice on solving this problem I am having in labview:
Some background info - I am trying to use the 'call library node' to allow me to use a .dll to allow for control of a remote power supply over RS-232.
I have been doing fine up till now, however I am now trying to use the following:
int TC4GetFnBlockSettings(struct T_FnBlock *p_fnblock, unsigned int type)
int TC4SetFnBlockSettings(struct T_FnBlock *p_fnblock, unsigned int type)
where
struct T_FnBlock
unsigned int BaseFunction;
double Amplitude;
double Offset;
double Symmetry;
double Frequency;
int BipolarAmplitude;
int RectifyAmplitude;
double ExpTimeConstant;
unsigned int NumPeriods;
unsigned int UserDefAmplitude;
unsigned int UserDefTimePrescaler;
double UserDefPeriodLength;
unsigned int UserDefNumPoints;
unsigned int InactiveLevelType;
double InactiveLevel;
unsigned int AAPInputType;
unsigned int AAPInputFilterKoeff;
unsigned int AAPFlags;
double AAPInputScaling;};
Obviously there is no such thing as a structure in Labview; I had hoped to use a cluster in it's place however the CLN does not allow for input or output of a cluster.
Any help would be appreciated!
Thanks
Solved!
Go to Solution.

Akiel wrote:
unfortunalty the call library node doesnt map labview types to c types very well. It can be done but took me a lot of time and effort (and overworking google) to manage it. In the end i abandoned the cln and write a c# code that interfaces between my dll and labview.
sorry cant be of much more help.
I think NI need to improve this functionality as the CLN could be useful but hard to get working on anything beyond a simple dll interface
That is not true!
The Call Library Node does a tremendous job in providing configuration options to map LabVIEW data to most C datatypes. In most cases the two match directly except when arrays and strings are concerned. Those two are very different in LabVIEW than in C but the Call Library Node allows to configure parameters to map LabVIEW strings and arrays to according C string and array pointers.
A structure in C is directly equivalent to a LabVIEW cluster unless it contains strings or arrays. Also there is the potential of structure element alignment which you have to take care of explicitedly but that is hardly the fault of LabVIEW but rather a direct consequence of the rather low level character of the C language.
Since the OPs C struct only contains scalar datatypes you can directly create a LabVIEW cluster with the same elements and the same order of elements and pass that cluster to the Call Library Node parameter configured as Adapt to Type.
The reason that you might have to get google overworked for such things is not because LabVIEWs support for interfacing to C code is bad, but because interfacing to C code is such a complex topic in itself. Without a lot of low level knowledge about what a C compiler really does when creating functions you are bound to do a lot of trial and error and googling. You get the same issue when trying to interface unmanaged code in C# (.Net).
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Call Library node and multiple array copies

Hey everyone,
I am trying to do the following using a hybrid of C and Labview:
1.) Create an array in Labview
2.) Pass the array into 2 seperate DLLs at the same time
3a.) One DLL modifies the data and then updates a flag. For example, the array created in 1 in 100,000 units long, this DLL modifies 999 units in one pass and updates the 1000th unit to say that the 999 units have been succesfully written. It would do this 100 times in this example.
3b.) The 2nd DLL checks the flag unit set in 3a, and if the flag is a certain value, the 2nd DLL reads the 999 units modified in 3a and performs operations on them.
Note: There is no read/write conflict here, since the only way 3b operates on the memory is if 3a has completed its operations and updated the flag.
The problem:
Labview creates 3 copies of the same array in memory. Once in step 1, and 1 for each DLL. This is problematic since the 2 DLLs can't communicate with each other anymore in the way that is described above, since the method above requires that the DLLs in 3a and 3b operate on the same memory locations.
The question:
How can I prevent Labview from creating multiple copies at the Call Library node so that my DLLs can operate on the same chuck of memory that is created in step 1.
Thanks,
Austin McElroy

AustinMcElroy wrote:
Ok, so as nk said, even if the idea is terrible why is Labview making extra copies? If I have 2 DLLs in serial to avoid the flag idea, and I am working with datarates of 100MB/s coming off of my acq. card, that is 100MB allocated for the initial array, 100MB allocated for the first DLL and 100MB allocated for the 2nd DLL, per second. Perhaps even more allocations and copying from C back into Labview (I am unsure of this, I will test it tomorrow). This is alot of memory being allocated and copied extraneously. Is there a way to prevent Labview from doing this?
And LabVIEW doesn't make copies if it doesn't need too. For this to work however you need to pass the array through the CLN (input it on the left side and output it at the right side of the CLN and from there wire it to the next function), not branch it. That should even work if you configure the array parameter to be a C array data pointer (since LabVIEW will pass the pointer to the actual data to the DLL), but it definitly works without copies for LabVIEW array handles.
Then LabVIEW won't make a copy (except maybe in some older versions).
If you branch the wire however, LabVIEW has no choice but to create at
least one copy to satisfy data flow contraints.
This doesn't mean that the first DLL function could store the array pointer and operate on it after it has returned since a C function once returning control to the caller has absolutely no control over a pointer it got passed anymore. At the time your DLL might decide to access that pointer LabVIEW quite likely might have left the diagram already and consequently deallocated or reused the handle for something else, causing your DLL to corrupt memory. Even if you decide to use events to signal the second function to not return before the data has been modified by the first, you create a monster of complexity that will sooner or later blow in your face. Either the user might decide to abort the programm mid term and your second function never receives the signal so never returning, making your application simply hang in there with no other option than to kill it through the task manager, or someone will go modify your little program not knowing the (unlogical) dependency of those two calls and creating something that simply works very wrong or if you are very lucky will crash with an access violation exception early on.
Rolf Kalbermatter
Message Edited by rolfk on 03-24-2008 01:39 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

SO Wait causes exception occurred within external code called by call library node

when trying to run some old code that used to work ok, i now get this error message:
exception occurred within external code called by call library node
and the vi flagged as calling the exception is SO Wait. the error occurs with different soundcards. does anyone know what is causing this problem?

Hi Kreuters
It sounds as if you have a case of memory corruption. Which version of LabVIEW and DAQ (traditonal or DAQmx) are you running and also on which operating system?
would it be possible for you to post your VI on this thread? in some cases there are ways to fix the problem
Regards
YatinM
NIUK

Why does the DLL function executed by call library node fail when the Vi is re-opened?

Development System
OS: Windows XP
LabVIEW: version 10.0
DLL: Custom
Compiler: Visual C++ 6.0
Function Prototype: __declspec(dllexport) const char * test(void)
We have developed a DLL for use. The DLL compiles cleanly.  The DLL includes a function test.  The test function validates the functional capabilities of the DLL. I have followed the examples online, and I have used the import shared library tool in LabVIEW. The VIs created use the call library node.
When I create a VI calling the test function from the custom DLL using the call library node the VI executes the DLL function test flawlessly. I close the VI. When I re-open the VI and run it, I get an error code from the DLL.  However, if I go to the block diagram and set the path for the DLL in the configure call library node again then the VI executes the DLL function test flawlessly again.
I have to set the path for the DLL in the configure call library node every time I open the VI. The examples I downloaded from the community do not require this. What might the DLL be missing? What am I missing?
Solved!
Go to Solution.

I think it was rather unfair of me to ask for help with my DLL issue without disclosing more detailed information. As a corrective action, I have attached a zipped file. The zipped file contains the entire VC++ 6.0 project for compiling the DLL, the DLL, and the VI I have been using to test it.
###NOTE####
As a prerequisite to compilation and usage of the DLL you'll need to have installed Python 26 on your system.
You may obtain the MSI for correct version of Python from the following location:
http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi
###NOTE###
Thank you very kindly for any assistance offered!
Thanks,
Bill
Attachments:
C_DLL_PYTHON_AND_LABVIEW2010.zip ‏1685 KB

How does LabVIEW convert string to char* when passing them to a Call Library Node?

I have a program which calls C++-based libraries which themself use external libraries (Qt). I pass strings to my library through the Call Library Node, and was wondering how the formatting goes? I have to interpret the char* according to Latin1, UTF-8, UTF-16, ... to convert them to a string which the Qt libraries understand. I need to use char* instead of LV strings, because the library is indepent of LabVIEW.
It seems that interpreting the char* as Latin1 (default) does not work on Korean systems (for one of our customers), which is understandable when you know that the Latin character set does not know Korean signs. Anyone knows how the char* should be interpreted then? In other words, for non-Latin languages, what exactly is passed to the DLL?

I don't think that we reinterpret your string in anyway, just reformat the data so that it can be passed to your dll.
So assuming you are getting text from, say, keyboard editing, the text should be in the ANSI codepage that the system is running under. That is, if you are running Windows using an English locale, it will be codepage 1252 (Windows Western, Latin 1), if you are running Windows with a Korean codepage iirc it will be codepage 949, Unified Hangul code.
If you are filling the string with data that you get from an instrument or some other fashion, it could really be anything.
Here is a list of the codepages that Windows knows about
http://msdn2.microsoft.com/en-us/library/ms776446(VS.85).aspx
I do have some experience with Qt as well, and I think that the function you are looking for to create, say, a QString from this is:
QString::fromLocal8Bit
but I am not 100% certain about this as I am not a Qt expert.
Jeff Peters
LabVIEW R & D
Message Edited by jpeters on 04-02-2008 12:38 PM

Getting error in call library node when establishing communication with MAX1452 on serial port using dll

I want to communicate with MAX1452 in labview on PC serial port. Maxim provides dll file which has functions to communicate with device.It says first two functions should be findcom port and initialization sequence where findcom port returns PC's serial port address while initialization sequence helps device to learn baud rate.Iam not getting exception error in call library node.i have kept dll file in the same location as VI.

Labview verison is 7.1 and os is win xp.
The data types are according to the dll functions defined in functions definitions( attached previously).
I'd put dll in the same directory where the code resides.
Attachments:
Code.vi ‏23 KB

Exeception caused by Call Library Node

I'm getting a serious error with LV DSC 7.1. I was making some changes to the scf file but when I went to save it I got the following error.
An exception occurred within the external code called by a Call Library Node. This may have corrupted LabVIEW's memory. You should save any work to a new location and restart LabVIEW. VI "dsc_DYN_TAInitDB.vi" was stopped at Node 0x48B4 of subVI "dsc_InitTagGroupsDB.vi"
When I restarted LV the error message appeared straight away and I could not start the Tag Configuration Editor. I have since tried repairing and reinstalling the DSC module. This let me get back into the TCE but I still got the error when I tried to save the SCF file. I thought the scf file may have been corrupt so I exported the data to a txt file and imported it to a new file but I still get the same error on saving.
I've just finished a complete reinstallation of LV, drivers and DSC module. When I open the TCE for the first time I created a new scf and and again imported the tag info from the txt file but again when I went to save it I got the error.
There are over 150 tags in the scf for an ethernet FieldPoint system. The PC is running XP Pro. The application was recently upgraded from V7.0 to 7.1. Everything was running fine until the edits to the scf. However, this was not the first edit to the scf I had made.
The knowledgebase contained details of a similar error for LV 6.1 and there were updated drivers available. Is there any ubdates for LV 7.1?

Hi Rob,
Thanks for your reply. However, I tried the uninstall, registry clean, reinstall as described but I still got the same error when I tried to save the scf after importing the tags from the text file. The error makes it impossible to open the Tag Configuration editor unless I uninstall and reinstall the dsc module which makes it very time consuming to even try anything different.
For now I'm going to go back to V7.0. I've attached the scf file and the exported tag data which I tried to import.
Thanks again
Paul
P.S It appears that .scf is not a valid extension for an attachement so I had to zip it.
Attachments:
Outside Test Rig.zip ‏4 KB
OTR Channel Tags 18-05-06.txt ‏63 KB

Call Library Node; enum structure

I suspect that I already know the answer to this. But is it possible to pass in the following defined structure to the call library node from labview:
struct HStradisDecoder {
unsigned long hHandle;
typedef struct HStradisDecoder* STRADISDECODER;
Thoughts and Ideas?
Using LabVIEW 8.0+
Paul <--Always Learning!!!
sense and simplicity.
Browse my sample VIs?

Hi Paul,
First I'd get Guenter's suggestion working - it should work! (and would make the parameter-passing very simple.)
Without knowing anything about the larger application it's difficult to guess why it didn't work. Is the hHandle the correct value? Does the "endian-ness" of hHandle change from caller (LabVIEW) to callee (DLL)? - it might be necessary to reverse the byte-order of the U32/hHandle.
Attached is an example of a VI that calls a WinAPI (User32.dll) function. The last two parameters to the DLL are non-trivial structures - passed and unpacked as arrays!
I stuffed the diagram with lots of prototypes, descriptions and links from MSDN - enjoy.
Cheers!
Message Edited by tbd on 08-16-2007 01:30 AM
"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Attachments:
Launcher.vi ‏145 KB

Call Library node error [1]

Hi,
I've written a program to control the angular position by using PID control algorithm.
The program works fine but after certain amount of time. The system hanged and need to shut down the LabVIEW and restart.
The warning message pop up is showing in the attached file.
One more question, is it the PCI-6221 M-series card can used for real-time application.
Just for your information, I'm using:
- LabVIEW 7.1
- PCI-6035E
The program is attached to the message "Call Library node error [2]"
Thanks.
Best regards,
IANES
Attachments:
Error11.bmp ‏405 KB

Hi,
It would be very helpful if you could post the code you are using to generate this error. These call library errors can be caused by many things.
Check out the following KnowledgeBases:
http://digital.ni.com/public.nsf/websearch/0120D13E4B4C94BB86256A3F007695EE?OpenDocument
http://digital.ni.com/public.nsf/websearch/58596F5D41CE8EFB862562AF0074E04C?OpenDocument
-Sal

Call library with struct as parameter - several problems

Hi everyone,
I'm trying to send a MIDI sysex message to a midi device through winmm.dll using MidiOutLongMsg. I have trouble figuring out how to pass the parameters right.
I need to call three functions (midiOutPrepareHeader, midiOutLongMsg, midiOutUnprepareHeader), all of them having the same form
MMRESULT midiOutPrepareHeader(
HMIDIOUT hmo,
LPMIDIHDR lpMidiOutHdr,
UINT cbMidiOutHdr
where HMIDIOUT hmo is a handle that I have already. Troubling me are the other two parameters. cbMidiOutHdr is the size (in bytes) of the struct lpMidiOutHdr. This is a struct of the form
typedef struct {
LPSTR lpData;
DWORD dwBufferLength;
DWORD dwBytesRecorded;
DWORD_PTR dwUser;
DWORD dwFlags;
struct midihdr_tag far * lpNext;
DWORD_PTR reserved;
DWORD dwOffset;
DWORD_PTR dwReserved[4];
} MIDIHDR;
(Struct: http://msdn2.microsoft.com/en-us/library/ms711592.aspx
PrepareHeader http://msdn2.microsoft.com/en-us/library/ms711634.aspx
SendMessage http://msdn2.microsoft.com/en-us/library/ms711629.aspx
UnprepareHeader http://msdn2.microsoft.com/en-us/library/ms711641.aspx)
[Note: The full code for what I want to do can be found here http://www.borg.com/~jglatt/tech/lowmidi.htm (section "outputting system exclusive MIDI messages) - basically I need a translation of this code to LabView.]
The following are my problems:
a) How do I emulate a struct in LabView? (other threads suggest that this is done by clusters)
b) How do I pass a pointer to a struct (cluster?) to a DLL?
c) If I can use a cluster for this struct, how do I represent the LPSTR lpData in the cluster, i.e., a pointer to my data?
d) how do I get the struct size for cbMidiOutHdr?
This is how far I got, lots of it with the help of several threads in this forum:
a) use a LabView cluster
b) use "adapt to type" in the dll call (couldn't get this to work)
c) I use a type cast on my string in the hope that what it returns is the register address (and I'm probably superwrong here)
d) my cluster consists of 9 elements of 4 byte datatypes, so I just use 36 for cbMidiOutHdr
The dll seems to be happy with the way I pass the cluster - I get error codes of 0 in both the PrepareHeader and UnprepareHeader functions. However, sending doesn't work (error code 7). Guessing that the type cast returns a pointer, I have also cast the cluster to an Int32 and passed that parameter as pointer to numeric value. Interestingly, the PrepareHeader and UnprepareHeader functions are still happy, but I get a different error code from the sending (code 11)
Most of what I've done so far is guesswork, and I'm out of guesses now. I've attached the code to this post (it uses VIs from the NI MIDI example library ftp://ftp.ni.com/pub/devzone/epd/midi-example.llb ). I'd appreciate any help with this. Thanks!
Attachments:
Write MIDI SysEx Message.vi ‏21 KB

First off, this problem doesn't have anything to do with control references; those have meaning only inside of the LabView environment.
My first suggestion is to look for a higher-level library that will do whatever MIDI function you are trying to call. If you can find an ActiveX or .NET object that will control the MIDI subsystem, I recommend that you use it instead since it will be a lot easier.
If calling the DLL directly is the best option (and calling DLLs is absolutely the way to go when you need high performance) then you need to understand how LabView passes data to library functions. That is described here:
http://zone.ni.com/reference/en-XX/help/371361D-01/lvexcodeconcepts/configuring_the_clf_node/
As you can see there are a lot of ways to pass data, but they boil down to this: LabView can pass, via various levels of dereferencing, a pointer to some [mostly] flat data. Things are easiest when your DLL mimics LabView's own data storage methods. For example, wiring a cluster into a node set with Adapt to Type passes a handle (struct**, pointer to pointer to [mostly] flat data). So if you are writing your own DLL, it's pretty easy to write something that works nicely with LabView data (e.g., strings with 4-byte length headers, self-describing arrays) and in fact the result is cleaner looking than its "pure C" variant because of the self-describing arrays and string length prefixes. (I say "mostly" flat because LabView clusters with variable-length elements aren't stored in a flat format.)
When it comes to matching someone else's API things get harder, and in this case you are out of luck; you are going to have to write a LabView-callable wrapper function in C because LabView can't mimic the exact data structure needed. The problem is not the struct; there is a sneaky way to pass a pointer (vs a handle) to a struct, which is to do this:
Generate a cluster in LabView representing the struct (atomic numeric data only! no strings arrays etc!)
Flatten to string using native byte order.
Convert string to byte array.
Configure the call library function note to accept a pointer to an unsigned byte array. (NOT a C-string as suggested at the bottom of the page in the link above; your data may have internal 0x00s, and it certainly doesn't need an extra 0x00 at the end!)
The reason this works is that a pointer is just an address; as long as all the right bytes are in memory in the right order starting at that address, all is well. The DLL doesn't know that LabView thinks it is passing a pointer to an array of bytes, it just gets the pointer to the first byte and it reads and interprets those bytes according to its own struct def. Reverse the process cooming back from the DLL (convert byte array to string, unflatten from string against the LV cluster.) This method will work for any flat struct.
In LabView 8.5 there may be a less bogus way of doing this, which is to pass the cluster in with Adapt to Type and select "Array Data Pointer" as the format. This is new and I haven't tried it.
But in your case, you want to point to a struct that contains a pointer to a string plus some numeric data and another pointer, and this you can't do directly. LabView does not expose the location of a string to you anywhere outside the Call Library Function node, so there's no way to "find the pointer" to a LabView string from outside the DLL. What you need to do in this case is write a wrapper function in C that takes your LabView data. Only then will LabView "tell you where the bytes are" and promise not to fiddle with them until the library call is complete. Once you are in C-land, you can throw pointers around to your heart's content. As long as you do it all perfectly, all will be well. (If you write one byte too many on output, boom! :-)
There are a few ways to do this. You could make a cluster that has meaning in LabView, e.g. replace lpData with a LabView string, then pass the cluster in to your wrapper function set to "Adapt to Type"; that will pass a handle to the cluster. You can generate the .c file from the Call Lib Fuction, and it will outline where the data is.
Complications: In this case it's your job to convert the handle to the labview string (which has 4 bytes of length as a prefix and no trailing 0x00) to a C-string by malloc()'ing a new buffer and memcopying the string out. There might be something in the LV CIN tools that does this, I'm not sure. Make sure you release the new string after the MIDI call.
The lazy route (which is what I would do) is pass the string as the first arg and all of the numeric stuff as the second arg, leaving the space for lpData as you have now. (I don't know what struct "midihdr_tag" is, but if that's not something you were passed in a previous call, you'll need to add a third argument for that cluster and treat it similarly.) Then you can tell LabView that it should pass the string arg as a C-string pointer. Inside your wrapper, extract the pointers and stuff them into the data structure as needed. Dereference once (to go from handle to pointer) and make the MIDI call. To be clean, put everything back where it was before in the cluster; in particular don't believe you can pass out lpData* and do whatever you want with it in LabView; LabView will release/change that address as soon as you leave the output string unwired or do anything to it (e.g. concatenate.) You'll be creating a new string buffer and a new pointer on your next MIDI call.
All of this complication is a result of a) LabView's hiding the details of memory allocation/deallocation from you and b) LabView's internal data structures being a bit different from C conventions (e.g. LabView strings vs. C strings). The second means that even when LabView is using non-flat data structures (e.g. cluster containing an array), you can't just blindly pass them along to a C function and expect it to work right. It would be nice if NI would write a little mini-compiler into the Call Library Function that would do what our wrapper function is going to do, but that's probably a fairly significant project.
Still, each function wrapper is only going to have about 10 lines of C. You can put wrappers for all the MIDI functions you want to call into a single DLL, then ship that DLL with your app.
(Now you see why I suggested you look for an ActiveX MIDI control!)
-Rob Calhoun

Call library node in builded exe - path problem

Similar Messages

Maybe you are looking for