do not call the dll of Labview in CVI

I have a Labview dll should call for the CVI. but it always shows error.

void __cdecl Idx_RW_Reg (uint16_t registry, int32_t RegLength,
[LVBoolean Data_in], uint8_t OperationRd1Wr0, TD1Hdl * read_reg_table_in,.
uint16_t PortAddress, TD1Hdl * Table_of_reg_out, LVBoolean ControlFrame [],.
uint16_t * PortAddressOut, int32_t len2, int32_t len);

TD1Hdl * read_reg_table_in: what is it, who can tell me

typedef struct {}
int32_t dimSizes [2];
LVBoolean Boolean [1];
} TD1;
typedef TD1 * TD1Hdl;

Any help is greatly appreciated.

Thank you.

Hello

What is your calling code?

I suggest you read: call a LabVIEW DLL in a CVI or other C/C++ project

Kind regards

Tags: NI Software

Similar Questions

  • Call the function in LabView from a DLL, and then access the global variable of DLL

    I've created a DLL in LabWindows with a function and structure.  I want to call the function from LabView and then access the overall structure.  I am able to call the function in the DLL with a "call library function node" and has access to the return value, but I can't understand how to access the overall structure.  The structure is declared in the header DLL with __declspec (dllimport) struct parameters file.

    Is it possible to access this structure without using the library of network variables?

    My guess is that you need two bytes of padding after "in_out" and another to two bytes of padding after "anin."  The reason being that ints are 4 bytes, and most of them C compilers will align on 4-byte boundaries.  The struct will naturally start to such a limit (in fact, in Windows, it will probably start to an 8 byte boundary).  If you then count bytes in your structure, you are 70 byte after "in_out."  70 is not divisible by 4, so you need 2 bytes more to reach the next 4 byte boundary.  You can also you could reorganize your struct so that "anin" follows "in_out" and this is probably the best option if it won't cause you other problems.

    Unlike most C compilers, LabVIEW compressed structures as closely as possible, without filling.  I don't know enough about the history of LabVIEW and internal parts to explain the reasons and to do this performance penalty, but, as choice of LabVIEW "endianness", it is probably a remnant of the first versions of LabVIEW that were running on the Mac.

    If for some reason you want to force your C struct to match package LabVIEW, you can use the #pragma pack (x) directive, but I wouldn't recommend that here because you can control the C and LabVIEW.

    EDIT: in the cases where it was not clear, add padding to your cluster of LabVIEW, insert appropriate size or items at the place desired in the cluster.

  • Call the library function does not find the DLL in the directory where are my LLBs

    I'm using LabVIEW 8.6.  I have a set of screws in several LLBs.  All LLBs located in a directory.  Most of my screws is wrappers for the functions in a DLL.  I was told to put my DLL in the directory where are the LLBs, and apparently this is how the previous programmer has worked (using an earlier version of LabView).

    In the configuration of the library call, I've specified .dll without path.  (This is how we want our screws are an API that will integrate other programmers, so I don't know where they put things and I can't use absolute paths).

    When I insert the VIs in LabVIEW, LabVIEW can not find the DLL and wonder of spotted.  It's just that here in the directory with the LLBs and when I double click on it, everything works fine.  However my absolute path to the DLL now appears in the library to call configuration, and we don't want that.

    Does anyone know how to make this work?  I guess the location of the screw (or LLBs, in this case) should be the current directory and thus Windows search there for the DLL.  However, it seems that this is not the case (in the least, in the latest version of LabVIEW).

    Thank you.

    Batya

    Well someone using your library should not have to dig into your screws and do it all on his own. Instead your library must wrap that and hide disorders it altogether.

    The cluster of error has been added when the dynamic path option has been added. It is not useful hide this error output, so it's always there. As well as the dynamic path, there was the improved error handling added the CLN. One of them is that the level of verification when calling function errors (exception handling) can be specified. I guess that some of these options may generate an error code instead of bring up a dialog box, as they did before and that the output of error code can be useful even in the case of static calls.

    As to what you want to do, I would have long managed that with a DLL that has essentially the same functions as your other wrapper DLLs and an initiliasation function that returns a pointer to a structure of functional distribution based on the actual DLL you want to call. Quite like what an object-oriented function dispatch table is. Then, when your interface initilising you call initialize function and specify the device interface/type that you want to use and after that all other functions take a pointer extra function parameter expedition as the first parameter, in addition to the parameters of the real function. This dispatch function pointer would be just a pointer to a structure that contains the table of function for this interface pointers and the sake of LabVIEW would simply be an integer of size pointer.

    The wrapper function then checks the pointer structure validity send feature and call the actual function with the remaining parameters. It is a C programming and may require a planning and desigining the different interfaces to facilitate this kind of technique of the expedition, but it will certainly pay to long-term and make your library even can be used in previous versions of LabVIEW, so that VB etc. without delicate dynamic loading in the level high, programming environment.

    Rolf Kalbermatter

  • Call the dll in BT (usbm.dll)

    Hi all

    I'm having a hard time finding how to call a DLL in Labview. I read a little bit on this subject but am still a beginner. The DLL in question is usbm.dll (http://www.usbmicro.com/, the list of functions & types is documented here). I use the call library node to call the DLL.

    So I call things with no input argument functions work well (for example my first 2 calls check for the presence of the device and the number of devices and work ok returning the correct output)

    Then I try to use functions with arguments (3rd stage of the VI) and Labview does not have them (error 1097). I'll for function "int USBm_DeviceValid (unsigned char device)", in my opinion, that argument must be of type uint8 and output type int8... I tried all numeric types, does not.

    In addition, if I skip the VI 3 and go to step 4 (calling a function that takes 2 parameters and sends a command to my device): the function is executed (for example the unit move), but then Labview block (exits without error message). Is it because of calling the function?

    Any suggestions would be welcome, thanks!

    Hi lvrat, thanks for your suggestions.

    I had the problem. I got an older version of this DLL usbm (as well as some example of LV files) which works very well. Looks like the DLL most recent that I was using has some issue with Labview...

    I enclose these files (they were not easy to find), in case someone else tries to interface to a USBmicro device.

  • SubVIs called screw embedded in a DLL must be located at the opening of a VI that calls the DLL

    I have compiled a DLL that contains two exported screws calling subVIs that calls another DLL that contains hardware dongle functions.  The build DLL works fine and the two screws work fine as source code.  The reason why I want to build a DLL, it is avoid distributing the source dongle screws in order to make the two functions called more sure.  However, when I try to open a VI that makes a call to one of my two functions of the DLL (screws exported), LabVIEW try to find all the subVIs called by VI exported in the DLL.  This suggests that the DLL does not contain the subVIs - probably each VI called by the exported screws must be built in the DLL - or am I completely wrong?  I tried setting all the subVIs and the dongle DLL like 'always understood' and even export all the subVIs too.  The constructor of the DLL is able to include the entire hierarchy of VI in the DLL?  Am I missing a special combination of parameters?

    To summarize my approach:

    A first level VI (to provide an end user with password protected diagram) calls my DLL (two functions are exported screws) that call subVIs that call the DLL dongle.  I want only to provide my DLL and the dongle DLL, NOT all their source code is linked.

    Any help would be greatly appreciated, that this problem has ceased completely in my development.

    Mike

    After traveling through the builder application LAVA forum, I found a post that discusses a problem of construction of the Advanced setting 'Use LabVIEW 8.x file layout'.  This should be checked to make the build work.  Apparently R & D already know the problem (# 158487).  Moreover, previous projects of 8.6 will have this checked by default, which makes them to build properly.

    The new application now works correctly.

    The problem of generation original DLL is also fixed.

  • I have W XP, SP3. Suddenly, Adobe reader showed the error: Acrobat could not load the DLL base.

    I have W XP, SP3. Suddenly, Adobe reader showed the error: Acrobat could not load the DLL base. Have Adobe reader X (10.0.1) who refuses to be carried away. Other than a drive X (10.1.0) has been reinstalled. Also have Acrobat reader 5.0 is installed from a CD of the Canon scanner slide. The error remains. If anyone can help. Leif Stg

    Hi Leif,

    Where do you get this error message?

    I suggest you to follow the steps and check if it helps.

    Method 1: Uninstall all the instance of Adobe reader and Acrobat reader and install the latest version of one of the drive and check if it helps.

    http://get.Adobe.com/reader/?promoid=DINRS

    Method 2: If the problem persists, perform a system restore and check if that helps.

    How to restore Windows XP to a previous state

  • Could not load the dll target, the error code 126

    A "runner error" box keeps popping up saying "could not load the dll target, error 126" code.  This appears at all different times, even when I'm not using the computer.  I don't know why it gives me this error or how I can get rid of him for good.

    Hello Tracy,.

    Try to configure your system to boot into boot mode (Ref: http://support.microsoft.com/kb/310353) will help you identify the problem.

    I hope this helps.

  • Adobe Reader could not load the dll base

    Original title: program compatibility Application Applications Apps game games Legacy Crash accidents Application Hang hangs

    Adobe Reader 9, X, and XI all will not pdf error message load Adobe Reader could not load the dll base saying tried to uninstall reinstall changing the settings all it does not please help I use it for my college courses

    Hi Marcel,.

    The question you posted would be better suited in the Adobe Forums; We recommend that you post your question in the Adobe Forums to get help:

    Adobe support: http://forums.adobe.com/community

    Keep us informed on the status of the issue.

  • When you try to open a PDF file, it says "Acrobat could not load the DLL base."

    I do not have any Antivirus and when I want to open a PDF it always says "Acrobat could not load the DLL base."

    Hello Kushagra_Saxena,

    To address your error message:
    You can repair Adobe Reader in Control Panel:
    In Windows, choose Start > Control Panel, and then double-click programs and features.
    Click on adobe Reader.
    Click on modify and follow the instructions to repair the application.

    Since you don't have an Antivirus, you can download Microsoft Security Essentials for free.
    It offers offers protection in real time for malware, spyware and other virus infections. It runs
    quietly and efficiently in the background.
    You can download at the following Web site: http://www.microsoft.com/en-us/security_essentials/default.aspx

    I hope this helps.

    Marilyn

  • SOUL error: could not load the dll to return of the ICC: BCC8_AE_16Bit.dll

    Whenever one of my colleagues opens the Adobe Media Encoder, it loads the start screen for the SOUL, but then we get the following:

    Could not load the dll BCC Render: BCC8_AE_16Bit.dll (see image)

    AMEerror.jpg

    We have already tried to uninstall and reinstall, but without a bit of luck.

    It's the CS6 Cloud creator on Windows 7 x 64 machine.

    SOUL works very well if you uninstall the plug-ins from Boris?

  • Call a dll for Labview: function not found in the library

    Hello

    I try to call a form very simple .dll Labview. I have compiled .dll file for x 64 by using Visual Studio 2010, because I'm using Labview(64-bit). I did everything exactly as I have read in several tutorials. But the "call library function node" does not create a menu with functions avalible as it is supposed to do. The Import Wizard found no function either. What is the problem with my .dll?

    I added a block marked 'extern "C" ' file in my source, but it still doesn't work.

    Thank you

    Matthias

    You have not read the article properly. Read step 3. In the .cpp file, you add '__declspec(dllexport)' to the body of the function. In the header file, you add extern 'C' at the beginning of the prototype. It comes to dealing with the name decoration than the C++ compilers.

  • File not found when you try to call a dll on LabVIEW Real Time machine

    I have a dll called "DLLRTTEST" that I wrote, and claim successfully on my host.  Now, I try to call this dll from a vi that is on my computer in real time.  Currently, I get a message 'error 7 occurred at the crux of library DLLRTTEST.vi. call function' when running

    In the attached screenshot, I try to ensure that the vi that I am running is indeed on the system in real time.  I then use a 'check if file or folder Exists.vi' to confirm that the dll that I'm about to call exists on the system in real time as well.  However, I always get an error "error 7 file not found" from the node call library feature.

    Any help is appreciated.

    Thanks again for all the responses.  As I said earlier, I had already met and solved the problem identified in the link provided by Nathand.  I had to go down to Visual Studio 2008 to go beyond this particular error, after which the app of auditor of the dll in real-time reported my dll needs to run successfully.

    I just got the phone with Jack in charge NEITHER well, and it turns out that I simply had to compile my dll in release mode.  Decommissioning of VS 2008 I got the correct version of dll (msvcr90.dll), but since I am compiling in debug mode, I found myself using msvcr90d.dll (d for debug) who doesn't have my computer in real time.

  • Loading of a DLL on RT: Missing Export "DecodePointer" "Kernel32.dll" and 7 error when calling the DLL

    Hi, I recently changed to Visual Studio 2010 and Windows 7 64-bit.

    I have an existing Office RT system running RT 2009.  This system calls a DLL that I already built using Visual Studio .net 2003 and Windows XP.

    Since I've recompiled the DLL I get an error 7 file not found error when I call the RT DLL, even if I simply replaced the old DLL with a new one in the file system so the path has not changed.

    I also noticed that the message on the screen connected to the RT system during startup:

    "achieveworldpeace.dll" load error: lack of export 'DecodePointer' of ' Kernel32.dll'.

    Any ideas on this problem?  It is perhaps as simple as a switch in the compiler?

    Thank you.

    I'm not sure it's a simple switch in the project settings in Visual C. The problem is clearly in the standard C runtime library that gets linked to your DLL and refers to exports of Windows which are not available on the RT system. Don't forget that the RT system is a limited Win32 API emulation.

    I usually avoid these problems using Visual C 6 to create DLLs for LabVIEW projects. The standard library of the C runtimes will not know what Windows API reference more recent exports because they have supported even under Win95. So unless your explicitedly reference code not supported RT APIs you wouldn't have problems. If you do not use the standard C file i/o functions and management of memory in your DLL functions, you can also try to link statically C runtime libraries in your DLL, or vice versa depending on what you have now. It may or may not work. Otherwise there is not much else but by using an earlier version of Visual Studio.

  • Could not import the DLL

    Hi all

    I am using the libsie API to open files .sie of SoMat (there is only a plugin for this data format for LabVIEW and tiara, but it does not work). I have previously imported from the dll using the wizard import with great success, but I don't ' know my way around c or c ++ so am a little confused on this one. When I try to import the attached dll (you will need to display the extension of .doc to .dll) by using the attached header file appear no calls. They are there in the header file. I wonder why that is. This is a header for the evil formattted file or is there another question?

    I have attached a copy of the zip file that I downloaded on the HBM website. There is a demo .sie in this file if you want to watch. It seems to be a fairly complete documentation on the API Web site.

    Any help or pointers gratefully received.

    Phil

    It doesn't matter what language was used to create the DLL, as long as it exports a C compatible (which does).

    If you make a copy of the header file and delete SIE_DECLARE(), leaving everything inside the brackets unchanged, of each function declaration, I think that you will be able to import at least some of the functions. I don't know how well the import utility will handle the pointer data types, you may need to modify each node in library function call to set manually after the import.

  • Problem calling seconday DLLs in labview

    Hello

    I'm using Labview 8.6 for my application. The application calls a dll developed in vc ++ (main dll).  During execution of the application, the main dll(vc++) calls another (secondary dll) developed in vb 6.0 dll.

    During the process, the main dll sends data to secondary dll to display data in a pop-up window. After getting the user recognize the display, the vi application stops.

    When the application runs first time (the vi running first time after labview open), the data sent by the main dll are updated in view of the secondary DLLs. But, for the second time from new data of the main dll not are not updated in view of the secondary DLLs.

    Once again, after the closure of the vi and quit labview, if I open and run the vi, then the data of the main dll are updated in dll secodary display. But the maindll data must be updated in the secondary dll without leaving labview.

    I use "Function Call Library" to call the maindll.

    Can someone please give the remody to this problem...

    Thanks in advance.

    Swamy.

    Is - this two dll to reside in the same physical directory as your main vi? They are included in your project?

    -AK2DM

Maybe you are looking for