Advantages of Solaris 10 library function calls over Solaris 8 calls.

Hi,
We are planning for a migration of OS from Solaris 8 to Solaris 10. We referred some documents related to Solaris 10 features and the 'What's new' document for Solaris 10. However we couldn't find much difference on library function calls.
It would be really grateful if anybody could give some more information on the function calls that are changed from Solaris 8.
Thanks,
Palani_techm.

Can you be more specific? There's are whole slew of changes (dtrace, driver framework changes (usb, gldv3, sata...), graphical changes (gnome, opengl) ), some function additions to make linux source compatibility easier. I don't think the C library (3C) has been changed that much minus new functions, since it would make forward compatibility more difficult.

Similar Messages

Nested library function call

Is it possible to create a DLL using the LabVIEW Application Builder from a VI that already contains a library function call?
Thanks,
mlloyd

Hi mlloyd,
This should definitely possible. If you dig deep enough, you'll realize that some of our VIs such as DAQmx, signal analysis, etc, use Call Library Function Nodes, and you can build those into a dll, so this should work.
Best regards,
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

C library function call - Unavailable Type for one of the parameters in the Function Prototype.

Hi,
I'm doing a job that has been already done by some others: implementing a LabVIEW SQLite Wrapper, I know how to do that with .NET alas I would like to do that in C, mostly for performance purposes and my poor pointer knowledge is kinda make me stuck.
A couple of informations are kindly provided here:
http://www.sqlite.org
http://www.sqlite.org/cintro.html
What I would like to do, is just to open a connection to a SQLite Database (if not existing, the SQLite engine will create the embedded Database and the related file to save the data and everything). The function to perform the operation is given in page below:
http://www.sqlite.org/c3ref/open.html
It seems pretty simple:
int sqlite3_open(
const char *filename, /* Database filename (UTF-8) */
sqlite3 **ppDb /* OUT: SQLite db handle */
int sqlite3_open16(
const void *filename, /* Database filename (UTF-16) */
sqlite3 **ppDb /* OUT: SQLite db handle */
int sqlite3_open_v2(
const char *filename, /* Database filename (UTF-8) */
sqlite3 **ppDb, /* OUT: SQLite db handle */
int flags, /* Flags */
const char *zVfs /* Name of VFS module to use */
However I'm struggling a bit about the following type:
sqlite3 **ppDb /* OUT: SQLite db handle */
And I'm not really sure about which type to use when I'm calling this function from LabVIEW
Any idea, I guess it's real easy, but I'm not really used to have a type which is I suppose the DataInstance but as it's not clearly explicted in the LabVIEW interpreted C Library Function prototype (InstanceDataType makes sense but not sure though) I'm not really sure what I'm showing in the attached screenshot is valid or not.
My VI seems to work like a charm, but don't really know if I'm doing something wrong.
Another prototype that I have no idea about the proper LabVIEW call is the close function:
http://www.sqlite.org/c3ref/close.html
Let me get this traight, usually a parameter has a name, right? but seems that nope:
int sqlite3_close(sqlite3*);
int sqlite3_close_v2(sqlite3*);
So also no idea about the parameter setting for this one... has to be considered as the self instance like the one calling this function is this... but I'm not passing any object?
Really confusing...
sqlite3*
I might sound really silly, but if anybody could point me some directions, I would be really grateful for that.
Thanks

Ehouarn wrote:
However I'm struggling a bit about the following type:
sqlite3 **ppDb /* OUT: SQLite db handle */
And I'm not really sure about which type to use when I'm calling this function from LabVIEW
This parameter should be a pointer-sized integer, passed by pointer. Doesn't matter if it's signed or unsigned. The SQLite library will allocate memory for you, then put a pointer to that memory location into the pointer-sized integer that you pass in.
As for the close function, you should pass that same pointer-sized integer, but this time pass it by value (because it's referenced with a single *, not two). There's nothing wrong with the documentation omitting the parameter name. For the purposes of a function prototype, the parameter name is unimportant, since all you need to know is the type of the data. How the function chooses to refer to that parameter internally is irrelevant.

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

Call Library function

Hi,
I just transfered some of my programs (in LV5.0 - student edition) from one computer to another. The programs work perfectly on computer A, but when I transfered them to computer B, an error comes up saying 'call library function not supported in this version'. What I don't understand is that I am using the exact same LV5.0 student edition on both computers - was maybe an update installed on the original computer to allow the call library function to work? If so, where could I find this? Any other ideas why I can't use Call Library Function on computer B?

Hi LV newbie,
Th call library function calls functions within a dll. The dll can be an API or driver from the equipment manufacturer or custom-made functions to control or communicate with the DUT.
So the first thing I would look for is the dll in question.
When you transferred the LV code from computer A to B, did you do a mass compile? (Tools > Advanced > Mass Compile). You can try that. If already done that, open the vi giving you trouble and look at the call library function. Is it pointing to the right directory to find the dll? The problem may be in the ability for the vi to find the dll. Make sure it is calling the right function(s) and passing the appropriate parameters and values. Strange things can happen when moving LV from one PC to
another.
Let us know your progress.
JLV

Debug gives non-exect.,Call Library Function: no library specified error?

I have installed the VISA 2.6 as mentioned in order to be able to see the VIs for my TDS5104 scope. The VIs are still not exectuable because of this library function call. I have followed all instructions pertaining to the labview add on, etc. I have the tektronix drivers installed. How do I fix this error so that I can actually program my specific solution?

Hi,
I looked for the instruments driver at www.ni.com/idnet and found NI Instrument Drivers Network: TDS 5054 Multi-Environment Plug and Play Instrument Driver for the instrument. This driver is developed by Tektronix.
I don't have the driver available, but it is most likely that the Library node VIs can not find the dll. Go to the VIs that are not executable, right click on the library call node and select configure. Note the path and the name of the dll the node is configured to use. You can then look for the dll in your system. You have 2 options: change the path in the node to point at the location of the dll or copy the dll to the location the node is expecting to find it. Any of
those should make the node executable.
Hope this helps.
DiegoF
National InstrumentsMessage Edited by Molly K on 02-18-2005 11:02 PM

Using call library function on a dll file created in an old version of labview

So I'm trying to update an old labview program to work in labview 2012. Everything converted over just fine but labview will always crashoverwrote some while using a library function in a DLL that was compiled using labview 8.5. Labview exits, stating that it vital memory area. It passes an array of data to the library call and an empty array for output. I thought I could get around this problem by changing my code to initialize the array being passed in so that it would be large enough to hold all the expected output. Now instead of overwritting areas of memory it shouldn't, I get a pop up message that says:
fatal internal error
memorymanager.cpp line 406
8.5.1.f5
So it appears because I don't have the ability to recompile the DLL file it runs off of the 8.5 runtime instead of the more recent one. Is there any thing I can do about this?

rjpierce wrote:
So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with.
Your problem most likely is that you try to pass native datatypes to the DLL function? That only can work if the caller and callee use the same LabVIEW runtime engine. Otherwise the memory block created in the memory manager of the caller will be accessed by the memory manager in the callee and bad things happen. Instead you should define the DLL function to use standard C datatypes (Pointer to C array) and also make sure to allocate the according buffer in the caller for all output array parameters.
An even more elegant way would be to completely abandon the DLL approach and call the according functions directly in LabVIEW. Then you won't have the problems about mismatched runtime engines. Passing C array pointers to a DLL is less performant than passing native datatypes, but if you use native datatypes you have to make sure the DLL is compiled in the same LabVIEW version as the one you call it from.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

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

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

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

Call Library Function Node produces error in Windows 7

Hi,
I've created a simple program using LabVIEW 8.5 that uses calls in winscard.dll to read and write to a Smart Card. I use Call Library Function Node to call functions in C:\Windows\System32\winscard.dll. This program works without a problem in Windows XP both within LabVIEW 8.5 and once it is compiled. I am also able to get this program to run without a problem when I run it in LabVIEW 2011 on a Windows 7 machine. However, when I run the program compiled with LabVIEW 8.5 on Windows 7, the first call I make to a function in the DLL returns Windows System Error 2 (file not found). Subsequent calls to other DLL functions return errors about invalid handles, which makes sense.
Can I compile the project in LabVIEW 2011 and save it back to a LabVIEW 8.5 compatible project file?
Thanks,
Jason Mazzotta

Bannu wrote:
Hi All,
I am also having the similar issue. I have a VI, developed in LV2010 on Windows XP machine with a dll call using "Call Library Function Node".
It is working fine in all WindowsXP machines but not in Window7 PCs.
Getting Error when i tried to open in Windows7 machine:
Error loading "DLL path....". Invalid access to memory location.
Please let me know how to make this working on both machines [XP and Win7].
Thanks,
Soumya
Way to little information to say anything useful about it. Attach your VI, explain what it should do, explain what the DLL is you try to call! You don't call your mechanicien saying your car doesn't start and expect him to diagnose the problem over the phone either with that much information.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Failed to run parallel path when using call library function node in LV2009

I have a problem with two parallel paths not being run in parallel on LabView 2009.
See the image below.
This code initializes an external device, the upper part contains a call library function node to download my code into the device. When done, the function returns and the "Done" flag is set to True.
The lower part contains a call library function node to check the download status, reporting the percentage of downloaded code.
This updates a progress bar that is referenced by the calling VI module and this works fine in LV 7, 8 and 2011. The lower path of the VI updates the progress bar while the CLFN in the upper part is still downloading code to my device.
Somehow, in LV2009 this does not work when running this inside my application. When running just the calling VI (the window showing the progress bar) it works but not when that VI is called by my application.
Is there some limit on parallel threads that is different in 2009 than in other versions ?
Or is there some other problem in 2009 that might cause this problem ?
My labview version is 9.0f3 (32-bit).
Regards,
Rob

I've just installed the DETT tool and checked what the different versions of LabView do.
In LV2009 the application instance runs in a thread (5) but the modal dialog (the VI above) then drops to thread 0 and stays in thread 0.
In LV2011, stays in the same thread as the application instance and only a trigger event (this could be the progress bar reference?) is executed in thread 0.
So it seems there is a 'feature' in LV2009 where modal dialogs are by default not following the preferred execution system set in the VI properties ...
When I change this from "same as caller" into another thread (I used "other 1") then my progress bar works as expected.
I'm not a LabView thread expert (not even a novice ) so I'm just guessing that "other 1" as a thread is OK. This VI only runs during startup of the application to download the code to my device.
To answer Ben's question: "What thread does a modal VI run in?":
In LV2009, the modal VI runs in thread 0 (UI thread ?). When the preferred execution system is set to another thread, the modal dialog still starts in thread 0 but then switches over to the other thread.
In LV2011, the model VI runs in the caller's thread (preferred execution system set to "follow caller") from start.
Thanks,
Rob

How to call a C pointer from call library function node

I have a client/server application which the client I am trying to develop using Labview. When I use to communicate the server and the client using the program provided by the manufacter, the system works perfectly.
Now, I am trying to develop a system using labview, because I need to get another things.
I have the DLL provided by the manufacter and the .h too, so I can check the functions parameters. One of these functions needs to be called using a struct element. Probably, the function's DLL instantiates the elements of this struct. I use the call library function node to do it.
When I receive the data, the function returns to me the struct that I passed as a parameter before, and then I can read all the elements of the struct, except the string element that returns nothing. The struct elements that are numerical, I can read them perfectly.
Another thing that is important to say, is that the string data was not returned in fact by the DLL function that the system calls. I have to pass a pointer (I use it as unsigned 16 in Labview, but I tried before as string and unsigned 8) as a parameter, and this pointer will point to the memory location that the string is. When I try to read what is returned by the function, I can read nothing. The same function returns that the size of data that is returning is 17 bytes.
How can I solve it?
Thank you in advance

Did you take a look at the example that ships with LabVIEW that shows how to do all sorts of data passing to DLLs. I believe your situation is one of the examples listed. You can find the example VI in the "<LabVIEW install directory>\examples\dll\data passing" directory.

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.

Window doesn't close wheh Call Library Function Node set to Run in Any Thread

This is a problem regarding Call Library Function Nodes running in the UI thread or any thread.
I have a camera which has its own API supplied as a dll. I have created a set of VI wrappers which each call a function in the dll through a Call Library Function Node.
Initially each CLFN was set to 'Run in the UI thread' (the default).
To start the camera streaming images I call (through a CLFN)
ICubeSDK_Start(int CamIndex, Hwnd, ImgHandle, bool Preview, bool callback);
If Preview = True then the image is displayed in a preview window.
If ImgHandle = NULL a default preview window
is used.
In the CLFN definition I define:
ImgHandle as a U32
Preview as a I32
To stop the camera streaming images I call
ICubeSDK_Stop(int CamIndex)
In the actual implementation I set ImgHandle = 0 (NULL) and Preview = 1 (true).
This all works fine, and a preview window is opened and images displayed. When I call ICubeSDK_Stop the preview window is closed.
However, I would prefer to set the CLFN to 'Run in any thread' because
a) when run in the UI thread the preview window randomly gets sent to the back when I switch focus between open VI windows (presumably because it is in the same thread as the VIs)
b) I don't want to put unnecessary stuff in the UI thread
c) my (naive?) understanding is that it is safer to run in any thread
So I have set all CLFNs to 'Run in any thread'
When I do this the preview window opens OK, and behaves like any other non LabVIEW controlled window in terms of focus. But when I call ICubeSDK_Stop() the preview window does not get closed properly, it just shows a blank image. I can't close it manually, there is no X in the corner and no option to close it from the taskbar. To get rid of it I have to close the LabVIEW project it is spawned from, which often results in a crash. It does appear as a separate item in task manager but if I 'end process' it, LabVIEW closes (and often crashes) as well.
If I change only the CLFNs that call the Start and Stop functions back to 'Run in the UI thread' then it all works fine again, except that the preview window gets sent to the back randomly as before.
So, what do I have to do to get the preview window to close properly if I set the CLFN to 'Run in any thread'.
Alternatively, is there a way to close the window programmatically (ie force it to close) after I have called ICube_Stop.
Thanks
DAve

Hi Dave,
The "Run In UI Thread" switches from the thread the VIs currently executing in to the user interface thread. If you select "Run in Any Thread", the Call Library Function Node continues in the currently executing thread. By default, all Call Library Function Nodes run in the User Interface thread.
Before you configure the Call Library Function Node to run in any thread, you have to make sure that the code is thread safe. Code is thread safe when it does not store any global data (e.g. global variables, files on disks, etc.), does not access any hardware, does not make calls to any functions, libraries or drivers that are not thread safe.
Unfortunately, since you said that your DLL accesses hardware, it is not recommended to use "Run in Any Thread." This is probably why you are seeing the crash.
If your preview window gets sent to the back you can programmatically bring it forward. Here is an example of how this can be done: http://decibel.ni.com/content/docs/DOC-4551
If you want to completely close the window down you can do so as described in this link: http://digital.ni.com/public.nsf/allkb/81E9C1441900FFCE8625748F0055DBB0?OpenDocument
I also thought you might find this useful: http://zone.ni.com/devzone/cda/tut/p/id/3009
I hope this helps.
Regards,
Mahdieh G
Applications Engineer
National Instruments UK&Ireland

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

When i open my i3tunes on my computer i get an error message telling me that iTunes has stopped working..the message is as follows...Microsoft Visual C runtime library Program C:\program files (86) iTunes\iTunes.exe R6025 -Pure virtual function call..

when i open my i3tunes on my computer i get an error message telling me that iTunes has stopped working..the message is as follows...Microsoft Visual C runtime library Program C:\program files (86) iTunes\iTunes.exe R6025 -Pure virtual function call.. How do i fix this

For general advice see Troubleshooting issues with iTunes for Windows updates.
The steps in the second box are a guide to removing everything related to iTunes and then rebuilding it which is often a good starting point unless the symptoms indicate a more specific approach. Review the other boxes and the list of support documents further down page in case one of them applies.
Your library should be unaffected by these steps but there is backup and recovery advice elsewhere in the user tip.
tt2

Advantages of Solaris 10 library function calls over Solaris 8 calls.

Similar Messages

Maybe you are looking for