call DLLs created by VC ++ in CVI

Similar Questions

• call dll issue

  Hello

  now I need to call a dll named SajetConnect.dll, this dll will create logfile and ini file automatically when I call.

  Attached VI call this dll, there is no log file and ini file created, but the exe file that I'm building this VI work well for her.

  I also call thie dll using c# and it still work fine.

  So it seems that some path setting question went from me, thanks for your help to take a look for my trouble, thank you!

  attached list

  2. without title vi VI

  New Folder\123\Application.exe create JOURNAL SAJET. INI SajetConnect.ini when you run this exe to call DLLs

  Without seeing the source code of the DLL there is very little we can do, but shooting in blue. And I have no balls to spare in this at the moment, except maybe the DLL tries to create these files in the directory where the executable. This would be the directory where the labview.exe deveopment environment. But given that Windows Vista users don't have write access to this directory more. Some features of the INI file are virtualized in these versions of Windows and redirected to a specific shade of the user location, but only if your application uses files INI of Windows API functions. Otherwise write access fails just and you won't see them unless you manage these errors in some way and proceed to the appellant.

• Python, call DLLs in LabVIEW: Fatal internal error when accessing output String Cluster

  Hello

  We have compiled a DLL in LabVIEW (TestError.dll) and tried to call it from Python.

  TestError.dll includes 2 functions:

  1 testErreur: cluster 1 entry string, 1 channel indicator

  2 TestError2: 1 channel input, 1 bunch of output string

  What we try to do in Python is actually something like this:

  1 provide values to controls in the functions of the DLL.

  2. call the DLL.

  3 get the values of the indicators.

  What we have seen are:

  1 read/write operations on normal data types (string, digital) indicators/controls are OK

  2. write operation on the Cluster string entry is OK

  3. read operation on the Cluster output string is not OK. The following error is still prompted for:

  «Unrecoverable internal error: 'MemoryManager.cpp', line 437.» LabVIEW version 8.6... »

  Also joined the TestError.prj and python code.

  Grateful if someone can help to explain why we get this error and how to overcome?

  Thank you

  howmean

  What we have seen are:

  1 read/write operations on normal data types (string, digital) indicators/controls are OK

  2. write operation on the Cluster string entry is OK

  3. read operation on the Cluster output string is not OK. The following error is still prompted for:

  «Unrecoverable internal error: 'MemoryManager.cpp', line 437.» LabVIEW version 8.6... »

  Also joined the TestError.prj and python code.

  It is very logical that it does not, and the bad news is, it cannot really be implemented reliable of a process not LabVIEW.

  LabVIEW channels (and tables) are very specific species. They are then called handles, which are pointers to a pointer to a block of memory. If you have a control or indicator on its own, the Prototype configuration allows you to configure this setting as a C. LabVIEW data pointer, when creating the DLL, create heels C for each exported function and place the code to do the translation between the past C pointer to and necessary LabVIEW data handle. For strings and arrays within the cluster, there is no configuration option and the DLL is expected to pass a structure with data handles native LabVIEW in there.

  You may say that creating handles data in your calling process enough to trick LabVIEW. For the input variables that actually CAN sometimes work (but is a delicate and dangerous generally to handle this). There is no way to make it work for output variables. LabVIEW will try to resize handle to fill data in that he wants to make. This resizing is done using internal memory manager of LabVIEW. This will work only if it had been allocated by EXACTLY the same instance of the memory manager. Otherwise, it refers to a different memory segment and catastophally fail. The only way to make this work perhaps, with luck, taking your heart and prayer to the gods, is to lvrt.dll to allocate a handle that you must pass to the DLL. Still find the good lvrt.dll, which will execute your DLL LabVIEW is a major challenge.

• Efficiency call DLLS in Labview

  Hello

  I'm working on a labview program for the treatment of the data in real time.  Thus, code running efficiency will be critical.  I wonder how about the cost of calling DLLs.  Similarly, what the call cost of the subprogrammes.

  To implement the same function, the call of a Subvi will be faster than calling a DLL?

  If I can develop all screws Sub in the main program and delete all the calls, which will be much faster?

  Can someone give me any clue or guideline?

  Thank you.

  CRXX wrote: [...]

  I'm working on a labview program for the treatment of the data in real time. [...]

  What is the OS you are using?

  Since you ask in general, I answer in general:

  This question cannot be ansered. This is a case-by-case-thing and must be assessed individually.

  Most of the effect will be the memory management: which allocates the amount of memory? When it's done?

  Memory of ESP. allocation mess up determinism, if a DLL can perform worse than pure code LV (given a BONE of RT LV). But it might be preferable for some algorithms encapsulated... no one can say in general.

  Perhaps the most important question is:

  How many times is that the code (DLL vs Sub - VI) called and how short is its runtime? If the load of execution: calling code relationship is very low (-online 1:1), it is best to "solve" the subcode. SubVI Inling is a valid way in pure BT (from 2010).

  If the code is called rarely, this whole discussion is somehow obsolete as the overload of calls will be negligible, even if it would be quite high...

  And no, C is not faster as LV by definition. It also depends on the task and how you implement it...

  hope this helps,

  Norbert

• Call dll ActiveX in Labview

  Hello

  I'm a new starter in c# .net.  I have a control dll ActiveX (control of vision of NOR -> CWIMAQ). I need to call dll functions in Labview. I searched for articles on this subject. Everyone talks about single thread and register the dll.  I have no idea about these things. Can any body give me a helping hand. How does it work?

  Thanks for any info

  Best regards.

  To use an ActiveX control in LabVIEW, you place an ActiveX container on the front panel and locate the control to put it in. Then use the nodes property and/or call nodes of the ActiveX palette to set properties and call methods.

  To register a DLL open a command prompt, navigate to the folder where your ActiveX control is normally the Windows system32 folder and type

  regsvr32 .

  In LabVIEW use help > type in the search and find examples... tab ActiveX.

• Pursuant to the window, we call exe, created in wpf, we got an error like ' an unhandled exception microsorft net framework exception due to the jilplayer.exe ' [6034]

  Pursuant to the window, we call exe, created in wpf, we got an error like ' an unhandled exception microsorft net framework exception due to the jilplayer.exe ' [6034]

  Hello Kumar,

  The question you have posted is related to Windows Presentation Foundation (WPF). The right place to contact you would be supported in MSDN. I suggest you to check with the help of MSDN for more information.

  http://social.msdn.Microsoft.com/forums/en-us/newThread?category=netdevelopment&Forum=WPF

• Can I create external call to create the campaign?

  Hello

  Can I create an external call to create the campaign in SFDC?

  I want to create an external call by that I have to go to sfdc and create the campaign.

  Can this process be automated like this, I create a campaign in Eloqua > put the name of the campaign, the campaign id and the type of campaign he in settings > fill these values in the countryside in Eloqua himself. > and when the external call runs, a SFDC creates a proper campaign.

  I think it may seem like a dumb question but I just want to check whether it is possible or not?

  Activate the internal event for 'Create campaign', change the mapping for the external call.

  Then create the campaign, check the box "Sync with CRM", save, go get a cup of coffee.  Do not change the campaign until you see the ID external populated campaign.

  Once the synchronisation with SFDC has arrived, you can add elements of your canvas.

  Nathan

• How to call dll com APIs that range from the performance counters of less than 1 ms with CVI and always get less timer resolution of 1 ms

  Hello

  I've created a dll com in VC ++ using performance counters/timers to less than a millisecond.

  This is useful when you send a message to very high speed. (say 10 or more)

  This is done by the dll.

  When I use CVI to create a user interface, this dll runs at a fixed rate of 1ms.

  This slows down the application.

  I tried to use the same dll with VC ++ host and it works well.

  I need to check the registry setting to see if the useDefaultTimer is set to false or TRUE.

  (I'm not near the development PC) However, by default, it should be FALSE and I have no fidle with it.

  Veuileez post any suggestions you might have.

  Thank you!

  This problem is now solved for me.

  Just the highest thread priority in the dll.

  Thank you if you had the answer.

• Why do I get 'Bad call Dll Convention'?

  Hello

  the gall attached contains an experimental to read dll in LV 8.6 and use in VB6.

  The zip file contains the vi (adding 2 numbers), LV, VB6 project.

  The service seems to work.  He adds the numbers, but still, it gives the error "Bad dll calling convention".

  I think I did good. I used the Conventioin of the Standard call.  I used Double in LV and long in VB.

  How can I get rid of this error?

  Sombody allows this example on his machine.  Maybe it's something to do with my specific machine?

  VB usually gives the error "Bad DLL calling Convention" when you said an incorrect function.  This can be as simple as exporting with __cdecl instead of __stdcall (although this will crash more likely only), or it could be that because of the function declaration to say the battery is placed in a terrible state because the DLL call placed more or less data on the stack that VB should based on your statement.

  In your specific case, I see a few problems.   For reference:

  In LabVIEW, is your equivalent C function prototype as shown in your project file:

  Double AddNumbers (double * xY, double x, double y)

  In VB, your statement is:

  Declare Sub AddNumbers Lib "D:\NI Projects\eDAS400\DLL\LVDLL Experiment\SharedLib.dll" _

  (ByVal x As Double, ByVal y As Double, xy As Double)

  The first "double" in the C prototype means that the function in the DLL call will return a double.  In your VB prototype, by declaring "Sub" you are, in essence, says VB you don't expect the DLL to return data.  It is a likely cause of your error.  To resolve this issue, change to say "Declare function", and then add 'Double' at the end of the statement.

  The second problem I see is that in your prototype C, the first parameter is passed by reference (like a pointer).  However, your statement of VB, passes all ByVal.  You must change this option to make the parameter that returns data (in this case xY) is passed ByRef.

  Finally, it seems that your parameters in the function of C are probably not in the order that you expect.  I expect to be x, y, xy (which you have in the VB declaration), but the order in the C (ie. in the DLL) function is not the same.  This results in a funny behavior.  The order must match between the two.  To resolve this, I recommend you actually change the LV DLL so that settings are exported in more logical x, y, xy order.

  I think this should take care of your problems.  Sorry so lengthy, but I wanted to make sure that you understand the 'why' on this one because it can be a common error trying to create/call VB dll.

  Jason

• Sequencefileload freezes when calling DLL

  Hello

  I TestStand 4.1, and when calling a DLL on the MainSequence, everything seems to work fine, but if I call him on a SequenceFileLoad TestStand freezes on this step.

  What could be the problem?

  Kind regards

  Daniel Coelho

  Daniel,

  In fact, printf() can be the problem.  Because you are calling it in DLLMain, there are additional considerations you need to keep in mind.  Microsoft has a great page on these considerations here: http://msdn.microsoft.com/en-us/library/ms682583 (VS.85) .aspx

  Some excerpts:

  The entry point function must perform only the tasks of termination or simple to initialization. It should not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), as this can create dependency loops in the DLL load order.

  Calling functions that require one dll other than Kernel32.dll can cause difficult to diagnose problems. For example, the calling user, Shell and COM functions may cause access violation errors, because some functions to other components of the system load. Conversely, calling functions of these courses of termination can cause an access violation because the corresponding component may already have been unloaded or errors not initialized.

  I'm sure that printf() is a shell command.  Also, while loading the file in sequence, it is likely that TestStand loading of DLLs or COM objects at the same time, which could conflict with a code that you have in DLLMain.

  Apart from that, Microsoft strongly recommends against any unnecessary code in DLLMain.  If this problem only may not be something to do with the products NOR, but more practical copies creation of DLL in general.

• Error 1097 when calling DLLS in LabView

  I get an error 1097 when calling the LabVIEW provider library. Curiously, the error, the DLL routines still seem to do what is asked of them.  This is the test code.  It opens an Ethernet connection to a controller of axes Galil, he asks (possibly) the value of its internal clock, and then closes the connection.  Each call library function returns error 1097 but "valve function" I32 error number is always zero. Open function causes the connection to be opened, the command function causes the send command and receives a reasonable answer, narrow funtion seems to cause the connection to be closed.

  

  Here is what I see when I run the test:

  

  Also directly configure call-library functions, as I did in this VI, I also tried using the import-shared-library Wizard to create a vilib of functions of the DLL and I get the same behavior and errors when I use these functions.  I tried to tweak some of the data types in my configured manually call library functions to see if I could find a combination that worked better with the library, but had no luck there.

  I use the x 86 version of the DLL with v2014 LabVIEW 32-bit on a 64 bit windows system 7.  I see that the error on the two computer systems of different work configured in this way. I see a similar error on a home computer with just the RTE of 2014 installed. The manufacturer says they can not reproduce the error. I always saw the error over multiple versions of their library DLL.

  In the attachment ZIP it has a link to the DLL library on the manufacturer's website. There is also a copy of the VI, the DLL and a large part of how-to-use documentation that accompanies the DLL.

  I was hoping that someone who was familiar with the use of the call-library function might take a peek at what I do and see if an error could be spotted.

  Unable to find an error, I did, I would be happy to suggestions on how I could solve this. Little seems to me like there may be a problem with the library. The manufacturer, Galil, said that they have opened a log with OR to see if NEITHER could help but since Galil said they can not reproduce the problem and provide an example of the NC, it really went anywhere.

  Given the decoration of symbol names as exported by the DLL I "m convinced that you must change the stdcall calling convention.

• Calling DLLS in LabVIEW

  Hello

  Below is the code written in LabWindows in which dynamically access a Dll using Windows API LoadLibrary(), GetProcAddress(), and FreeLibrary().

  Successfully, I could load the library and get the procedure address using library calls node in LabVIEW. But got stuck after that.

  As I am not good in C/C++ coding, ask someone to really help me to write the same thing in LabVIEW.

  Kindly do the needful.

  #include   // Function prototypes.
  #include     // CVI Active X definitions.
  #include 
  #include    /* Needed if linking in external compiler; harmless otherwise */
  #include 
  #include 
  
  typedef long __stdcall( *OLECREATEOBJECT)(char*);
  static  HINSTANCE  Hinstlib;
  static  long  gvntISystem;
  
  long CviCreateFastObjects (void)
   {
  OLECREATEOBJECT procAdd;
      pStrTempmem      = (char*)CA_AllocMemory(1);
      Hinstlib = LoadLibrary("FastTrio");
      if( Hinstlib != NULL)
  {
          procAdd = (OLECREATEOBJECT) GetProcAddress(Hinstlib, "OLECreateObject");
          if(fRunTimeLinkSucess = (procAdd != NULL))
  {
          gvntISystem = (procAdd)("FAST.IMFASTSystemInterface");
          return 0;
          }
          else
          return 1;
          }
      else
          {
  return 1;
          }
  }
  

  All the information you need are in the C code.

  • OLECREATEOBJECT is typedefed just after all the #includes at the top.  It returns a long integer (typically I32 in LabVIEW, but could be I64 on a 64-bit operating system) and takes a string as input.  It uses the standard windows calling conventions, not the C calling convention.
  • LoadLibrary and GetProcAddress are used to get a pointer to the function (procAdd).  This is handled in LabVIEW, by filling in the location of the library and the function in the call library node.
  • The library of appeal in LabVIEW node must also be set to the standard calling convention and return value (I32) and list of parameters (a string) must be set.
  • the function is used to set gvntISystem with a constant of entry 'FAST. IMFASTSystemInterface ".  In LabVIEW, a constant string of wire at the entrance and read the return value.
  • You can implement the audit, thus using the call library errors node error output.

  Good luck!

• Problem in the call dll c ++

  Hello

  I have problems to make a dll written in c ++ to work when called in LabView. I don't have the source code, but I know it works because I tested it with a demo of Visual C++. I get an error of 1097 the first time I call and no error at any time after that. However, the dll does not seem to do anything. I have attached the header file and my code labview below.

  Edit: I can't download attachments so I'll post screenshots

  relevant part of the header file:

  #ifndef

  #define

  #include

  using

  #ifdef

  extern

  #endif

  #pragma pack (1)

  typedef

  } LicenceDate;

  LicenceDate displayed;

  } SoftwareLicence;

  LicenceDate displayed;

  } EsessionLicence;

  #ifdef

  SoftwareLicence & PSoftwareLicence,

  EsessionLicence & PESessionLicence);

  

  

  You cannot really the interface call this function directly to the library node. The problem here are the string parameters. Who are the C++ object model classes, something only the C++ compiler that created the DLL can guarantee to manage properly.

  People using C++ must understand that the use of C++ objects in the interfaces parameter takes a DLL basically almost certainly unusable for any other compiler that was used to create the DLL. It can be even as bad as requiring the same version of the compiler, because there is basically no binary standard on how to pass objects C++ functions. Maybe that C11 sets something but most modern C compilers are struggling even to conform fully to the C99 standard which, as its name suggests, came out in 1999 (with a few addenda released in 2001, 2004 and 2007).

  string to a type of C++ template was even more complicated than just the binary object interface, as every compiler comes with its own header designed template classes.

• "Mesa.dll is not found" from CVI 2010 installation

  When I launch an executable file that has been installed from a distribution kit created with CVI 2010 (360), I get the message "Mesa.dll is not found." But I do not see that the file is installed in C:\Program NIUninstaller Instruments\Shared\Mesa.  If I replace this file with a mesa.dll more than a previous version of the CVI, my newly installed executable launches properly.

  Hi mrtqs,

  While testing on this issue, I came across a similar problem.  From my understanding, the CVI Run - Time Engine will also install of VS 2008 C++ Runtime parts.  According to that the CVI Run Time options you choose to install a different part of the runtime C++ 2008 VS will be included in the installation.  It seems that Microsoft has been able to modify the runtime C++ VS 2008 for some parts, but not others, which is what causes the problem.  As a result, there are a few options:

  1. install the runtime full CVI with default settings

  2 leave out the ActiveX module if does not necessary

  3. install the runtime C++ 2008 VS separately on the deployment computer.

• Call dll error 1097

  Hello

  I'm reading the data from a capture card in my slot PCIe card. When I call the "Initialize" function from the .dll file that I got with the card, I always get error 1097. 1097 means that the called function threw an error. When I run the program supplied with the acquisition card, the acquisition card still works.

  If I have everything just omit the "initialize" function call and continue with the function that will be called after the "Initialize" function, LabVIEW block (program stops without any warning).

  I also had a LabVIEW program that uses the dll that was supposed to work. But here I get the same error.

  Do you have any idea what normally causes this behavior and how can I solve this problem?

  I have the second post of nathans. 1097 error is almost always an error in the configuration of the right to call library node. And in some cases, there is no right to set up and you need a wrapper DLL to convert between what the library node call allows and what needs your DLL. The reason why it works sometimes and other times not, actually is that it never really works, but sometimes the error that gets caused cannot be detected by the operating system and LabVIEW does not get an exception according to. This can change according to LAbVIEW version, runtime system or development and even recompilation of the code after the small seemingly unrelated changes in demand.