Calling DLL FMI Objects in Labview

Hello,
         I am working with Functional Mock Up Interface between Modelica and Labview.
         I have made an FMI Program and now comes the tricky part of Porting it to Labview(We use RT Target with a PCIe6343 Device).
         The easiest and simplest direction i took was to convert this FMI program(written in C) into a DLL.
          Now this FMI program uses FMI objects and FMI functions for data handling.
         My first out of many questions is.
         1.Can i Call a Function specified in The DLL to create an Object in Labview.?
          2.How to get to creating an Object via a C DLL.
             Regards
          Raghu

Hi Raghu,
you cannot directly access global variables that are declared in a DLL from LabVIEW or any other programming environment. The easiest solution for this is to add functions to your DLL which provide dedicated reading and writing access to those globals to external callers.
Using C++ instead of LabVIEW will therefore not resolve this issue, as you still need to define data i/o functions inside the DLL to access the global variables.
But before you start re-engineering your model DLL to include these functions, you might want to re-evaluate the concept of your mock-up interface. From my understanding, a FMU provides the simulation functionality only (give the model some inputs, wait for the calculation to finish, read back the outputs), which can be called through a standardized interface from a quite complex simulation framework. The framework provides data generation and storage, i/o with the simulation model, data visualization and logging. Although writing such a framework in LabVIEW is possible, I would not recommend doing so alone, as you will probably need several month just for concept design and programming.
So from my point of view, the only sensible way to go would be to see if your existing simulation framework has an interface (ActiveX, .NET, OPC, TCP/IP low level, ...) that allows you to share data other programming environments. This way, you could implement the user interface in LabVIEW and send the user-changed parameters to the simulation framework, which then forwards them to the model. The model's outputs are then read back from the framework and will be passed to your LabVIEW application, which visualizes them for read-out...
Best regards,
Sebastian

Similar Messages

Call dll in labview

"Hi All,
I have to get data from USB camera, I have following functions in DLL.
DLLINOUT HANDLE WINAPI CC_Open( LPCSTR CameraName , ULONG CameraNumber , CC_CAPTURE_MODE CaptureMode ) ;
and
DLLINOUT BOOL WINAPI CC_CaptureSingle( HANDLE Cam , PVOID Buffer , ULONG TransferSize , CC_TRIGGER_MODE TriggerMode , USHORT TimeOut , OVERLAPPED * pUserOverlapped );
When I open hardware with function cc_open I am getting handle to an object. How can I store this object and pass it to CC_CaptureSingle function?
Another question is when I call CC_CaptureSingle I am getting pointer on the 2 dimension array �PVOID buffer� how can I get this array in Labview?"

hi,
you can do this two thing.
1. Create your new DLL with (your DLL will call camera's DLL) one big function my_capture_image() and insert you do CC_Open(), CC_CapruteSingle() and CC_Close(). And to LabView you pass only Array whit image data. And you don't have problems with HANDLE. But you must allocate memory for image array in LabVIEW before you call this DLL!!! [Or use LabVIEW C function for reallocating memory]
2. You must identify type of HANDEL variable. And you can change type of this variabile. But when HANDLE variable is structure it is hard pass this structure to LabVIEW.
If you use LabVIEW 7.1 look example 'Call DLL.vi' it is great!
Have a nice day.
JCC

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.

"HOW to use Labview call Dll compiled by VC++"

"hello,I use VC++ compile a DLL,and i want to call DLL Function in LABVIEW program.But there is a dll function
when i call it in labview.There is error.The prototype of Dll Function that make error is "USHORT DLLFUN __stdcall IBWRT(unsigned short dev_address,const char *pstrWrite)",The second paramenter is a char pointer,
and the paramenter pass a command which content is
"MEASURE:CURRENTC? 1A,0.001MA".
When i use VC++ to call this function,i program followed:
CString m_wrt;
int ReturnW;
m_wrt="MEASURE:CURRENTC? 1A,0.001MA";
char buffer[40];
strcpy(buffer,m_wrt);
ReturnW=IBWRT(4,buffer);
and this call is correct.
But when i use labview to call this function.ther
e is
error.So, who can help me,to tell me how to call this
function.Thanks."

Are you asking about porting code or calling C++ code in LabVIEW? As far as porting code, there's no easy way to move code back and forth between LabVIEW and C++. However, if you are trying to call C++ code in LabVIEW, you can compile it as a DLL and call it in LabVIEW using the Call Library Function node.
Chad B. » National Instruments » ni.com

Calling Dlls from LabVIEW

LabVIEW Gurus:
I am working with some software engineers who have no experience in LabVIEW. Unfortunately I have little experience in C/C++ to make sense of their inquiry.
Basically we are dealing with “Data Marshalling”. I will call a DLL and issue a command (string) and get back a 2-D array and an integer. So far so good.
The C/C++ programmer requested that I provide them with a pointer/memory address in which they will store data, so I can read it once the dll returns the array and integer. I browsed through the example online http://decibel.ni.com/content/docs/DOC-1690 and thought that if I wanted to read from the dll, the process is a simple as calling the appropriate function and configure the parameter (no pointers needed).
So, is there a specific way that they need to write the C/C++ code to be used in LabVIEW? Or what else to I have to take into consideration?
Thank you,
Santiago

That example is pretty simplistic as it only deals with integers. In this case no pointers are required since everything is returned by value. When you're dealing with arrays, however, you need to deal with pointers. If you open the Example Finder (Help -> Find Examples) and search for "dll" you will see the "Call DLL" example. That contains many examples of how to call DLL functions with a wide variety of datatypes. I strongly suggest looking at that example. There is also a chapter in the LabVIEW Help on calling DLLs (Fundamentals -> Calling Code Written in Text-Based Progamming Language).
You have 2 things to consider:
You're dealing with arrays - this means you typically need to pre-allocate the memory in LabVIEW, and it sounds like that's what the DLL expects you to do. This amounts to using the Initialize Array function to create your 2D array of the appropriate size and datatype.
You may be dealing with a C++ DLL. LabVIEW can only interface to C DLLs. This doesn't mean that you can't create a DLL in C++, but it does mean that the C++ programmers need to add an extern "C" modifier to the function calls, otherwise you get name mangling, and LabVIEW won't be able to call the DLL. The DLL programmers should know what that means.

Calling DLL using LabVIEW 7.1

so, i have this DLL which might be compiled using Visual Studio 2003 or Visual Studio 2005.NET.
question is: Can i call DLL functions using LabVIEW 7.1? has anyone tried it and has any issues loading the DLL?
i think i have everything right, as far as the configuration of 'Call Library Function Node' is concerned, but i get the
'error loading DLL - application has failed to start because application config is incorrect'.
can you please verify if .NET is not causing me issues? i think DLL assembly should be the same wheather it's VStudio6
or .NET, but can anyone confirm that's not the issue? Thanks...

Yes.
If you dll is generated by C/C++, using Call Library Function node.
If it is generated by .net, using constructor node.
http://forums.ni.com/ni/board/message?board.id=170&message.id=206959#M206959

Labview fails to call dll after Migration from 2010 to 2014

An error 'Failed to load dynamic library because of missing external symbols or dependencies or because of invalid file format' occures everytime the labview framework tries to call dll. Has anybody come across this problem before.???

priyanka0101 wrote:
[...] But this dll consists of APIs which [...]
This sounds as if the DLL requires some other components, most likely other DLLs. Is it possible that these are not installed on the target machine?
Do you run LV 2010 and 2014 in parallel on the same machine for checking?
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Does anybody can give me a simple example about the labview programme calling dll ?

Does anybody can give me a simple example about the labview programme calling dll ?And the dll is also writed by using labview .I just want to study the process of the labview programme calling dll file.Thank you!

Hi,
Please click on "Find Examples" in the "Getting Started Window"
A window named "NI Example Finder" will pop up.
In this go to "Search" tab
Type "DLLs"
You will see a lot of examples.
If you're online, you'll see user examples too...

CALLING DLL: Labview or CVI?

I'm going to start a new project using Testand and Labview or CVI. In this project I will make a lot of calls to C++ functions packed at a DLL file. The Dll was prepared and compiled using MVC++.The function prototypes are not simple & contain structures, pointers and typdefs's.
Is it possible to call the functions from Testand,Labview,CVI?
Is it easier to call the functions from CVI compared to Labview?
Thanks,
Ofer

ofer_o wrote:
I'm going to start a
new project using Testand and Labview or CVI. In this project I will
make a lot of calls to C++ functions packed at a DLL file. The Dll was
prepared and compiled using MVC++.The function prototypes are not
simple & contain structures, pointers and typdefs's.
Is it possible to call the functions from Testand,Labview,CVI?
Is it easier to call the functions from CVI compared to Labview?
Thanks,
Ofer
Jon already mentioned that CVI will be a lot easier to deal with this than LabVIEW.
BUT!!! Make sure the DLL exports standard C functions instead of C++.
LabWindows CVI (and LabVIEW even more so) can only link to globally
exported C functions. C++ classes are completely out of reach for both
and C++ compiled global functions have both the problem of taking
sometimes C++ parameter types as well as the name decoration added by
the C++ compiler to all function names.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Portage d'un appel de DLL en DELPHI vers LabVIEW

Bonjour,
Je suis en train de porter un programme DELPHI en LabVIEW.
Dans ce programme DELPHI, j'ai un appel de DLL (dont je n'ai pas les sources, mais vraisemblablement écrite en C), que je n'arrive pas à transposer en LabVIEW :
prototype de la fonction en DELPHI :
procedure EXAMPLE_FCT (
     const PARAM_IN_1: byte;
     const PARAM_IN_2: byte;
     out PARAM_OUT_1: Byte_Array_T;
     out PARAM_OUT_2: cardinal); cdecl;
external 'nom_dll.dll';
(Byte_Array_T est un tableau[1..200] de cardinal)
J'avais pensé parametrer le "Call library function node" de la façon suivante :
- convention d'appel C
- paramètres :
   PARAM_IN_x : type numérique; constante; type de données: entier 8 bits non signé; Passer par valeur
   PARAM_OUT_1 :type tableau; type de données: Entier 32 bits signé; Dimension: 1; Format du tableau: Pointeur sur les données du tableau; taille minimale : <none>
   PARAM_OUT_2 : type numérique; type de données: Entier 32 bits signé; Passer par valeur
Cela ne me renvoie pas d'erreur, mais rien ne m'est retourné dans les paramètres de sortie...
Quelqu'un saurait il parametrer correctement le "Call library function node"?
Merci d'avance,
Christophe

muks wrote:
Translation
function prototype in DELPHI:
proceedings EXAMPLE_FCT (
     const PARAM_IN_1: byte;
     const PARAM_IN_2: byte;
     PARAM_OUT_1 out: Byte_Array_T;
     PARAM_OUT_2 out: Cardinal); cdecl;
  external 'nom_dll.dll';
(Byte_Array_T is an array [1 .. 200] of Cardinal)
I thought might set the "Call library function node" as follows:
- C calling convention
- Parameters:
     PARAM_IN_x: numeric; constant data type: 8 bit unsigned integer; Pass by value
     PARAM_OUT_1: array, data type: Full 32bit signed; Size: 1; Format table: Pointer to the table data, minimum size: <none>
     PARAM_OUT_2: type digital data type: 32 bit signed integer; Pass by value
Christophe
French Board
First PARAM_OUT_2 needs to be passed by Reference (Pointer) as it receives a value from the function.
Second stdcall might or might not be advisable here. Not sure what Delphi uses as default but I would have guessed they would use stdcall, unless if it is for the sake of being different than Microsoft default.
Third you do need to allocate the array on the LabVIEW diagram using an Initilize Array Node. DLL Functions normally need all their parameters being provided by the caller unlike when working in LabVIEW or some more object oriented programming environments where the compiler does take care automatically about that. But when using the Call Library Node this does not apply since the shared library function calling mechanisme has no way of indicating to the caller anything in this direction, so the calling application can not take automatic measures for you.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How can I call a COM object from a PL/SQL CODE

Hi everyone,
Does anyone know how to call a COM object from a stored procedure in oracle.
a sample of code
please help,
Hilaire

Are you familiar with external procedures? Basically, you can expose functions exported by a shared library (i.e. a DLL on Windows) to the Oracle database. My assumption is that you'd probably need to write a wrapper DLL around the COM object, since I believe you can only pass fundamental data types back and forth (i.e. no object references). You'd expose the method(s) of that wrapper DLL to the database via external procedures.
Justin
Distributed Database Consulting, Inc.
www.ddbcinc.com/askDDBC

How can we call a C program in Labview

Hi
a) In one of our application we have to call a C progran in Labview. I am not able to call it. Can somebody help me.
b) When we call a C program ,is Labview makes block diagram for it.
Please reply
Thanking You

hi there
well, then we need more information what you mean with a "C program". are you talking about C source code, a command line executable, a high end executable with a GUI, a dll, ActiveX.... what are the parameters you have to pass? what parameters are returned from the "C program"? please post some code....
as a startup you could search the examples shipped with LV. open the example finder from the runtime menu.
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"

The problem about call dll from VB....

Dear All.
I have a device and VB dll file.I want to use labview to call dll.But Labview show "An Exception occurred within the external code ..."
Below is to call this dll details.
1、FindHardware：
Call it at beginning when load program first, it can let program auto detect printer port address and model of dso scope.
parament
winversion：
winversion = 2 "Windows NT,XP"
UIP: open UIP(2048) array
UCP:open UCP(1023, 1023 + 11, 6) array
return：
board_model：
dso2902_128 = 27
Then is my program
Could somebody tell me what's wrong?
Attachment file is this dll.
http://us.f1.yahoofs.com/bc/500cf3ac/bc/dll/dll.rar?bfd1QSDBkHPgKI9c
Thanks.
由 Samyang 在 10-09-2005 07:14 AM 上編輯的訊息

I can't say I understand the documentation snippet you provides, and I also can't access the DLL, but here are a couple things...
1. I doubt very highly that a VB DLL is built with the C calling convension. I believe you should try the stdcall instead.
2. You have the winversion being passed by pointer, but the docs make it look like a regular integer. Is that correct?
3. Your board model is being passed by value, but it is listed as a return value in the docs. That would indicate an actual return value or a parameter passed by reference.
My guess is that one or more of the above is causing the stack to get corrupted or an invalid pointer to be accessed and that is generating the error. Is there anyway to see the document (pdf or webpage)?
Brian Tyler
http://detritus.blogs.com/lycangeek

Imlementing synchronized access to shared objects in LabVIEW OOP

Many objects in object-oriented programming have an
identity, such as a file, a front-panel object or a hardware device.
These objects cannot be modelled using present LabVOOP (LabVIEW Object Oriented Programming) objects as
LabVOOP objects gets copied as wire is branched; multiple different
wires cannot all represent a single object. This issue has been
irritating the community of LabVIEW users since the release of LabVOOP
a few months ago.
It seems that there is a huge demand for
objects with unique identity i.e. by-reference objects in LabVIEW. The
central problem why LabVOOP propably doen't have these objects is the
difficulty in implementing synchronized access to these objects from
multiple parallel threads. The problem of synchronized access can be
divided into two different separate topics. First how the
sychronization should be implemented in LabVIEW runtime engine. Second
how this synchronization mechanism should be visible to the developer.
I'd like to start this thread to discuss these two issues.
Synhronization under the hood
Traditionally
people talk about locking of an object and about get-modify-set pass
when accessing the object. Locking is traditionally done by acquiring a
mutex for an object, modifying the object and releasing the mutex so
that other threads can access the same object instance. This is how
inter-thread synchronization is traditionally done. However, besides
the mutex based locking, the computer science community has innovated
also different kinds of methods on synchronizing the access to objects.
One way to get object-level synchronization is modify the
runtime engine so that it only allows a single method of a synchronized
object to run at any time. This mechanism of syncrhonization is
implemented in programming languages like O'Haskell, which is a Haskell
variant with object orirented features.
Also different
transactional mechanisms[1,2] have been successful. In transactional
mechanisms multiple threads are allowed to access a synchronized object
simultaneously. As each method accessing an object commits their
changes, they verify that no other object has modified the object
simultaneously in a manner than would break the transaction. If such a
modification has occurred, everything is rolled back. Transactional
mechanism do not suit to every possible situation as not everything can
be rolled back. For example it's hard to roll back an action that
somehow modifies the physical world.
User experience of synchronization
How
the synchronization is generally implemented in LabVIEW shouldn't be
directly visible to the developer end-user. The developer should
understand the general concepts of synchronization to take full
advantage of it, but in general the synhronization mechanism should be
integrated directly to development environment. There should in general
be no need to acquire a mutex by calling acquire mutex node but instead
the end-user should be able to specify which data needs synhronized
access in more sophisticated way.
In the following I propose a
mechanism of integrating the synchronized access of by-ref objects to
the development environemnt of LabVIEW. The proposal is very
preliminary but I hope it breaks the ice and the community would start
innovating in how should NI implement the syncrhonization support in
the user interface of LabVIEW.
Wire level synchronization
Only
methods can access object private data members. In synchronized access
to the object, it's the methods accessing the private data members that
need to be synchronized. The private data members are accessed by
applying unbundle node to the class wire and data is written back to
the object using bundle node.
What I propose is the following.
An unbundle node could either be normal or "synchronized". A
synchronized unbundle would guarantee the access to the private data
members in synchronized manner. All data wires originating from
synchronized unbundle would be of synchronized type, in a little
similar manner as a dynamic dispatch wire is of special dynamic
dispatch type. Such a wire must evetually be connected to a bundle
node. When the wire is bundled back to the originating object, the
synchronization requirement is released.
These synchronized
wires would look somewhat different from normal wires so that the
developer instantly knows that the wire is synchronized. The developer
can branch the wire, but only one wire branch can own the synchronized
type. The developer could easily select which wire would be
syncrhonized by Ctrl+clicking the wire. Such a wire can be considered
as a combination of a data and a mutex, even though mutexes don't need
to be the underlying synchronization method. The wire just guarantees
that there is a mechanism in the runtime engine that makes sure the
access to the wire data is synchronized.
There is a need to wire
data originating from a non-synchronized wire to a synchronized wire so
that it can replace the private data member of the class. This is
accomplished with a new node similar to bundle node, that would allow
replacing the data in a syncrhonized wire with some data originating
from a non-synchronized wire.
The synchronized wire can be
connected to a front panel controls of special syncrhonized type. This
way the synchronized wire can originate from a method and allow passing
the synchronized data to the calling VI and back to another method.
This is practical for example in a situation when the developer wants
to run different analyzes to a data class but don't want to rewrite all
the existing data analysis tools as class members. So the developers
writes a syncrhonization acquiring getData method that let's the
calling VI to access the syncrhonized data. Then the developer passes
this data to an analysis VI and passes the result back to a setData
method that writes the result back to the class wire.
There
will probably be technical problems in allowing the user to connect
such a synchronized wire to all existing VIs since these VIs. Therefore
the programming model for all nodes that do not support such
synchronized wires will be branching the wire and passing the
non-synchronized wire branch to the node and then bundling the result
back to the synchronized wire.
To increase performance and
decrease unnecessary buffer copies when a syncrhonized wire is
branched, if the syncrhonized wire continues directly to the new bundle
synchronized wire node, no buffer copy is made.
Discussion
The
syncrhonized access to a by-ref LabVOOP objects can be implemented in
multiple ways by National Instruments. The synchronized access should
be divided to two different and independent parts: 1) the user
experience of synchronization and 2) the runtime engine synchronization
mechanisms. As LabVOOP objects have special properties compared to
other LabVIEW data types, optimal user experience can be gained by
designing the user experience specifically for LabVOOP objects. From
user experience point-of-view this syncrhonization mechanism may not
work for other data types. Separating object syncrhonization from
synchronization of other data types is advantageous also for other
reasons. Due to the fact that object data can only be accessed via
object methods, more advanced synchronization methods may be used with
objects than can be used with other data types. O'Haskell
synchronization implementation is an example of this. Integrating the
synchronization directly to the user interface allows NI to change the
mehcanisms under the hood, when computer science comes up with more
advanced methods. Therefore NI could begin with traditional and quite
easy mutex-based synchronization and later move to more advanced
perhaps transaction based syncrhonization methods or even combinations
of multiple different methods.
I hope this topic generates
discussion that would help NI to implement an excellent synchronization
mechanism in LabVOOP. I hope that all talented individuals in the
community participate this discussion to help NI to reach this goal. I
also hope that if you just have time, it would be great if you could
surf the computer science resources to find out what kinds of new
techniques there exists for synchronizing access to shared resources. A
Large community may find much more innovative solutions than a few engineers at NI. Let's give NI the power of open source design
Tomi Maila

Hello Tomi,
First, thank you for taking the time to write such a well
though-out suggestion. Are you familiar
with the “LabVIEW Object-Oriented Programming: The Decisions Behind the Design”
document? I think the reason we chose to implement a ‘by
value’ strategy, is that is more in line with the LabVIEW programming paradigm
of dataflow, and would make sense to most of our LabVIEW users.
I think your suggestion is interesting, and it does
highlight the need to think outside of the conventional LabVIEW box and look to
some of the innovative things other languages do. However, I think we all agree that
synchronization takes careful planning and extra work for the programmer. Even with an ‘ideal’ solution I see no way
around this. For LabVIEW users today,
one great way to get synchronized ‘by reference’ semantics with your objects is
to use a single-element queue to pass your object. The queue itself is passed ‘by reference’ and
is inherently synchronized! The does
have the disadvantage of adding one more small layer of complexity to your
program, but some complexity would have to be introduced in any situation. The other disadvantage with this is that it
is not always an intuitive way to implement your program and requires some
amount of LabVIEW knowledge before one would generally come across this
technique.
In any case, I appreciate the time and effort you put in to
your suggestion. Please make sure that
you submit the suggestion formally through the NI Product Suggestion Center so
that it can be reviewed by some of the decision makers here.
Thanks again,
Travis M
LabVIEW R&D
National Instruments

Calling DLL from BSP

hi,
Can anyone suggest me how to call a dll in a bsp. if you can help me with a sample code it'll be helpful.
Thnx in Advance
Vinodh

What exactly do you mean by calling a DLL? Do you want to host an ActiveX Control? Do you want to call a DCom Object or a .Net Object? Or perhaps you are wanting to call a WebService writting in .Net?
For a Native DCom Object or .Net Object your would need the SAP DCom Connector or .Net Connector respectively. For an ActiveX control, BSP is no different than any other Web environment - Client Side JavaScript or VBScript should do the trick. I'm sure you can google many an example from the Web.
If I am off base here, just let me know. Also this question might be better suited to the BSP forum instead of the ABAP one.

Calling DLL FMI Objects in Labview

Similar Messages

Maybe you are looking for