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

Similar Messages

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

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

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

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

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

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

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

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

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

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

Call Library Node + Windows Console

Hello NI developers!
I have a DLL for LabView.
Inside the DLL there are many "printf("...Text....")" calls.
If I compile source code as an .exe and run it - it runs a windows console and shows text outputted buy " printf(....) " and even somewhere expects input from keyboard.
I want my DLL, when I execute VI, also launch console and show all the information the same way as a console application.
I understand that I can simply make a VI which executes .exe application, but I need to receive data from this program to Labview, so I think I should use a DLL.
Could anybody point me at a possible solution of this problem?
Thank you in advance.

to Wiebe
I've already tested AllocConsole(). It opens a console and attaches it to VI's process. So if I close either the console or VI - both of them closes immediately.
I even learned how to print text in a new console. But I reached a problem that my driver uses a custom function which processes inputs from a keyboard.
And it is quite difficult to edit this function. So this solution is rather complicated.
Could you tell a bit more about those "ogPipes" ? or post a link to a some kind of doc.
And what If I do not want to run my VI from a Console by typing every time? Then I could make two VI's, 1st VI simply launches command line and runs 2nd VI, which does all work.

Call Library Node; enum structure

Similar Messages

Maybe you are looking for