02-21-2014 03:09 AM
What I already do is calling a webservice (SAP BAPI) with LabVIEW in order to get some information from the ERP. To do this, a DLL call is required and it always works fine.
Now I'm looking for a LabWindows/CVI solution for this, so I built a shared library out of the LabVIEW-VI which contains the BAPI call. Now I have a DLL which calls a DLL, and obviously it doesn't work this way. No meaningful data is returned from the built LabVIEW-DLL, so I must assume that entire VI is not called properly. Even when I wire a constant value to the output "daten" for debugging purpose I won't receive it as long as the subVI containing the DLL call is enabled within the LabVIEW-DLL. As soon as I disable the subVI is disabled the returned data is ok.
The attached screenshot shows the VI which the DLL is build of.
Anyone faced this problem too?? After a long web research I have no idea what to do...
Many thanks for your help!
02-24-2014 12:40 AM
02-24-2014 12:49 AM
try to copy both DLLs in the same directory as your LabWindows/CVI executable.
02-24-2014 01:16 AM
Doesn't work neither.
02-26-2014 12:45 AM - edited 02-26-2014 12:46 AM
I just found out that it works when the DLL is called in LabVIEW (LabVIEW VI calls LV-DLL that calls a DLL). What is the difference between this and calling the LV-DLL from CVI?
02-26-2014 12:13 PM
03-03-2014 01:43 AM
Top level: call.vi
The shared library which is called by "call.vi" is located in a subfolder. The DLL which is called by the shared library is also placed there.
03-03-2014 01:45 AM - edited 03-03-2014 01:45 AM
I also posted this one in the CVI forum as well:
Some extended information now:
Originally I imported a web service by means of the LV Web Service import wizard. LabVIEW automatically created a DLL which establishes the connection (SubVI "Open Web Service GET_DETAIL"). The main VI contains this subVI and the invoke node that performs the call. This "Main.vi" works properly when run using a valid login info preconditioned. In order to get a CVI solution for the ERP call I built a shared library out of "main.vi". Calling this one using LabVIEW (call library funcion node) also works properly.
Now I created a LabWindows/CVI project to call the shared library. And this doesn't work anymore.
As you can see, the return value from the shared library is an error code. A call's return value will always be 0 in case I call the shared library out of CVI, even when I wire a constant value to the "error_code" output in the shared library for test purpose.
A C string pointer is given from CVI to the shared library so "material" can be read in CVI afterwards. This procedure basically works when I create a test project without the ERP call. Including the ERP call, the string contains the same nonsense as it did before the call, so I assume that no value is ever assigned to the string.
Attached you'll find the project VIs also including the C source. The VIs I haven't mentioned do some error handling or data manipulation stuff (e.g. add leading zeros to a string).
03-03-2014 03:32 AM - edited 03-03-2014 03:36 AM
This can't easily work. Basically you are fighting with DLL search paths here, and the fact that you mix LabWindows CVI and LabVIEW here makes this more complicated.
LabVIEW tries to be a bit smarter when locating DLLs and usually searches the project directory too for a DLL before letting Windows handle the search for the DLL. Windows however only searches in very specific locations for DLLs. LabWindows CVI has no notion at all about LabVIEW project files and its directory. So it simply hands the load request to Windows and that will fail if any of the dependencies is not in one of the standard Windows search locations.
The Windows standard search locations for DLLs are:
1) DLL already loaded in the application independant of the actual absolute path specified
2) if the path is absolute at that specific location and if not found the loading will fail here
3) in the application directory (where the exe resides that launched the current process)
4) in the System directory
5) in the Windows directory
6) any directory listed in the PATH environment variable
7) in the "current directory" a variable that is maintained per process and updated by various Windows API functions that access directories
In earlier Windows versions step 7) was actually located between step 3) and 4)
If you enter the entire path in the Call Library Node configuration, LabVIEW will pass this absolute path to Windows to load the DLL (and if you build an executable or shared library the absolute path will be adjusted to point to the location where the application builder copied the DLL). If you just enter the DLL name, LabVIEW will adjust the path to show the location where Windows found the DLL if it was found, but remember that you only entered the DLL name alone. In that case it will not include the DLL in any executable or shared library build at all and depend on it that this DLL is installed by other means in one of the Windows standard search locations.
03-03-2014 04:05 AM
Many thanks for your explanation!
But doesn't this mean, that CVI or Windows should find the DLL when placed at the same location as the CVI exe? I did this from the very beginning...
For test purposes I also placed the DLL in C:\Windows and C:\Windows\System32, but it didn't work, in neither case.