Simulink, Labview and DLL

Hi all,
I can communicate my model in Simulink with Labview using the SIT and without working in real-time. However,now, although I have made a DLL(Dynamic Library Link) with Simulink and my compiler, I don´t know how I could run it in real-time with my target calling the DLL.
This is, instead of using my model (*.mdl) in Matlab, I want to use the DLL but I don´t know how I must call it from Labview.
If someone could help me, I would be very grateful.
Thanks
Ziman.

Hello,
considering that you have recent versions of LabVIEW and SIT, you could do that ( run the model in an RT target ) using the SIT Connection Manager ( Tools - SIT Connection Manager ). In this dialog box, you will have to select Real-Time Target, insert an IP and choose the path to the Model DLL. Once configured, then click on OK button and when running the VI, it will download the model to the RT Target
If you open an example that comes with SIT called Sinewave ( Help - Find Examples ), you will have the information to run it in an RT Target in the front panel. For more information, here you have a link ( http://zone.ni.com/devzone/cda/tut/p/id/3583 ).
I hope this helps
crisR

Similar Messages

LabVIEW and DLL

Hi
I'm making a project based on video acquisition with NI-IMAQdx. The goal here, is to grab images from an USB webcam, converting the images to arrays of pixel values, and then exporting those arrays to a buffer, which is implemented in C. Due to that, I have the idea to sending those arrays of pixel values continuously to a DLL file as an output, so I can catch them continuously with an external C-program and directly export the arrays to the buffer from the DLL file. As can be seen in the block diagram, I managed to export the arrays continuously to a .csv file, and I want exactly the same procedure to a DLL file, but don't know how to do it.
Best regards
Oesen
Attachments:
Transmitting___1.vi ‏50 KB

Hi Dennis
I have builded a DLL file by creating a project from this VI, and then choosing "Shared library DLL" from the build specifications. I only want the arrays in this DLL file. I have figured out, that I also can use those two blocks in the block diagram shown on the picture. What is the benefits of using them ?.
Best regards
Oesen

How to distribute the serial core only with my exe and DLL application using the Labview application builder 8.21. I'm not interested having MAX and other components installed on the customer PC and in the program menu

Since Labview ver 8.0 and later, I am not very happy with the new way the project installer is managing the additional drivers such as Serial.
With LV 7.11 the serial components was included in the cab file and was installed on the target computer in a specific directory. The size of the distribution was pretty small and well suited for compact distribution.
My LV application use only the serial object and with LV 8.21, if I include the serial 3.2 component, I get an enormus file including max, visa ... and a lot of fucky component I do not need.
To distribute my application, I just need, the runtime engine and the serial driver as it was with the version 7.XX
Looking for clever advises from you gentlemen!

Thanks Dennis for you input
My problem is in fact very simple. 3 years ago, I developped a software suite for X ray generator; My company is selling such generator all over the world and our control panel software and DLL (for OEM integrator) is based on Labview professionnal development plateform.
To drive our generator, we just need to transfer ascii data using the strandard RS232 port still present on most of equipments used in the industrial area.
Until LV version 7.11, there was no problem to include serial component in my distribution with a very reasonable size and transparency for the end user.
with LV 8.xx (preparing a new release), I'm very disapointed to see, my distribution is increased of about for 10 Mo to 180 Mo just because I increase the serial component.
May I mix a previous version of the serial component with LV 8.21?
Should I change my source to Visa instruction only and merge visa runtime only to my distribution?
is there any simple serial example based on visa and distributed with th application builder?
I will appreciate your help in order to optimize my distribution
Pascal

Creating a LabVIEW Shared DLL for use with C# and Strings?

Hi All,
I am trying to create a prototype for a LabVIEW Shared DLL that all the VI does is take in a string and return an upper cased string. Needless to say the DLL builds fine but when I try calling the shared DLL from C# the .NET application recieves an exception about "Ansi char arrays can not be marshaled as byref or as an unmanaged-to-managed parameter". Does anyone have an example of how to pass a string to a VI and return a string or an example of a better way of accomplishing this.
We are using labVIEW 7.1 on Windows 2000.
I am in quite a bit of a hurry to prove that this type of a LabVIEW Shared DLL VI would work. The eventual system will be passing in a string of XML with a large amount of
data and returning XML.
Thanks in advance,
Jim

Hello jprucha,
This occurs because LabVIEW DLLs are not considered managed code. As such, we need to define the C# function as unsafe to be able to call unmanaged DLLs.
You can find more information about C# and managed code at Microsoft's developer website linked below.
MSDN Home Page
Good luck with the development,
Matt F
Keep up to date on the latest PXI news at twitter.com/pxi

Create DLL from labview and calling it from other application

I have an application built using Labview. I wanted to create DLL out of it. The application has
two String inputs start and stop buttons and two status indicators.
1. How to itegrate start and stop buttons from function prototype?
2. Does Labview created DLLs requires labview runtime engine when it is to be called from other application?
Can some one help on this.
Solved!
Go to Solution.

Hi Yuvish,
1) They should be boolean inputs to your VI. But does it makes sense to provide a stop button input at the start of your VI? (THINK DATAFLOW!)
2) Yes, the LV-RTE is needed...
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

Labview Calling DLL with 2D array input and output

Hi all，
    I have to call a dll which a 2D double array as an input and also a 2D double array as an output.The dll is made by me and written in c language , I need it to work  efficiently.
If i define the program in labview like this
The 2 2Darrays sent into CLN were "Array data pointer",then how to define the function in c laguage? just like -----int myfunction (Parameter1,Parameter2,Parameter3,Parameter4)
If the function in the dll is defined like this         int myfunction (double **A, int sx,int sy ,double **B,int ix,int iy),then what will the program in labview will be ?
sx ,sy ix ,iy are the array's size.

ylongwu wrote:
If the function in the dll is defined like this         int myfunction (double **A, int sx,int sy ,double **B,int ix,int iy),then what will the program in labview will be ?
sx ,sy ix ,iy are the array's size.
Your proposed prototype double ** seems to indicate that you want an array of pointers to the rows of the array. That is not how LabVIEW stores multidimensional arrays (nor how this is usually done in C for such arrays).
LabVIEW and most C libraries threat multi dimensional array as one single block of memory where the rows are located one after the other. So as DFGray has already pointed out you should use double * instead as datatype or since you create the DLL yourself and if it doesn't need to be compatible with other environments than LabVIEW change that altogether into:
typedef struct {
   int32 dimSize1;
   int32 dimSize2;
   double elm[1];
} 2DDblArrRec, **2DDblArrHdl;
int myfunction (2DDblArrHdl A, 2DDblArrHdl B);
then change the Call Library Node parameters for the arrays to pass the array as Data Handle (the native LabVIEW datatype) and leave away the extra dimensions since they are already inside the handle structure.
Last but not least if you want to be very fancy you can even use NumericArrayResize() on the output handle to resize it to the correct size before filling in your information and leave away the Initialize Array function on the LabVIEW diagram.
Message Edited by rolfk on 05-26-2010 09:11 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

"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

Question about LabVIEW generated DLL's

Hello,
I want to try programming games in either JAVA or FLASH.
What I want to know is if I can use the LabVIEW generated DDL's for use in my games, without having to need the LabVIEW runtimes installed.
(in other words, are the LabVIEW generated DLL's, stand alone DLL's as generated in for example C/C++ or other programming languages?)
Second, how good is LabVIEW in converting it's code into a DLL. Can I make complicated algorithms, or are just simple functions allowed.
Hope you guys can spare a few words on this topic.
Sincerely,
Heinen
The Enrichment Center is required to remind you that you will be baked, and then there will be cake.

Hello dan_u and thank you for your quick reply.
If the LabVIEW Runtimes are needed to use the DLL's, that is not a good option for me then. I eventually want to distribute my games over the internet, and having to sent the LabVIEW runtimes with the games is just not an option.
To bad, I'm better in programming stuff in LabVIEW then in writen C++ like code.
Sincerely,
Heinen
The Enrichment Center is required to remind you that you will be baked, and then there will be cake.

Large applications - Labview and other programming languages

Hello Labview Users,
as the forum saw this very interesting thread about large applications programmed in Labview
(see: http://sine.ni.com/niforum/niforum?requireLogin=False&forumDU=http://forums.ni.com/ni/board/message?... ) I would like to ask the community about their experiences with Labview applications in combination with other programming languages.
In advance: I have several years of experience in programming Labview applications starting from quick-and-dirty solutions which had to run within few hours and complex test solutions. I saw Labview growing and becoming better with the released versions and lot of things I missed in former times got implemented in the meantime. Actually I have to develop a complexe ATE solution with numerous equipment to control and numerous data to be captured and archived. Despite the Verison 8 I still feel still some drawbacks of the LV concept which let me hestitate to setup the solution completly in Labview:
1) It is alway hard to re-use code of complex applications since it is not possible to do some kind of global search an replace of functions
variables etc. It nearly impossible to re-use approved code structures (e.g a state machine) if the "inner part" is changing more the a little bit.
2) If the application requires a certain flexibility (e.g. exchangeable test equipment of varying vendors) this is hard to implement since you have to define a lot of parameters through your hierarchy if you dont want use global variables which slow down your application and hide
the code functionality.
3) Despite modern PCs the look and feel of LV applications appears somewhat slow compared to other applications. For complex user interfaces the polling methode generates a lot of complex code. (I dont have expierence with the event-structure).
Now my questions:
Do you have experience of implemention of complex solutions dividingthe code modules using Labview and other languages? Which other
languages did you use? Why did you use these languages (speed, flexibility of text based code, available library functions)? Did you found out this to improve your development time and code maintainibility?
(I concider a solution where I do the single tests with Labview-VIs but delegate all the test sequencing and data collection stuff written in PERL which allows really very compact code)
I'm curious what your experiences are.
rainercats

Given that you're asking these questions in a forum for LabVIEW users the opinions given are going to be somewhat slanted towards the general like of LabVIEW. I've been working with LabVIEW for a long time, ever since 2.something on a Mac. I've written numerous large-scale applications as well as "mundane" instrument drivers. As you've noted you're experienced with LabVIEW, so you know some of its strengths and weaknesses.
To address your specific questions:
(1) Yes, that has always been a limitation in LabVIEW, but I don't believe it is an overriding one to choose C over LabVIEW. Putnam provided one workaround for the search and replace of VIs. Once you've programmed in LabVIEW long enough you get used to doing it this way. Is it clumsy? Yes. As for the re-use of code structures, that's not entirely true. You can create a "template" VI (a regular VI, not a .vit) that contains the code you want to re-use and place in your palette with the "Merge VI" option set. That way you can select it from your functions palette, plop it down on your diagram, and you get the "template" VI's diagram placed right into your new VI.
(2) This is not something that is specific to LabVIEW, as this exists with any programming language. It's not the language that limits you here, it's how you've designed your code. In a language like C++ you would go with classes. You can do the same thing in LabVIEW. IVI is another option (though not preferred by me).
(3) As Putnam mentioned, you should be using the event structure.
Other thoughts:
The biggest strength I see with LabVIEW is that each VI is a miniature program, which allows development and debugging of functions a snap. With a language like C you have to write another program to call that function in order to debug it. The biggest weakness? I would say user interface. Yes, even with the event structure. Don't get me wrong, the event structure has vastly improved the way user interfaces and event handling in general are done with LabVIEW, but it simply doesn't hold muster to a program written in C or VB. ActiveX anyone? LabVIEW still doesn't do ActiveX properly in terms of actually getting the controls to work. Programming ActiveX controls is just plain aggravating what with all the property nodes taking up so much diagram space.
It certainly makes sense to use the best tools available to you to get the job done. In my recent projects I had to write software to run automated tests on some products my company made. The test modules were written in LabVIEW. The tests executive was a proprietary engine driven by a SQL Server database. I had to write a "wrapper" DLL that interfaced between the LabVIEW code and the executive since the executive hadn't been designed to call LabVIEW DLLs directly. This allowed us to use LabVIEW as the preferred language for developing the test modules and let the guys who were fiddling with the test executive do their bit. Of course, TestStand's premise is basically that.

Using tlb and DLL

Hi,
I was wondering how to use a tlb associated with a DLL in Labview. I know the tlb has the function and bject prototypes and the DLL has the actual code. Now question is, how do I create an object according to the tlb and the use this with the DLL? Thanks
Yohan

more specifically...
The .tlb contains an interface (eg: ITestInterface) that is implemented by the .dll using the (visual c++ 8.0) "implement interface" on a class defined in the .dll (eg: CConcreteTest)
The project that created this is a visual studio 8 c++ .dll project. There is one interface defined and a separate class that uses the "implement interface" option in vc8.
--> when importing this .tlb and .dll into a visual c++ project: I use a COM smart pointer (of type ITestInterfacePtr) and call the CreateInstance() function using the name of implementing class.
Also,
This is the code to load the .dll and
.tlb:
#import "..\drivers\vna\debug\vna.tlb"
no_namespace
IcVNABASEDriverPtr pVNA;
HRESULT hr = pVNA.CreateInstance("VNA.RS_ZVC");
pVNA->setAddress(20);

Error Code "1097.....this might corrupted LABVIEW's memory.........." appears after exit the labview and re-start labview

        I have a probelm when I use the "tool/import shared library(.dll)" wizard to generate the API from C.
        The API works correctly when I complete the wizard, but after I exit labview and re-start labview to run the API again. The error 1097 code "......this might corrupted LABVIEW's memory.............."appears.
        The only solution now is to re-generate or update the wizard to generate the API.
        I try to find the answer in
        http://digital.ni.com/public.nsf/allkb/58596F5D41CE8EFB862562AF0074E04C?OpenDocument
        The paragraph in above article shows
         "LabVIEW does not crash until it is closed
The most likely problem is that the DLL function being called has corrupted the memory. If you pass arrays or strings to the DLL, the DLL function cannot dynamically resize the array. Writing beyond the last element of the array or string could corrupt the memory and this may not be obvious until LabVIEW is closed."
But it doesn't match my case. Does someone have idea about this? I Attach my .h file for reference
Attachments:
test_api.h ‏1 KB
link_test_api.h ‏1 KB

wewe1215 wrote:
        I have a probelm when I use the "tool/import shared library(.dll)" wizard to generate the API from C.
        The API works correctly when I complete the wizard, but after I exit labview and re-start labview to run the API again. The error 1097 code "......this might corrupted LABVIEW's memory.............."appears.
        The only solution now is to re-generate or update the wizard to generate the API.
        I try to find the answer in
        http://digital.ni.com/public.nsf/allkb/58596F5D41CE8EFB862562AF0074E04C?OpenDocument
        The paragraph in above article shows
         "LabVIEW does not crash until it is closed
The most likely problem is that the DLL function being called has corrupted the memory. If you pass arrays or strings to the DLL, the DLL function cannot dynamically resize the array. Writing beyond the last element of the array or string could corrupt the memory and this may not be obvious until LabVIEW is closed."
But it doesn't match my case. Does someone have idea about this? I Attach my .h file for reference
Which of the 2 functions do you call? How?
The documentation of InitSocketEx() seems to indicate reversed parameter order than what the function prototype looks like!
I indeed do not see much possibilities to pass in to small a buffer that the DLL function might be overwriting past the end. This really only leaves one more possibility:
Your DLL is doing something largely illegal somehow. Maybe something as silly as storing the reference to the ipAdress instead of the address itself. The memory passed as parameters into a C function is generally only valid for the duration of the call. This is especially true if you use LabVIEW since LabVIEW will re- and deallocate memory buffers frequently as soon as they are not used anymore and the parameter to a Call Library node is considered to not be required anymore after the function returns.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Vision Assistant 2014 (and DLL inside of LV) repeatedly crashes while reading multiline OCR

I am working on an OCR application. With certain files (not all) the multiline function just crashes. No questions asked. I set the ROI area to the targeted text and without fail it causes a crash.
Is anyone aware of this problem, and if so is there a solution?
Additional information: My .abc file is from scratch with default settings and trained characters. Nothing in it should be causing the crash. Images are simple scanned jpg files.
Edit: I tested it. Crash still happens without any character set loaded, and no changes to threshold, size, or read options.

I cut out an offending section of one of the files. It is attached. To replicate the error:
1. Load image
2. Identification -> OCR/OCV
3. New Character Set File...
4. Select entire text.
NI Vision Assistant 2014, 64 bit.
Edit: Posted this before I saw your request On the "Full sized" image, it crashes always - even when it is called from inside of LabVIEW (the DLL crashes then). It is how I noticed the bug - my program kept crashing. Tor this image, it seems to only crash for me inside of the training assistant, but is again reliable.
Attachments:
crash.png ‏731 KB

How to call LabVIEW ActiveX dlls into VB6

I'm jumping in on a project written primarily in VB6. I'd much rather wirte code in LabVIEW so what I am looking for is some example code for calling LabVIEW activeX dlls into VB6. Does anyone have example code? I need to see how the LabVIEW libraries and classes are called and used in VB6.

Hi Drewdafis,
Refer to this link for example code on calling a LabVIEW DLL from Visual Basic.
Hope this helps!
Best Regards,
Jonathan N.
National Instruments

Turning a LabVIEW built DLL into an ActiveX server

Does anyone have a list of the steps you must go thru
to convert a LabVIEW generated DLL into an ActiveX server. Do the functions become methods?

Hi James,
we have a library we deploy in three ways: as a LabVIEW library, as a DLL and as Active-X server.
In the build file for the DLL we have made each "function to call" a top level VI.
In the Active-X server each "function to call" is a dynamic VI. We created a new top level VI which will run when the server is started and stops after his window is hidden. In LV 6.x you need the winutil library to hide the window. If you close the window (through FP.Open set to FALSE) the server will stop. The window size is set to 1x1 in the VI Properties to minimize flickering on the screen during start of the Active-X server. You must check the "Enable Active-X Server" box on the "Application Settings" page in the app builder. In your client application yo
u open a reference to the server and then you can open a reference to the VI. You set/read the controls and run the VI. There is sample code for Visual Basic on the NI web site. I have also sample code for Visual C++ single and multi threaded clients.
If you are interested in the examples contact me at [email protected] and I will ask my customer to allow me to send it to you.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Strange crash with Intel FFT in Windows XP x64: only when first starting LabVIEW and opening VI, not when opening VI by double-clicking

When I use the Intel FFT libraries(MKL), I seem to have a strange crash whenever I start allocating the Intel DFTI descriptors. I call a DLL from LabVIEW 8.2.1, in which these functions are used. I am working on Windows XP x64. This seems like a bug which was present in these libraries, but I got the libraries where the bug was resolved.
The strange things is that, when I open LabVIEW and then open the VI, LabVIEW crashes from the moment I allocate an Intel Dfti descriptor. But when I just double-click the VI and open it this way, I can run the VI without a crash! I already removed the DLLs in \Program Files (x86)\National Instruments\Shared\MKL\MKL70 to see if they were the cause. But even without them, I still get the crash.
I know there was a strange crash in the previous version of Intel MKL when calling a DLL and allocating this type of descriptor, so it seems like somewhere LabVIEW still uses old versions of some of these DLLs. But even then, can this explain the difference in behaviour between opening the VI through LabVIEW or directly? And if so, were could I find these DLLs? I've already searched from them everywhere.

Update:
- Opening the single VIs directly by double-clicking indeed solves the crash: from then on I can run all VIs using the libraries without any problem. So LabVIEW must do something strange when it is opened.
- Linking my DLLs statically against the Intel libraries ALSO solves the prolbem. So this seems to indicate LabVIEW loads some dynamic library which screws up everything. But only on x64 systems . This bloats my DLL, but currently I do not see another work-around.
Anyone has any more ideas? Otherwise I can always submit some test case to LabVIEW support.

Simulink, Labview and DLL

Similar Messages

Maybe you are looking for