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

Similar Messages

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

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

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

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

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.

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 to include header files with different extensions

Hi,
When i include a header file with extension .ch (myincludefile.ch), the compiler gives error messages but when i change the extension to .h, the problem disappears.
Can anyone help me getting rid of this problem?
For example, for the line below, I get a warning such as, "attempt to redefine MY_CONST without #undef". Remember when i change the extension to .h, the problem disappears.
#define MY_CONST 500 /* Constant */
Thank you very much

I don't see how the name of the file could cause or prevent error messages, except when template declarations are involved. So let's assume for now that the file has a template declaration.
The Templates chapter of the C++ Users Guide explains about including or separating template declarations and their definitions.
If you have only a template declaration in a file and the compiler needs the definition, it will look for another file with the same base name and include it automatically. For example, if you have files foo.h and foo.cc, and foo.h has a template declaration, the compiler will include foo.cc automatically, even if you didn't intend for that to happen. You can wind up with multiple delcaration errors that way.
When looking for a file containing template definitions, the compile will not include a .h file, so as not to create recursive inclusion. If changing the file name to .h causes your problem to disappear, it seems like an unwanted automatic inclusion is the problem.
You can try two things to find out:
1. Compile with the -H option. The compiler will output an indented list of all included files. See if you are getting a file you didn't intend, or the same file twice.
2. Compile with option -template=no%extdef. It disables the automatic search for template definitions.
If you find an unintended included file this way, you will probably have to change the names or organizaiton of some of the files. Our implementation of the C++ standard library depends on NOT using the -template=no%extdef option, which might mean you can't use that option.

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

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

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

Using header files with call library node

Similar Messages

Maybe you are looking for