DLL calling problem

Problem:
From a LabVIEW VI I am calling a DLL (not developed in LabVIEW) that calls a new DLL developed in LabVIEW.
When I do this LV hangs (CPU Usage = 100%). Why?
I can call the LabVIEW-DLL direct from my VI without any problems...
/Daniel

Dear kopisti,
Rearding we talked over phone about this problem, let me share the current state in nutshell also on this forum:
The dll you use doesn't contain the prototype of the functions. Like: int func(int a, int b ...) So we don't know any parameters about how to call those 4 functions: CallAT(), EntryPoint(), DllInit(), DllFree()
Since the TestStand is a very flexible environment, you can provide this prototypes manually by adding those parameters in dll module.
If you could reach somehow the documentation of the Dll, it's very strait forward to do it, and any case we can provide you help. Maybe you can also ask for support by the developer company of the Dll, or the developer of the old test-program which called this dll.
We also mentioned that this Dll is possibly an interface to reach a ActiveX/COM Server. By-passing this dll you can also use ActiveX/COM TestStand module to call directly the ActiveX functionality.
Feel free to contact us in any progress or questions on this topic, and/or share with public here in the forum your knowledge.
Best Regards:
Tamas Szekely
Applications Engineer Hungary - National Instruments

Similar Messages

I am using a Application in c dll calling from jni jar by java applet in firefox version 19.0 , the problem is click event message box will not working correct

I am using a Application in c dll calling from jni jar by java applet in firefox version 19.0 , the problem is button click event message box or popup window will not working correctly. Please any one suggest me the steps to overcome this not responding or slowness in the responding problem of Button click event.

Hello,
In Firefox 23, as part of an effort to simplify the Firefox options set and protect users from unintentially damaging their Firefox, the option to disable JavaScript was removed from the Firefox Options window.
However, the option to disable JavaScript was not removed from Firefox entirely. You can still access it from about:config or by installing an add-on.
'''about:config'''
# In the address bar, type "about:config" (with no quotes), and press Enter.
# Click "I'll be careful, I promise"
# In the search bar, search for "javascript.enabled" (with no quotes).
# Right click the result named "javascript.enabled" and click "Toggle". JavaScript is now disabled.
To Re-enable JavaScript, repeat these steps.
'''Add-ons'''
You can alternatively install an add-on that lets you disable JavaScript, such as
*[https://addons.mozilla.org/firefox/addon/noscript/ No-Script] (to disable JavaScript on a per page basis, as required)
*[https://addons.mozilla.org/firefox/addon/quickjava/ QuickJava] (to easily disable and enable JavaScript, automatic loading of images, and other content)
Thank you and I hope this helps!

How is it possible to make sure that LV uses the same thread for several threadsafe DLL calls?

Hello,
i have a thread safe DLL and most functions are called from serveral threads from the LV apllication without problems.
In case of an error i have to call an error handler function in this DLL (like WinAPI: GetLastError()) from the same thread which has called the function that failed before.
I can't use the user interface execution because some functions need a long execution time and i don't want to balk the user interface.
All other executions than the user interface execution have more than one thread and in most cases the DLL function calls were executed from different threads - so the error handling doesn't work...
Any idea?
Thanks for your help!

Hmmm....
How about wrapping all of your dll calls in a single VI (or an Action Engine ) and make sure the VI's thread is NOT set for "Same as caller".
"Threadconfig.vi" (sp?) will also let you dictate the number of threads associated with an execution system. Set your target thread for "1".
Not sure on the above.
Please correct me if this is wrong!
Ben
Message Edited by Ben on 07-19-2007 08:26 AM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Private dll calling in Labview

Hi everyone, (refinement of my question)
I have two dlls. One contains public functions which I call from Labview. The functions in this dll call functions in the other (private) dll. However, how do I tell Labview where to find this private dll?
I have tried installing the dll in the system path directory. I have also put the dll in various different places relevant to Labview (e.g. in the directory of the Labview executable file). However, none seem to work (.
Is there an option in Labview where I can set paths to dlls?
Any help will be gratefully received.
Ciao,
Matthew Banham (colleague of Francois)

> I have two dlls. One contains public functions which I call from
> Labview. The functions in this dll call functions in the other
> (private) dll. However, how do I tell Labview where to find this
> private dll?
>
> Is there an option in Labview where I can set paths to dlls?
>
The problem is that the system loader is what handles the dependent
DLLs. Since LV knows about the primary DLL, we try multiple locations,
the path in the dialog, next to the VI, in the LV search paths, and
finally we ask the system to look in their places. LV doesn't know
about the dependent DLL, and it is up to the system to find it. I'd
recommend trying the system or windows folder again. That should be the
right solution.
An off the wall thought that might h
elp would be to add a dependency
directly into LV by making a DLL node that calls in the the "private"
DLL. You don't actually have to call it, you can place it in a case
structure with a constant set the other way. Anyway, this will cause LV
to look for the DLL, and I think it might help if nothing else works.
Greg McKaskle

RT startup application with C code DLLs deployment problem

Hi!
I work with LV 8.2 at host PC and LV RT 8.2 at PXI RT 8186 controller.
I have made VI which uses some C code from one of my DLLs. For making DLL I used CVI. My VI with DLL is working good when deployed on RT directly from developer interface. So I wanted to make startup apllication out of that VI. I used build application tool (Build Specifications) at Project Manager.
Target destination directory for startup application was set as c:\ni-rt\startup. Looking at Generate Preview before engaging build, startup.rtexe was listed to go at c:\ni-rt\startup folder and DLL was automaticaly added through include if referenced option into c:\ni-rt\startup\data folder.
There where no build errors and startup.rtexe was sucessfully built and saved at my procject's destination folder at my host PC. After that I tryed deploying that application at my RT target and I would get : Failled to deploy error.
When I look at c:\ni-rt\startup   folder on rt target, after failed deployment, I can see application files copied (strartup.rt exe to:\ni-rt\startup, and DLL to :\ni-rt\startup\data), and also in ni-rt.ini file I can see expected changes. But when I start my PXI with that startup application it doesn't seem to work at all.
After making several different builds using different destination and support directory options for my VIs, and differently placed checkmarks under Advanced Build Application project properties, got the same result. Every build was good, but deployment failed.
So after that, I removed DLL calls from my VI and tryed to build startup application, and got good build exe and sucsessfull deployment on RT target and application worked good.
So to summarize it:
                            - I have VI with some C code used throgh DLL calls using Call Library Functon Node
                            - Path off DLL in that Call Library Function Node is absolute (exe: D:\monitoring\communication\myTCP.dll) at my host PC
                            - DLL is used for establishing TCP/IP communication and it is made with CVI compiler and CVI libraries
                            -I get built application without any error
                            -build automatically includes depending DLL
                            -when running startup application with DLL it doesnt seem to work good (I tryed including some write file VIs to it and it didnt write anything)
                            -when building and running startup applications without DLL calls everything works OK
Is there anything else I have to include in my build besides the dll that I am using in my VI? Has anybody have any idea how to deal with this problem?

Hi Mike,
When you build a CVI DLL for real-time (i.e. you selected the Real-time only option for Run-time support in the Target Settings dialog), that DLL is statically linked to cvi_lvrt.dll located in the windows\system32 directory. This means that your DLL plus this DLL must be present on the RT target for your application to run. To get the cvi_lvrt.dll to the RT target, you can add it as a support file in your RT application. This will install the cvi_lvrt.dll to the ni-rt\startup\data directory and allow your application to load and run.
Hope this helps!
Best Regards,
Jonathan N.
National Instruments

Error Code 1097 Coming in DLL Calling

Hi,
I am getting error code 1097 in DLL calling function. Please find the DLL calling function details for more information.
Function : GetControllerListTest(controller *ptrControllertest,char *max_controller);
Controllertest parameter details:
define NO_OF_CONTROLLER  100
#ifndef CONTROLLER_STRUCT
typedef struct
  CString name;
  char status;
  CString blocked_by;
  char group;
}controller;
Controllertest parameter data type is structure. In LabVIEW, I have configured parameter as a cluster.
name : String control
status : U8 Integer control
blocked_by : String control
group : U8 Integer control
Could you please confirm it, did I configured the datatype in correct way?
I am getting empty array output and Error Code from the DLL 1097. Can you please tell me where I am missing?
Thanks
Sivaramkumar.V
Solved!
Go to Solution.

Call Library Node problems without the VI in question attached AND the complete C prototype of the function provided, AND preferably some documentation about the C function in question can be not diagnosed. These informations are paramount to get the Call Library Node configured properly since there is no way a calling application can retrieve the necessary information from the DLL itself. The DLL interface was never intended to be a self configuring interface and it was designed with the understanding, that the user of such an interface is a fully knowledgeable C programmer knowing both, how to read a header file definition as well as various details about memory buffer handling.
So show us your VI and the C header file, and we can start to help you. Otherwise all we can do is guessing in the way you have done with changing the calling convention randomly. You can of course try to shoot in the shooting range with a blindfold on, but the chances that you not only do not hit the target, but injure some other person instead is very high.
The only reason that the suggestion from Fragger Fox has any merits is the fact that LabVIEW used to have some heuristics that changed the Call Library Node automatically from C calling convention (the LabVIEW default) to Windows calling convention, if it recognized a certain pattern in the exported function name. This heuristic was removed in LabVIEW 2009 because it did prevent the Call Library Node to be able to call functions that were using C calling convention but happened to match the heuristic pattern. So changing a Windows calling convention to C calling convention when the code has "seemed" to work before is NEVER a solution.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to response polling event during dll call

Hello,
There is a long time dll call in my program. The program doesn't response to mouse click in the front panel during the dll call when I want to display other page in Tab control. It only response after the call.
How to solve the problem?
Thanks!

Wether or not it is possible to fix this situation is dependent on the dll itself.
IF
the dll is written to be re-entrant (thread-safe)
THEN
you can configure the Call Library function to not run in the user interface thread. This can be done by right-clicking on the node and selecting "configure". In the configure screen, ther is a drop down selection box that defaults to "Run in UI thread". Change this to re-entrant.
You can then determine which thread the dll runs in by setting the properties of the calling VI.
Warning!
If the dll is not re-entrant you WILL experience random crashes and possible data coruption! All bets are of if the dll is used in the wrong manner.
What is happening:
LV's execution systems are multi-thread with the exception
of the UI thread. The UI thread is single threaded to ensure updates of control and indicator information is updated correctly, etc. This thread also uses co-operative multi-tasking wherein a proccess is expected to "put itself to sleep" regularly in order to allow other proccesses in that thread to gain access to the CPU. Your dll is dominating this thread and prevent user actions to be serviced!
Final note;
If you do not know if the dll is thread-safe and decide you just want to experiment,
BACKUP YOUR ENTIRE MACHINE!
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

RoboHelp for Word Version 8-Run-time error 49-Bad DLL calling convention

I just installed the trial version of RH8. I have RH5 installed. I also have Word97 installed. When I start RH8, the RH Explorer pane opens, but when it tries to open Word, the following error message appears: "Microsoft Visual Basic - Run-time error '49'. Bad DLL calling convention." Any ideas on what I can do to fix this problem?

See Snippets on my site.
See www.grainge.org for RoboHelp and Authoring tips
Follow me @petergrainge

Labview 5.1 vs. 5.0 and dll calls

Hello!
I have Analogic cPCI-14-2 DAQ cards in the PXI box. Their driver is a dll
for which I wrote LabView interface using LV5.01 . Everything was nice
until I switched to 5.1, now it is impossible to run the program for more
than 5min without a memory access violation error and subsequent LV crash.
I compiled executable from the DAQ module under 5.01 and 5.1. Executable
made under 5.1 would not even execute once, resulting in the crash. Then I
saved VI's using save as LV5.0 option, compiled executable under LV5.01 and
that runs without problems. I ended up using ActiveX server capabilities of
the executable by calling it from my main program written using LV5.1
because I needed to call Matlab. ActiveX server is actu
ally nice because of
DCOM in NT boxes, I can now run everything from my office super-duper
machine instead of using a PXI box's Pentium233.
Question is, has anyone else had problems with dll calls and how were they
solved ?
I will appreciate your suggestions.
Sincerely
Reinis Kanders

Mass compiled in 8.2.1
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Attachments:
Keithly 8_2.zip ‏1231 KB

Bad DLL Calling Convention

Hi,
I've created a dll with LV8.6 and I'm trying to call it from VB6.0. I get the message 'Bad Dll Calling Convention. Run Time Error '49'.
Questions:
1. Any idea what might cause this error?
2. What is the meanig of the second function appear inh the h file ( long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module)
Thanks very much for your help
Rafi
The dll definition as appear in the h file:
     void __stdcall EDASAnalysis(double f_sampleMHz, char FilePathFromOut[],
         double *RMSValue, double *AmplitudePP);
     long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);
The Decleration in Visual Basic 6.0:
     Declare Sub EDASAnalysis Lib "D:\NI Projects\eDAS400\DLL\ LV-DLL_V2\DLL\eDAS400_Analysis.dll" _
            (ByVal f_sampleMHz As Long, ByVal FilePath As String, RMSValue As Long, AmplitudePP As Long)
Using the Function in VB6.0:
    Call EDASAnalysis(10, "D:\NI Projects\eDAS400\Data Files\Samples\10MHz.txt", rms, pp)

Rafi2003 wrote:
Hi,
I've created a dll with LV8.6 and I'm trying to call it from VB6.0. I get the message 'Bad Dll Calling Convention. Run Time Error '49'.
Questions:
1. Any idea what might cause this error?
2. What is the meanig of the second function appear inh the h file ( long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module)
Thanks very much for your help
Rafi
The dll definition as appear in the h file:
     void __stdcall EDASAnalysis(double f_sampleMHz, char FilePathFromOut[],
         double *RMSValue, double *AmplitudePP);
     long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);
The Decleration in Visual Basic 6.0:
     Declare Sub EDASAnalysis Lib "D:\NI Projects\eDAS400\DLL\ LV-DLL_V2\DLL\eDAS400_Analysis.dll" _
            (ByVal f_sampleMHz As Long, ByVal FilePath As String, RMSValue As Long, AmplitudePP As Long)
Using the Function in VB6.0:
    Call EDASAnalysis(10, "D:\NI Projects\eDAS400\Data Files\Samples\10MHz.txt", rms, pp)
muks already pointed you to a discussion that shows the problem. VB can not call cdecl exported functions, so when you create your DLL you'll have to tell LabVIEW to use the stdcall calling convention to export the function for VB.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Trying to get dll calls to work like c++

Hi,
I understand there have been many posts about dll files. I have reviewed them and found nothing that helps me. I have a segment of c++ code that communicates with a digital correlator, reading data from it. The c++ code works fine, but when I wrote the code in Labview, I get results that are reasonable sometimes....sometimes I get good data, sometimes odd data, and sometimes no data. The c++ code ALWAYS yields good data. The function prototypes in each of the call library functions matches that in the c++ code.
The C++ code is attached.
NOTE THAT there are a few things (like calculating delay times and writing to file I don't do in the labview code).
The labview code never outputs any values in TraceA or TraceB, which should be values around 300,000. The DLL location is set correctly, as evidenced by the fact that the code works....just not consistently.
Any help would be greatly appreciated.
Josh
Attachments:
Correlator.vi ‏38 KB
sample.cpp ‏6 KB

Your message is very clear!
I have no idea how the fact that this particular code was made to work would help you unless you try to use the same DLL which would seem rather strange. As to what the OP posters problem was:
One has to provide buffers to DLL functions for ALL parameters when one calls them. Yes LabVIEW does take care about buffer allocations everywhere else so you don't have to worry about that, but when calling C code, LabVIEW can't even guess what buffers the function may need. And therefore it correctly doesn't try to guess at all.
Those arrays that the function should write into, have to be allocated BEFORE one calls the function. It's the single most problem why DLL calls don't work as expected either returning rubbish or crashing. And anyone claiming to have read all the posts about DLL calling on this board or also on lavag.org should have gotten across at least two dozen messages from me where I pointed that out and explained it in detail.
in detail: The graph arrays do get initialized but in the same frame all control get initialized to default. That is completely wrong! one does either one or the other but not both and definitly not in the same frame because of uncertainety which is executed first.
nTrace is initialized to 0 and then used as indication in the CallLibrary Node, how large the array needs to be. Well a 0 element array is just that an array of no content, therefore a buffer that can hold no information and therefore it's sheer unluck that the Call Library Node doesn't crash.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How do I create a fault-tolerant DLL call from LV?

I've created an .exe from a VI that calls a DLL, when that DLL crashes,
it crashes the whole application. This DLL is too complicated to
completely debug and it, in turn calls DLLs I have no control
over. It crashes approximately once every 100,000 iterations.
How do I make a DLL call fault-tolerent?
Attachments:
crash.gif ‏19 KB

I might not have been very clear in my answer - this isn't a feature that CAN be added to LabVIEW...the DLL threw an unhandled exception across a DLL interface - which pretty much means a system exception (code shouldn't be throwing language exceptions across DLL boundaries as they are language specific). This means that something went very wrong with the code and there is a good chance that the process space has been corrupted. And from my own debugging experience, if it's only crashing 1 time out of 100,000, that doesn't mean it isn't corrupting memory or otherwise causing problems...it was just the time it was caught.
Considering this, the Call Library Node already is fault tolerant - we catch the exception and report it to the user. You have a valid position that we should simply return this as an error. It's also a valid position that it would be a road paved with good intentions. All you need to do is remember what life was like in Windows 3.1 - where one process could silently corrupt another - to realize the amount of untraceable errors that could occur. Yes, the error out value should be handled by the user, but when an application of 100's or 1000's of VIs crashes seemingly at random because someone didn't, you can see the problem.
I will say I like the idea of a separate memory space. It is unfortunate that Windows only offers that through creating a separate process, but it is a neat idea. I worked in the VXI/VME world for a while, which does have multiple address spaces.
BTW - using signal handlers to catch exceptions is unfortunately not a 100% solution...signals are a partial port of a Unix concept in Windows. You would be best to use SEH around the call (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/key_s-z_4.asp). If the DLL is already a C++ DLL, then you can use the global catch of C++ instead
int err = 0;
try {
} catch(...) {
err = -1;
Again, you still are at risk of a corrupted process, but this allows you to avoid our handling of it.
Having spent years writing and (god help me) debugging device drivers, I love this topic. If you want to talk more about it and various options, feel free to shoot me an email at [email protected].
Brian Tyler
http://detritus.blogs.com/lycangeek

I am an iphone4 user from United Arab Emirates with home button/MIC not working during call problems..

hi, i am an iphone4 user from the United Arab Emirates. I got my phone as a gift last September and it was not bundled with any carriers and was a factory unlocked piece. Within one month of usage the home button started misfunctioning. It started registering double clicks as single, triple clicks, etc. (the usual complaint of many countless users of iphone from the time of the release.) I then kind of ignored this problem and continued using the phone.
With this problem still continuing, comes another one.
My friend gave me a call yesterday, and we were talking happily for a minute or so and suddenly without any reason my friend failed to hear me. Five minutes was spent trying to make myself heard to him. I tried and i tried and the only solution i could find was tapping the phone gently,but firmly. Then he was able to hear me but then after sometime it was back to the same problem.
The only solution i found was to tap in th sides.(please note that this is also a common problem with many who have call problems but no voice memo problems.) I tried adding and registering my device to my account but when i try to put in my iphone's serial number,they say that the device number is invalid.
Now i want to get a solution to this, but since this was a gift piece i do not have any invoice of any sort. I even checked itunes.com/support and was happy to find i still have warranty till september.
I am confused as to what to do as I was dissappointed to find even a single apple store in the UAE and do not know what do we get in terms of support. Could someone please help me?

that is exactly the problem. I have no idea as in where this phone originates from. It was gifted to my Dad from a personnel who he was supplying for in the company. My dad then gifted it to me on my birthday. I asked my dad about the phone but he also does not know a thing. He also said that the other guy must have taken the invoice with him as he did not give anything to my dad.
I checked it in quite a few places (like SharafDG,eMax,Axiom etc., the local electronics suppliers) to track where this phone was originally purchased from( because these people usually take down the IMEI's of the electronic devices they sell), but they all could not help me.
Now i have no idea what to do and i do not want to spend huge amounts of cash for this matter as i am already in the warranty period. Anyways,thanks for your help in advance, but it would be helpful if you could try to get this solved for me.

Configuring array of byte in dll call

Dear all,
I need to send the data 2010010100H to the dll at the question mark(U8) i mentioned in the attachment. Actually the data has to be transferred at a time not in bits and pieces. How to do this? I just put an array constant. Is it correct? Kindly give suggestions asap.
Thanks,
Mathan
Attachments:
1.PNG ‏10 KB

Hi mathan,
the dll call in your pic only accepts single bytes (U8) - so no way to wire an array!
why do you create so many new threads, when the topic doesn't change?
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Failure: "gnrclist.cpp" after a DLL call

Forum:
Since adding dll calls in a VI, LabVIEW is frequently crashing, both during VI execution and after exiting the application.
Generally, what issues need to be considered when making successful dll calls (using the "call library function").
Jordan

Hi Jordan,
It sounds like this issue is due to the fact that you are not allocating memory for the dll in advance. This is the most common mistake when implementing a dll in LabVIEW.
For instance, if your dll is going to output an array of 100 double-precision numbers, then you need to allocate this place in memory by passing the dll a dummy array of 100 double-precision numbers that it can operate on. Also be careful not to expand the size of the array. LabVIEW doesn't support dynamic memory allocation within a dll in most circumstances. If you don't allocate a place in memory in advance, LabVIEW may crash when you exit the program and LabVIEW tries to deallocate memory.
A really good example of allocating various types of data for use in a dll is available from the Example Finder (Help >> Find Examples from LabVIEW). Click the Search tab and search for the term DLL. The Example is called Call DLLs. It contains c code that corresponds to various dll functions that operate on various data types, and it shows you how to call these dll functions properly from LabVIEW. For a more comprehensize overview of the process, refer to the document Using External Code in LabVIEW, available here, or browse through these Developer Zone examples and applications notes.
Jarrod S.
National Instruments

DLL calling problem

Similar Messages

Maybe you are looking for