Error in Calling a dll built in labview from Matlab standalone

hello,
The problem I encountered is in the use of the math interface toolkit. I
created a dll which performs data fitting using a labview vi which i converted into a dll using the
math interface toolkit.
This dll is then called from a standalone matlab program. It works fine in the computer where I
create the matlab standalone program and labview dll. Howerver when i export to another
computer the matlab part runs fine but an error is reported when it tries to
call the labview created dll.
"One or more output arguments not assigned during call Parfit.dll"
The files related to this problem in the math interface toolkit (the labview vi, the corresponding dll and the matlab .m and .fig files and the standalone exe are in the attachment and named MathITproblem.zip
The matlab run time engine(for matlab 7) and labview runtime engine(ver 7.1) must be installed for this matlab file to run. the run time engines are downloadable from the web.
Does any one know the source of this error or encountered it before?
thanks
Attachments:
MathITproblem.zip ‏1263 KB

Hi Srinivas,
Just another note, I noticed that the Math Interface Toolkit version (MIT) 1.0 is not compatible with LabVIEW 7.1. You’ll need version 1.0.1. of the MIT toolkit in order for it to work with LabVIEW 7.1.
The LabVIEW 7.0 lvanlys.dll is also attached. I had to rename it with a .txt extension, so you’ll want to delete the extension.
Kileen
Attachments:
lvanlys.dll.txt ‏516 KB

Similar Messages

Application crashes when calling DLL built with LabVIEW 2011

Hello everybody,
Our application calls DLLs built with LabVIEW 2010 SP1. We installed LabVIEW 2011 and built some DLLs. So far so good. If we start our application and run 2010 DLLs it still works fine. If we run a 2011 DLL just once no error happens, but if we try to run the same 2011 DLL our application crashes reporting the error below. I saved the code for 2010 version and built a DLL and it works fine. Does anyone know why?
Thank you in advance.
#Date: Fr, 16. Sep 2011 16:25:25
#OSName: Microsoft Windows XP Service Pack 3
#OSVers: 5.1
#OSBuild: 2600
#AppName: PasTA
#Version: 11.0f2 32-bit
#AppKind: AppLib
#LabVIEW Base Address: 0x30000000
16.09.2011 16:25:26.181
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash: Crash caught by NIER
minidump id: 8a779b3f-51d7-4864-8e4d-6ab0195cd158
ExceptionCode: 0xC0000005
N
0x3072C804 - lvrt <unknown> + 0
0x3072CBB8 - lvrt <unknown> + 0
0x7C864191 - KERNEL32 <unknown> + 0
0x7C83AB50 - KERNEL32 <unknown> + 0
0x00000000 - PasTA <unknown> + 0
Attachments:
error.PNG ‏11 KB

On that note, you should be able to create DLLs in 2010 and run them with 2011, correct?? In my case, I have a 2010 built DLL (talking to sbRIO), most of the functions work when run in 2011, but a couple of them lock up LabVIEW on the desktop (but not the sbRIO), no lock ups happen with 2010 on the desktop.

401 Unauthorized Error When calling a SharePoint REST web service from SharePoint 2013 Workflow

We have our Workflow Manger installed on the same server as our SharePoint 2013 WFE development environment. When creating a SharePoint 2013 Workflow all Calls to a SharePoint 2013 REST web service results in a 401 Unauthorized error.
As an example I created a simple workflow that should return a JSON result. The REST Url returns the results in the browser without error.
Set Variable:webServiceUrl to https://<hostnamedsitecollection>/_vti_bin/client.svc/web/lists/getbytitle('ISR%20Approvers')/Items?$select=Title&$filter=Title%20eq%20%27General%27
then Build{...} Dictionary (Output to Variable:requestHeaders)
then Call [%Variable:webServiceUrl%] HTTP web service with request (ResponseContent to Variable:responseContent |ResponseHeaders to responseHeaders | ResponseStatusCode to Variable:responseCode)
The RequestHeader is set to the requestHeaders variable though the web service call properties
then Log Variable:responseCode to the workflow history list
After manually running the workflow in SharePoint on a list item in the ISR Approvers list it Logs "Unauthorized" in the Workflow History Log. It does this with every SharePoint REST web service call that I have tried through the workflow.
It doesn't have anything to do with the Workflow Manger being installed on the same machine as the SharePoint WFE does it?
Thank You for any insight

Hi,
According to your post, my understanding is that you had 401 Unauthorized Error when calling a SharePoint REST web service from SharePoint 2013 Workflow.
Please make sure you use the ‘Call HTTP Web Service’ correctly.
You can enter the URL into the brower to check whether it is correctly.
You need to
create the Request header requestHeaders
using a Dictionary:
Accept : application/json;odata=verbose
Content-Type : application/json;odata=verbose
To associate the
requestHeaders variable, select the Call action
property, set the RequestHeaders property to
requestHeaders.
Please refer to the following articles:
Working with Web Services in SharePoint 2013 Workflows using SharePoint Designer 2013
Calling the SharePoint 2013 Rest API from a SharePoint Designer
Workflow
In addtion, you need to make sure you install the workflow manager correctly.
More information:
Install and configure workflow for SharePoint Server 2013
Known Issues in Workflow Manager 1.0
Troubleshooting Workflow Manager 1.0 Management and Execution
Best Regards,
Linda Li
Linda Li
TechNet Community Support

To invoke an application exe built using Labview from python.

I am trying to invoke an application exe built using Labview from python.
I am able to invoke labview vi, send and receive data. But if I change the vi to exe, it doesn’t work.

This is more of Python. I can suggest you another way, if you can do those changes to your existing code.
This is what I do: If I have to communicate between 2 different platforms I use "File" as a communication medium (Simple method). So if you want to pass data to the LabVIEW code from python, write the data to the file from Python and read the data in LabVIEW and vice versa. I generally use *.ini files for this purpose.
The best solution is the one you find it by yourself

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

Can the dll built in Labview be called in labview

Hi
i built a Dll for the attached Vi and tried to call it in another vi. When i run this vi in which i called the dll, it exits the labview.
why is it so ?
Attachments:
try.vi ‏16 KB
tryi.bld ‏2 KB

I have no problem in calling the DLL that's built. Did you specify the datatype correctly when you configured the Call Library Function Node? I've attached a VI that works.
Attachments:
CallDLL.vi ‏16 KB

Programming a c application which is calling a *.so built by LabVIEW.

Hello all,
This question probably has been asked, but I can't find the answer. So here's my question:
I have built a LabVIEW *.so in Linux and I want to call it from a "c" application. The LabVIEW *.so is returning a cluster of strings and I want to know how to call it from my c application (memory allocation?).
Here's the *.so source code, the function is named "testvi":
Here's my c application source code:
#include <stdio.h>
#include <string.h>
#include "testclusterofstrings.h"
int main()
Cluster_Of_Strings clusterofstrings;
Testvi(&clusterofstrings);
printf("-------------\n");
printf("String_A: %s", (*clusterofstrings.String_A)->str);
printf("-------------\n");
return 0;
I'm getting the following output when calling my application:
LabVIEW caught fatal signal
13.0 - Received SIGSEGV
Reason: address not mapped to object
Attempt to reference address: 0x0x19f5c381
Segmentation fault (core dumped)
So, what is the proper way to do this?
Thanks,
Michel
Solved!
Go to Solution.

smithd wrote:
If its a labview-built dll and you're passing parameters by ref, I'm not too surprised you have to initialize it (although I would expect labview to be friendly enough to allocate the data structures for you). Maybe if you passed it a null pointer instead it would work? From your original post, maybe try this:
int main() {
Cluster_Of_Strings * clusterofstrings = NULL;
Testvi(clusterofstrings);
For some reason I remember reading that labview will interpret the null as a sign that it needs to allocate the structure, but I could be totally insane on that point.
If that doesn't work, then yes you'll have to allocate all the handles as appropriate. From <labview>\cintools\extcode.h you can see that a string is defined as follows:
typedef struct {
int32 cnt; /* number of bytes that follow */
uChar str[1]; /* cnt bytes */
} LStr, *LStrPtr, **LStrHandle;
Since you have size-0 arrays I think you really just need to call DSNewHClr(sizeof(int32)) which will allocate a handle with all 0s, and 0 is what you want. Final result would be...
int main()
Cluster_Of_Strings MeasInfo;
MeasInfo.String_A = (LStrHandle)DSNewHClr(sizeof(int32));
MeasInfo.String_B = (LStrHandle)DSNewHClr(sizeof(int32));
Testvi(&MeasInfo);
Oh, and for the string functions, make sure you look at the built-in functions first before you make your own.
Actually, the whole thing is both a little easier and more complicated at the same time. LabVIEW is fully managed with its data types but you have to follow that management contract when you interface to LabVIEW code from C.
First, the first attempt with allocating a string handle with sizeof(int32) + sizeof(uChar) bytes without initializing the length element is wrong. That length element could contain any value and cause LabVIEW to wrongly assume that the handle is already big enough to fill in its data and not do anything and then writing over the end of the allocated buffer.
Also initialisation of the structure with NULL is not going to work. This cluster has to be provided by the caller as it is a fixed size data area passed in as a pointer. However initialisation of the string handles inside the cluster with NULL should work fine, since LabVIEW considers NULL handles as the canonical zero length handle.
However after you have called the LabVIEW DLL function you are the owner of any memory that was allocated by that function and returned to you, just as you would be if you had allocated those handles yourself before the call. So proper etiquete is to also deallocate it and this is not optional but a requirement or you create memory leaks. It doesn't get noticed here since your test program terminates anyhow right after but it will bite you badly in a bigger application if you forget this.
The code could then look something like this:
int main()
Cluster_Of_Strings MeasInfo;
MeasInfo.String_A = NULL;
MeasInfo.String_B = NULL;
Testvi(&MeasInfo);
printf("-------------\n");
printf("String_A: %s\n", LV_str_to_C_str(MeasInfo.String_A));
printf("String_B: %s\n", LV_str_to_C_str(MeasInfo.String_B));
printf("size %d", (sizeof(int32) + sizeof(uChar)));
printf("-------------\n");
if (MeasInfo.String_A)
DSDisposeHandle(MeasInfo.String_A);
if (MeasInfo.String_B)
DSDisposeHandle(MeasInfo.String_B);
return 0;
// Returns the pointer to the string buffer in a LabVIEW string handle that has been made
// sure to be zero terminated.
char *LV_str_to_C_str(LStrHandle lv_str)
if (lv_str && !NumericArrayResize(uB, 1, (UHandle*)&lv_str, LStrLen(*lv_str) + 1))
LStrBuf(*lv_str)[LStrLen(*lv_str)] = 0;
return LStrBuf(*lv_str);
return NULL;
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

C++ Call to DLL made in LabVIEW Fails the second time it is called

I have an application where a C++ executive calls a LabVIEW DLL (a LabVIEW application built into a DLL).
The executive calls and operates the DLL fine the first time (NT, the applications task manager shows LabVIEW runtime runs, then stops when the DLL is done. However, when the executive calls the DLL a second time, it hangs, and the runtime engine never shows up in the applications task manager as running.
However, this only occurs when something like IMAQ, DAQ, or another custom DLL call is occurring. We tried it with a simple DLL that only uses a call to the sound VIs, and it seems to run fine, although as the program called is very short, and the task manager slow, we never see the runtime engin
e in the task manager. We are going to put a popup dialog in to ensure that the DLL is being called reliably, but we believe it is.
We are unable to answer why when we call something that uses IMAQ, that the DLL doesn't run right the second time. We are unsure of the reasons, but believe it to be related to thread creation and destruction in the executive.
If anyone out there has any insight into this, we would be happy to see it.
We will be putting in a formal request for support from NI, but wanted to poll the audience as well, as we know from first hand experience that LabVIEW users often times have more experience with this sort of thing than developers.
Thanks a bunch

> Thanks for the information Greg. There is no documentation on this
> issue, except for the email that we got from NI Support. This is
> quite a new realm for us and NI alike. We would like to know what
> your experiences have been on this subject. If you have a bit of
> information, perhaps we should suggest a topic. As I said, this is a
> new frontier for LabVIEW, and there are a lot of things that NI
> doesn't know, and I'm sure a few of the programmers out there have
> figured out.
>
I often answer emails from home, but I work for NI on the LV development
team. So anything I know about, NI knows about. The info I was
describing about the DLL execution system is not well documented since
we were hoping that it would work we
ll with the way Windows Apps are
typically written. I suspect that we will need to write a Tech Note
to cover the nitty gritty. This sort of info gets lost in manuals,
and it is subject to change as we learn how people are expecting to
use it.
Anyway, my post was to explain why your use of it didn't work.
In general, we believe that LV DLLs are thread savvy, reentrant
VIs can be called from multiple threads simultaneously, execution can
continue in the background after the DLL call has returned, and the UI
is live provided the calling app processes messages in that thread.
If you have other issues or questions, just ask.
Greg McKaskle

Error while calling a DLL

Hello Everyone,
I have made a dll and calling that dll in LabVIEW.
When I select a functioni n that dll, in the window where we get the Function Prototype, I am getting some unusal charcters like "?", "@@YAHXZ" "void ?FindNodesNm@@YAHXZ(void);"
In the above dll FindNodesNM is a function which i am trying to call
Can anyone tell me why this is so?
Thanks in advance
Avni

If I remember correctly I think this has to do with the way you're exporting the symbols for your functions. I did a quick check in the NI KnowledgeBase and came up with this article, which discusses extra symbols in function names if you don't use extern "C" when definining the symbols to export.

Anyone ever see this error when calling a dll? "Arbitrary.dll?"

Hey folks, I'm attaching a jpg of the error I get as soon as I try and load a vi whose subVIs call a "Call Library Function".
Double clicking on the call function I can verify that the 'Library name or path" is correct, and the Function name is what I want.
I do not understand why it is telling me I need "Arbitrary.dll" - the name of the lib is adwgc.dll as indicated in the path (that I verified).
Anyone deal with this error before? I'm pretty clueless at the moment, any help will be appreciatized and surely kudo'd!
thanks
-pat
edit- also, I'm using LV 2011
Solved!
Go to Solution.
Attachments:
error.jpg ‏18 KB

You get this error because adwgc.dll is internally loading Arbitrary.dll because whoever wrote adwgc.dll called some function in Arbitrary.dll. The only to fix this is to get Arbitrary.dll and put it in a folder that adwgc.dll can load it from. Putting it in the same folder as adwgc.dll should work.
Where did you get adwgc.dll from and are you sure they didn't supply Arbitrary.dll as well?

Receive an error when closing my program built using LabVIEW application builder

When I close my program built using LabVIEW application builder I receive an application error,"The instruction at "0x77fcb1ad" referenced memory at "0x023a0010". The memory could not be "read". Click OK to terminate the program"
I have no idea why this is happening.

This is most likely due to a reference or similar left open. You will experience this if you leave an image undisposed in IMAQ as well.
Check all of your references and be sure you are cleaning everything up.

Calling a DLL(with vi.lib) from a lvclass within a Packed library

Basically, I am having problem calling a DLL (which uses the vi.lib) from a packed library.
The error code I got is error code 1003. “Error 1003 occurred at Call Library Function Node in XXXXX.lvlibp”, “Labview: The VI is not excutable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.   Create Summary Log.vi”
The VI that was mentioned above (Create Summary Log.vi) is one of the functions in the DLL that I am trying to call from the packed library. This VI modifies an Excel spreadsheet so it needs the vi.lib. In my DLL project, vi.lib is in my dependencies. When I compile my DLL, Labview will create four folders (NI_Excel, NI_HTML, NI_report, NI_Standard Report) at the build destination.
To problem happens when I run a Top level VI, which calls-> the lvlibp -> lvclass (within the packed library) -> DLL (uses the vi.lib Excel functions).
This problem doesn’t happen when I am not running the packed library (Only with the lvclass). So I think the problem is that DLL can’t access or find the vi.lib when it’s being called by the packed library. It seems like the packed library changes the way the DLL access the vi.lib.
Any suggestions?

Hi,
Thank you for your reply. Unfortunately, I think I might have provided wrong information. I thought the problem didn’t exist when I wasn’t running the packed library, but the truth is, the problem always exist regardless.
I would get an “error 7” when I created a simple VI that would utilize “Call Library Function Node” to call the DLL.
Error 7 occurred at Get LV Class Default Value.vi
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS X, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
=========================
NI-488: Nonexistent GPIB interface.
Complete call chain:
     Get LV Class Default Value.vi
     NI_report.lvclass:New Report.vi
     Create Summary Log.vi
     Create Summary Log.vi.ProxyCaller
LabVIEW attempted to load the class at this path:
C:\XXX\XXX.dll\Excel\NI_Excel.lvclass
So the problem is, I don’t know how to include the NI_Excel.lvclass in my DLL. I didn’t have this problem back in 8.2, as I would just include a VI (with the excel VIs in the block diagram) in the project when I build it. This doesn’t work anymore as I am using 2011.

Input parameter setting when calling a DLL(Built from LabVIEW and a kind of VISA communication driver) in Teststand.

In labVIEW7.1 I wrote a COM port communications driver by using "VISA Write/Read". I put a string as the input of "VISA Write" and made it the input of the whole vi. Then I converted the vi into a DLL, which is called in Teststand3.1 by specifying DLL adapter. In "Edit C/C++ DLL Call" dialog, I pass a message of "60 6A 94 80 86 81" as the input parameter. My problem is I tried three kinds of methods to pass the message, see attached 1.jpg,2.jpg and 3.jpg. and found the first one sometimes doesn't work, the second work fine and the last doesn't work all time. I don't know why the first one and last one don't work well.
Thanks!
Jacky
Attachments:
31.jpg ‏38 KB
11.jpg ‏36 KB
21.jpg ‏49 KB

Hi Srinivas,
Just another note, I noticed that the Math Interface Toolkit version (MIT) 1.0 is not compatible with LabVIEW 7.1. You’ll need version 1.0.1. of the MIT toolkit in order for it to work with LabVIEW 7.1.
The LabVIEW 7.0 lvanlys.dll is also attached. I had to rename it with a .txt extension, so you’ll want to delete the extension.
Kileen
Attachments:
lvanlys.dll.txt ‏516 KB

Error when calling a DLL function

Hi,
I am using external C++ code with labView. One of the DLL functions I use serves to call files. The directory and the name of the file is is passed as a parameter for this function. When the VI is running and arrives at this function (I use the Calling Library Function Node tool), the following message is displayed:
ERREUR de type class boost::filesystem::filesystem_error.
boost::filesystem:ath: invalid name "D:\Documents Johan\Johan\Stitching\Fichiers de mesure\front parfait\13z2" in path: "D:\Documents Johan\Johan\Stitching\Fichiers de mesure\front parfait\13z2"
I do not know why this message is sent to me.
Thanks for your answer
JF

Hello,
How are you passing the file path to the DLL -- are you passing it as a
string? If you are passing at as a string, I would do some basic
console output to make sure that your DLL is receiving the file path
corectly as a string and perform your appropriate C++ function in your
DLL. If the error is occuring with passing the file path you
might want to check out the links below for a little more information
on this.
http://zone.ni.com/devzone/conceptd.nsf/webmain/7d6a20fe02edbf318625690700704cf3#4
http://digital.ni.com/public.nsf/websearch/4E9234BA4C7C4ABE86256E3C0074760F?OpenDocument
http://digital.ni.com/public.nsf/websearch/3B994675B17C654A86256FDD00754DD2?OpenDocument
Hope this helps,
Travis M
NI
Travis M
LabVIEW R&D
National Instruments

Error when calling external DLL function.

When calling a function in Oracle, the error happens
ORA-28575: '... error RPC connection to external procedures'
code:
create or replace library LibFunctions as 'c:\MyDLL.dll';
grant all PRIVILEGES on LibFunctions to public;
create or replace
FUNCTION Max(num1 in number, num2 in number) RETURN number IS
EXTERNAL LIBRARY LibFunctions
NAME "Max"
LANGUAGE C;
grant all PRIVILEGES on Max to public;
obs. Dll was created in Pascal.
What can this error?
tks,
Mauricio
Edited by: user13794390 on 19/01/2011 06:29

It's been a while since I used extproc. Anyway, it listener.ora make sure extproc is added. I'll assume you are on Unix:
(SID_DESC =
(SID_NAME = PLSExtProc)
(ENVS = "EXTPROC_DLLS=ANY,LD_LIBRARY_PATH=proper-directory-list")
(ORACLE_HOME = path-to-oracle-home)
(PROGRAM = extproc)
) SY.

Error in Calling a dll built in labview from Matlab standalone

Similar Messages

Maybe you are looking for