Trouble when Labview call CVI DLL in after compiled to EXE

Hi,
I m developing a program by LabVIEW, and have to call a DLL, which developed by using CVI.
The UI of the DLL consist of a table and a listbox.
The DLL run smoothly but when I compiled the project to EXE, when the program call the DLL, the DLL won't show properly.
The DLL UI only show the table, and the listbox has "disappeared".
Any common known-problem caused it ? Please advise. Thanks a lot.

Hi Engwei,
I'm not familiar with any such issue. Would it be possible for you to post the corresponding CVI and LabVIEW codes and the built DLL and executable? I would like to investigate this issue further. Also, what version of CVI and LabVIEW are you using?
Thanks!
Joshua de la Llana
NI Applications Engineer

Similar Messages

Do I need Developer studio (C++ programming language) in my computer when I call a dll through my labview?

Thanks in advance...
Solved!
Go to Solution.

yemin wrote:
   Thank you Rolf and smercurio_fc
   My C++ code has many inputs and I am going to get different results ( pressure-temp-friction etc). I am looking at call library function and I couldnt add more than one "return type" . Do I need to name parameters like return type 1, 2, 3 etc... Do you have an idea, how can i get more than one return result?
A C function can have only one return value. This is a C limitation, not a LabVIEW limitation. What's sometimes done in this case is to have these additional values "returned" as function arguments. You pass in a pointer to a value of the appropriate data type, and the function will write the new value to that memory location. If you don't know what that means, then I'd suggest spending some time with C tutorials.
   Also, when i run my c++ code, I can get all results in a notepad file.... In labview when I run the dll, how can i create that kind of file in the computer to store my run's result?
As noted, you can use Write to Text File. Or, you can use Write Spreadsheet File to create a delimited text file that can be easily imported into a spreadsheet application such as Excel. Or, you can use the Write to Measurement File VI if you want extra formatting at the beginning.
   Thank you again, I am very beginner at Labview.....
We were all beginners at one point. To learn more about LabVIEW it is recommended that you go through the introduction material, tutorial(s), and other material in the NI Developer Zone's Learning Center which provides links to other materials and other tutorials. You can also take the online courses for free.

Error transact.cpp when load LabWindows CVI DLL

Hie,
I'm a "newbie" about LabView, and I would like to call a simple LabWindows CVI DLL from LabView. Then for this
I did also a very simple VI (I think : 2 buttons, the first to call my DLL function and the second to quit
my VI). I define my DLL as indicated by NI, all seems OK. After placing and defining parameters about my
DLL function in the diagram, If I "double clic" on the DLL icon in my diagrram, I obtain :
"Failure Transact.cpp, line 1132 ...blabla...blabla".
Another Time, I obtained a message (when I try to run) about
"not enough memory"
the solution is then to kill LabView Process or shunt Down !!!!!
I've tried my "mini" projet on tow systems and I obtained the same results :
Wind
ows 2000 and Windows NT
LabView 6.0 et Lab Windows CVI 6.0
144 Ram and 256 Ram in the two PC and not another application running during my test :
I think then I should have enough ram to do this !
I did not see my problem
thank a lot in advance for any help
file attachement contain hardcopy of VI
Thierry
Attachments:
Bug_Memory_LabView.doc ‏56 KB

Hie,
Now It's OK !!
After submitting my problem to NI, NI has transmitted to me a simple program :
a VI which simply calls a function in a DLL (which loads an UIR), and their solution runs.
Their solution is the "same" as mine except in mine, I have added calls to "MessagePopup"
just to study how running my program like this (see "// Here ->x" ) :
Extract of my code in my DLL :
int __stdcall DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
int iValue=0;
switch (fdwReason)
case DLL_PROCESS_ATTACH:
"// Here ->1" MessagePopup ("Avertissement", "DLL -> Init Ressources DLL LabWindows");
if (InitCVIRTE (hinstDLL, 0, 0) == 0)
return 0; /* out of memory */
break;
case DLL_PROCESS_DETACH:
"// Here ->2" MessagePopup ("Avertissement", "DLL -> Free Ressources DLL LabWindows");
if (!CVIRTEHasBeenDetached())
CloseCVIRTE ();
break;
The problem is located to the line "// Here ->"
When I drag the icon "Call Librairie function" in the diagram of my VI and I define parameters,
immediately a "link" is established between LabView and the DLL, the __stdcall DllMain is called !
then LabView Environnement failed !, you have then to kill the LabView Process !
By changing the "MessagePopup" functions with tracks (*) in a file, I can "debug" my program and I will
have never this artefacts.
change line // Here ->1 with TraceMsg("DLL -> Init Ressources DLL LabWindows");
change line // Here ->2 with TraceMsg("DLL -> Free Ressources DLL LabWindows");
void TraceMsg(char *szBuffer)
int iValue=0;
int iHandle=0;
iHandle = OpenFile("D:\\Thierry\\Formation LabView-LabWindows\\trace.log",
VAL_WRITE_ONLY, VAL_APPEND, VAL_ASCII);
iValue = WriteLine (iHandle, szBuffer,strlen(szBuffer));
iValue =CloseFile (iHandle);
Thierry

Can LabVIEW call a DLL built with VS(2005) C++ with /CLR and Without an Entry Point

My project requires me to convert a C++ program to a DLL and having it called by LabVIEW. Due to the complexity of this C++ program (converted from fortran using f2c -C++ option), it cannot be compiled without using /clr option. I did build the application standalone (/clr), and it functioned fine. When I build it into DLL using VS2005, I was forced to use No Entry point option and without using DllMain in the C++ code. Eventually the DLL was built without error. But after I call it from LabVIEW, I was not getting calculated results as expected. I added a testing function to the C++ code of the DLL and just try to modify a parameter, it will not, but only return the input numbers. I was passing data by pointer and not by value, so I expect this parameter output be modified. I suspect that the DLL didnt get executed at all as it has no entry point specified.
Am I on the right track to approach this task, or I am heading to totally wrong direction here? I believe due to the fact that my C++ was from f2c and use vsf2c.lib and so on, the code is managed code, so that a regular DLL cannot be built from it with an entry point. How can LabVIEW call such a DLL? Am I right on that? I really need your advice here for a right approach to this problem and possible implementation "watch outs"...Thanks!
Bryan

Hi...Finally I was able to compile my code with an entry point defined and without using /clr. I can also call this DLL from LV and got back a variable from a little test function added to the DLL. But the function that was used for my main application in the DLL crashed LV and I got a pop up box from Microsoft Visual C++ Runtime Library: Runtime Error! "This application has requested the Runtime to terminate it in an unusual way, please contact the application's support team for more information". In Visual Studio I also got the following message: (I eliminated most of the "No symbols loaded" messages that are not errors but just info.) I would apprciate if someone can take to look with your more "experienced eyes", many thanks! Bryan.
'LabVIEW.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\Shared\nicont.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\Shared\NICONTDT.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\nitaglv.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\lkbrow.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\lkrealt.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvdaq.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvdesktop.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvfp.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\mfc71.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\MFC71ENU.DLL', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\vi.lib\FieldPoint\SubVIs\FPLVMgr.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\lvfprt.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LvProjectProxy.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LvRealTimeCoreProvider.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\MVEProvider.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtCore4.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtXml4.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\QtGui4.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\mxLvProvider.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\nimxlcpp.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\nimxlc.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\variable.mxx', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\lvMax.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\MAX\UI Providers\FieldPoint71.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\MathScriptParser.dll', Binary was not built with debug information.
'LabVIEW.exe': Loaded 'Z:\bli\development\projects\galfitDLL\Debug\galfitDLL.dll', Symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\Program Files\National Instruments\LabVIEW 8.5\resource\mesa.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\mscms.dll', No symbols loaded.
'LabVIEW.exe': Loaded 'C:\WINDOWS\system32\icm32.dll', No symbols loaded.
The thread 'Win32 Thread' (0xf94) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x90c) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xfd0) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x284) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xdac) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xa98) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x528) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x614) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xa5c) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xebc) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x5cc) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x700) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xcf0) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xc7c) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x4c8) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0xa4) has exited with code 3 (0x3).
The thread 'Win32 Thread' (0x52c) has exited with code 3 (0x3).
The program '[804] LabVIEW.exe: Native' has exited with code 3 (0x3).

The LV crashed when I call a dll to control my com port

I am controlling the com port with calling a dll(dwdio.dll--see the attachment). The VI I used is also attached below.
I just used four functions of this dwdio.dll, as followings:
1. bool DWD_set_comport(unsigned char com_port,int *handle)
Parameter config:return type--unsigned 8-bit int(value),com_port --unsigned 8-bit int(value),handle--signed 32-bit int(point to value)
bool DWD_set_baud_rate(int baud,int *handle)
Parameter config:return type--unsigned 8-bit int(value),baud--signed 32-bit int(value),handle--signed 32-bit int(value)
bool DWD_check_comm_link(int *handle)
Parameter config:return type--unsigned 8-bit int(value),handle--signed 32-bit int(value)
bool DWD_close_com_port(int *handle)
Parameter config:return type--unsigned 8-bit int(value),handle--signed 32-bit int(value)
I can run my vi successfully,but Labview will crashed when I close Labview application. I tried many ways to change the parameters and convention, but there is no effect.
Because this dll file need hardware dongle,so I can't upload the vi. I just attached the screen-shot of it.
Can anybody have some analysis on my vi to give me some valuable suggestion?
Attachments:
dwdio & explanation &my vi.zip ‏2456 KB

Yaoming wrote:
> SVences, I know that Erroneous data types assignments can cause crashes.
> I have checked all the data type with my experience and knowledge,but I didn't
> find anything should cause this crash problem. After all,I am not very
> experienced in Call Library Function, so maybe my vi still have some erroneous
> data type assignments. Can any DLL expert help me to locate them?
> For the original function description, I have posted as attachment in the first
> post. Therefore,anybody who want to check my data type error can have a check
> with that function description.
> That issue is very urgent and important to me. Can anybody to help me sort
> this problem as soon as possible? Thanks in advance.
A few remarks:
1) the Bool return value is probably an int. It doesn't look like a
standard Widnows datatype so you will have to look in the documentation.
However this is unlikely to crash your code.
2) The handle parameter for DWD_set_comport should be set as Pass:
Pointer to Value. All other parameters should be passed by Value only as
they are not pointers at all. Also please wire a 0 constant to the right
side of the CLN for that parameter to provide memory for the DLL to
write in.
3) The calling convention for the DLL functions is not obvious from your
documentation. You have the choice between C (cdecl) and WINAPI
(stdcall) on Windows. Since this DLL seems to be available for multiple
platforms (The remark for each function) it may be that the developer
decided to use cdecl calling convention (a smart choice I would say) but
Windows DLLs usually use stdcall instead.
Having the wrong one will absolutely crash LabVIEW but usually at the
moment you return from the functioncall and not later on.
So I would guess the most probable cause is number 2, but don't discount
the other ones completely.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Intermittent problem with TestStand calling CVI DLL calling MSCV DLL

Sorry about cross post, but I am not sure which group is best to address
this issue.
Setup:
Windows 2000 SP1
TestStand 2.01f
CVI 6.0
MSVC++ 6.0 SP5
Problem:
I have a CVI Test Library DLL that contains test functions called by
TestStand using the C/CVI adapter. The CVI Test Library DLL in turn makes
several calls to another DLL written in MSVC++. I am experiencing an
intermittent problem with one of the MSVC functions. The problem ~appears~
to be stack related, but I am not sure. Among other things, this MSVC
function accepts a const char * argument that is a TestStand lookup string.
The function uses this string to access the TestStand API.
What happens is this: Everything works fine. I then recompile the CVI DLL
after making some mod, then run. The MSVC++ DLL asserts that the const char
* arg passed by the CVI DLL is NULL. However, this is not the case if I
single step through the CVI code. It has happened both with passing
variables as the const char * argument and as hardcoded strings literals, so
its not that I am actually passing NULL. The other argument to this
function is the TestStand sequence context dispatch pointer (LPDISPATCH
pobjSequenceContextDisp) and it always ~appears~ to be passed correctly.
The problem is frustrating and hard to debug because I can not
deterministically reproduce it. The problem ~never~ appears when I debug my
MSVC++ DLL in Visual Studio. And it only occasionally appears otherwise.
The problem, when it appears, always appears on the first run after
recompiling the CVI DLL, though the problem does not happen after ~every~
recompilation. I'd say it happens 1 in 6 times after a recompile.
Recompiling the exact same code does not always make the problem disappear.
If I change the CVI code (code that has nothing to do with the argument
itself though) and recompile the problem almost always goes away. Selecting
'Mark all for compilation' and rebuilding does not make the problem go away.
Only tweaking the CVI code and recompiling does (usually).
Whats more, the problem appears:
* With the CVI DLL built as Debug or Release mode.
* With the CVI default calling convention set to __stdcall or __cdecl.
* With the C/CVI TestStand adapter set to run in-process or external
instance of CVI.
The problem appears to be some sort of stack or argument passing problem
between CVI and MSVC, though thats just a guess based on the symptoms. I
have quadruple checked the calling conventions of all declared functions.
The CVI DLL functions all use TX_TEST (which resolves to __cdecl). The MSVC
DLL functions all explicitly use __stdcall. Is there a problem with calling
__stdcall MSVC functions from a __cdecl CVI function?
I can find no other memory leaks or indications of memory corruption
elsewhere in either the CVI or MSVC DLLs. Its only this one function that
exhibits this strange 'null const char *' problem.
Can anyone offer any ideas about what may be causing this problem? Anything
else I should check/verify?
Regards,
Joe

Silvius,
> Although I'm not sure if any of the following are the real cause of
> your problem, I have the following suggestions:
Thanks for the reply. At this point any and all suggestions are welcome...
> 1. There could be a problem with calling
> __stdcall MSVC functions from a __cdecl CVI function. As a workaround
> wrap the _cdecl call inside a _stdcall call that is exposed or
> exported to TestStand or vice-versa. This can be a problem because if
> _cdecl is used, the calling function is responsible for cleaning up
> the stack and if _stdcall is used, the called function is responsible
> for cleaning up the stack.
I was under the impression that as long as everything was explicitly and
consistently declared, you could safely mix cdecl and stdcall f
unction
calls. Is it bad to do this? Is this a known issue with the CVI compiler?
I've never seen a problem with doing this under MSVC++.
I'll try wrapping them in cdecl calls for CVI - though we have a
depressingly large number of stdcall functions in the MSVC DLL ;-). They
need to remain stdcall in the DLL because we also call them from Visual
Basic.
> 2.Don't mix Debug version of one DLL with the Release version of the
> other DLL. I had some bad experiences doing this and both DLLs where
> developed in MSVC. Allways use either Debug either Release versions of
> DLLs.
I verified that the MSVC DLLs were either ALL Debug or Release. I too have
seen nasty problems when MSVC Debug and Release is mixed.
One thing I had not thought of until your reply: What about mixing CVI Debug
DLLs with MSVC Release DLLs? Have you ever seen issues with doing this?
Thanks!
Joe

Calling CVI DLL Function from Visual Studio

HI all ,
Iv'e created a DLL using CVI and i'm tring to call one of it's function from visual studio 6.0
I'm getting a general error , is there a specific prototype that i need to set my functions in ordrer to call them ?!
Kobi Kalif
Software Engineer

You will need to distribute the CVI RTE along with your DLL, since anything you write in CVI is going to use the RTE.
As far as calling the DLL functions, you can use the CVI defined macros
<return type> DLLEXPORT DLLSTDCALL <function name> (<param1 type> <param1> ...) {
to declare your functions in the DLL for access by a VS application.
for example
int DLLEXPORT DLLSTDCALL myfunction (int funparam1, double func param2) {
There are options for identifying which functions to export from your DLL, I use "functions marked for export" but there are other choices available. I also include a type library so when you type the name of a DLL funciton in VS6 you see a balloon popup with the function signature. This is a check box in the target settings. You have to create a ".fp" file (function panel file) to collect the function info for the library.
From VB6 you can access the DLL a couple of ways, but I usually add the DLL as a reference.

Labview gpib timeout when calling cvi dll

Equipment used :
VXI Rack with Slot 0 controller
Labview V5.0.1
Lab Windows V5.0.1
GPIB controlled Power10 I63 PSU
We run an intermediate Labview driver which communicates with a low level CVI driver (dll) to control a PSU. We recently tried to run the Labview driver on a Slot 0 controller and we get timeout errors when waiting for a response after commanding the PSU to switch off ( "CST OFF" is sent , and the driver waits on "ST OFF" being returned - it never does and times out). Ni Spy is on when it fails. In the same driver, a call to return the Instrument ID is carried out happily, with the ID being returned with no errors.
I can run the low level CVI driver with an interactive script and it works fine with no errors.
I can run the Labview driver with NI Spy switched off and it works ok too, Our customer cannot get it to work even with Ni Spy switched off. They have the same setup as us.
Any ideas?

The solution I had previously documented only partly worked. It cleared the timeout error, but I am still experiencing various errors in testing the PSU with Labview (still no problems with running the functions with Labwindows directly). Also, if NISpy is running I see no errors, which still leads me to believe its a timing problem. I saw another thread on here from someone with similar problems and I tried all the recomendations in that, but it still did not fix it. The last recomendation was to re-write the GPIB driver to slow down the message transfer to the instrument!
A link to the thread with similar problems to mine.....
http://forums.ni.com/ni/board/message?board.id=140&message.id=20031
Message Edited by edinsofty1 on 09-09-2008 07:21 AM
Message Edited by edinsofty1 on 09-09-2008 07:21 AM

How to do with a pointer element in a structrure when I call a dll in labview

struct ZT_USBBOARD
long lIndex;
HANDLE hHandle;
short nCh;
long lData;
long* plData;
long lCode;
FUNCTION：long APIENTRY OpenUSB7kC (ZT_USBBOARD* bs)
---open the device USB7310
the valid input parameter:1Index
There,how to do with 'HANDLE hHandle' and 'long* plData 'in a cluster of labview? DO you understand?
WAITING....Thinks!

Structs can be handled by using Adapt to Type, just build the cluster and wire it in. Pointers can be handled as intergers and passed on.
Did you read Using External Code in LabVIEW? If not, go to Help>>Search the LabVIEW bookshelf.
You can find some more DLL related material here.
Try to take over the world!

How to call Fortran .dll file that using other library files?

Hi,
I am trying to do some arkward tasks using LabView, and I am desperately need help....
A little bit background:
1. My co-worker has some code written in Fortran, where he called other libraries (many from CERNLAB or PAW). Those stuffs are pretty powerful in mathmatical calculation and simulations.
2. In some of my LabView code, I need to call his Fortran source code in order to do some complicated calculations. I have no capablility to translate his Fortran code to Labview (or is it even possible??), so we end up with trying to use "Call library function node" where I just provide input/outputs to communicate with his code. The idea sounds simple enough?
3. We complie the Fortran code into .dll, and then specifiy the dll in "Call library function node". The first try with a very simple Fortran code, something like c = a+b*a, was sucessful. The dll file and Call lib function worked good. It's sort of proved the concept.
4. Now I am trying more complicated Fortran code (say Test.dll), which calling other library (.lib files) that using typical "call xxx(a,b,c)" line, and my nightmare started.... It seems nothing was excuted when I call Test.dll in LabView.
Questions:
1. How do LabView know if the Test.dll code needs functions from other .lib files? Do I need to copy all the .lib files to a specific folder?
2. When I create .dll file, for LabView to be able to use it, are there any special requirement on the way the .dll is compiled?
3. Seems there is mismatch btw the data type in Fortran and LabView. For example, LabView's Signed 8-bit Integer seems different with a integer in Fortran. How can i know the correlation btw data type in different langurage, i.e. LabView vs Fortran?
4. Are there any good examples that I can take a look?
I would highly appreicate any suggestions/helps!
Rgds,
Harry

You are aware that Intel Visual Fortran is the successor to Compaq Visual Fortran (I think you made a mistype with the Virtual)? So an upgrade might be at its place.
Anyhow I'm really not familiar with Fortran at all, but lib files are usually compiled into an EXE or DLL and not loaded dynamically. 1)
So there should be no problem with locating those libs. What most likely is a problem are other DLL dependencies such as any Fortran Runtime library or possibly other third party DLLs the more advanced code in your DLL might be using.
Typically most compilers can be configured to link the runtime library code statically into the DLL, as altenbach reports for the Intel compiler, otherwise you must make sure to install the redistributable Fortran Runtime Library for your compiler. Besides that you must make sure to find out what other runtime dependencies your code might have and install them.
1) One exception I know of is LabWindows CVI which allows to also load lib files dynamically. This is supposedly a legacy feature from LabWindows for DOS, which allowed that feature to simulate dynamic module loading in order to swap modules at runtime to work around the 640k memory limitation of DOS.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Necessary system dll before calling SAPbobsCom.dll

Hi:
I am using an application which allows me to call dll files in a specific folder. Hence, when I call SAPbobsCom.dll, the application needs related dll's supporting SAPbobsCom.dll. Could you tell me whatelse dll's are needed for calling SAPbobsCom.dll?
More detail: A normal application will check dll's registerred in the OS and use them. However, what I am using is not. Hence, I need to know what dll's registered to the OS are required by SAPbobsCom.dll. Thanks a lot

Hi
You can use e.g. Microsoft's "Dependency Walker" (depends.exe).
It is part of the tools shipped with MS Visual Studio, the Windows Resource Kit Supplements etc. (see the Microsoft home page for more: search e.g. for "depends.exe" or "198038 +depends.exe").
HTH,
Frank

VB6 source code cannot connect to Oracle database after compile to file.exe

Hi All,
I have a problem about VB6 connect with Oracle database. It can connect as normal when run on VB program. After compiled to file.exe and execute, it cannot connect to Oracle database. What's going on ? Please advise? Thank you.
Here is sample of my code connection.
Option Explicit
Private wsData As New ADODB.Connection
wsData.ConnectionString = _
"Provider=MSDAORA.1;User ID=lsp;Password=lsp2007;Data Source=prd01;Persist Security Info=False"
wsData.Open
End sub
Rgads,
Ats.

Hi,
I believe you're in the wrong forum, this forum is for Oracle Application Express.

Is it possible to step into a CVI dll when called by TestStand?

As the question says: "Is it possible to step into a CVI dll when called by TestStand?"
I am sure Ray F. may have a few tricks up his sleeves... Hope you see this post, Ray!
I compiled a dll using CVI. The dll is called as a test by TestStand.
I do have an "exe" version of the code that I use for debug with a testbed, but the behaviour is not the same as testing the actual target while running TestStand. My goal is to get as close as possible to the real events.
Thanks,
JLV

Sorry about that,
There are two ways as I was saying:
1. You can configure the CVI adapter to Execute Steps in a External Instance of CVI (requires CVI 6.0 or greater).
Only go to Configure->Adapters and select the LabWindows CVI adapter and click on configure and select the corresponding option.
After that set a break point in the step that you want to debug.
An external instance of CVI will be launched where you can set break points and step into the code.
2. From CVI Specifying an external process:
In CVI go to Run Specify External Process and enter the seqEdit.exe as the program name (you have to browse to the location <TestStand>\Bin\SeqEdit.exe).
As the argument you enter the name of the sequence file you want to debug.
Now just select Run->Debug SeqEdit.Exe
The Sequence Edtior will be launched and you can set break point in your CVI code and step into it when the step is executed.
Check the Using LabWindows/CVI with TestStand reference manual for more information.
I hope it helps you to get started.
Regards.

LabVIEW crashes when calling a dll

I am trying to call a dll through my LabVIEW program. The dll implements a routine to access an ftp server. When the server is found, everything works as expected. However, if there is a delay in finding the server, LabVIEW throws an error � �An exception occured within the external code called by the Call Library Node�. The detailed error message is attached here.
The dll function times out after 25 seconds if the server is not found (it returns a signed integer). This error message pops up after roughly 20 seconds.
The dll was created in VC++ 6.0. It uses standard MFC calls.
Any information about why this could be happening will be appreciated.
Thanks.
Attachments:
LabVIEW_error.jpg ‏14 KB

Hi,
If you call a dll, everything should be just right, or it will crash (if you
use LV7, you're lucky, most of the times LV stays alive, and only gives a
message).
The first thing that should be checked is the calling convention. This
should probably be "stdcall (API)". This changes the way the parameters and
return address are pushed to the stack.
The second point are the parameters. Pointers should be set to pointers,
LONG to i32 etc. The return parameter can always be set to i32, or to
nothing.
My best guess is (since the dll crashes after a while), there should be a
pointer to a buffer (most likely a cluster, but could be a reference). The
connection succeeds, and the dll copies the information to the pointer. If
the pointer is not valid (the memory does
not belong to LabVIEW), an
exception is raised.
Perhaps you can give a function prototype? The prototype is the way to
start.
Regards,
Wiebe.
"gopinath" wrote in message
news:[email protected]..
I am trying to call a dll through my LabVIEW program. The dll
implements a routine to access an ftp server. When the server is
found, everything works as expected. However, if there is a delay in
finding the server, LabVIEW throws an error - "An exception occured
within the external code called by the Call Library Node". The
detailed error message is attached here.
The dll function times out after 25 seconds if the server is not found
(it returns a signed integer). This error message pops up after
roughly 20 seconds.
The dll was created in VC++ 6.0. It uses standard MFC calls.
Any information about why this could be happening will be appreciated.
Thanks.

Fall into a trouble when calling a dll from java in linux

Hi, experts:
I encountered a big trouble when using JNI to call a C++-compiled DLL from java in Linux: The DLL function didn't execute immediately after the invocation, and was deferred till the end of the Java execution. But all worked well after migrating to windows. This problem made me nearly crazy. Can somebody help me? Thanks in advance.
Linux: fedora core 8, jdk1.6.0_10,
compile options: g++ -fPIC -Wall -c
g++ -shared

It looks like the OP compiled the C source file and linked it into a Windows .dll, which would explain why it worked flawlessly in Windows. (Though I must say the usage of GCC would make someone think it was compiled in Linux for Linux, GCC also exists for Windows, so I'm not sure it's a Windows .dll either...)
@OP: Hello and welcome to the Sun Java forums! This situation requires you to make both a .dll and a .so, for Windows and Linux. You can then refer to the correct library for the operating system using System.loadLibrary("myLibrary"); without any extension.
s
Edited by: Looce on Nov 21, 2008 11:33 AM

Trouble when Labview call CVI DLL in after compiled to EXE

Similar Messages

Maybe you are looking for