12-27-2013 10:18 PM
Hello,
Thank you for the suggections. I'm interested in created a dll file for the program but i don't know how to create one. I have looked at some sites and they say that there are several techniques for this. Can you provide me a link that explains how to do this and i also have the c program of the same function also got from the internet. I haven't executed this yet but i was wondering if labview executes the c-code or the matlab code faster?
12-30-2013 01:01 PM - edited 12-30-2013 01:02 PM
Well, on the MATLAB® side I am honestly not sure on the best process. I am sure there is some good resources out there via search engine results. But honestly I'm not super comfortable with the material enough to make a recommendation. You can try to reach out to the MATLAB® Support team, as well. I'm sure that they can provide some helpful information and recommendations,
On the LabVIEW .dll side here is a quick document that I recommend.
https://decibel.ni.com/content/docs/DOC-15556
MATLAB® is a registered trademark of The MathWorks, Inc.
12-03-2015 02:38 PM
@mugger wrote:
The procedure entry point ?initialize@task_scheduler_init@tbb@@QAEXHI@Z could not be located in the dynamic link library tbb.dll.
Any idea?
have a look here:
DLL-Name Conflict
http://forums.ni.com/t5/LabVIEW/Matlab-MCR-DLL-cannot-be-used-from-LabVIEW/m-p/1273254/highlight/tru...
Has anyone information, if this name conflict is resolved? And in which LV version?
12-03-2015 03:35 PM
It's not a name conflict. This is the Intel Threading Building Block Library. Being written in C++ it is very suspictible to version chances. It's a great library but you can not easily use two different versions of it in the same application. And it is not feasable to expect from Matlab to use the same version of it than from LabVIEW. Not using it is also not a feasable solution for both if you want to do multithreading programming.
It's another variant of DLL hell and there is no easy fix for it. It's neither Matlabs nor NIs fault really! NI or Matlab could decide to rename the DLL on their side to make the chance for such a conflict smaller but that is at best a bandaid as it makes the release process of a product considerably more complex. Or Intel could decide to use Side by Side (SxS) assembly technology to help avoid this problem.
As it is now, everybody has some right to claim that it isn't really their problem and the others should fix it.
12-03-2015 04:05 PM - edited 12-03-2015 04:20 PM
Hi Gerd,
thanks for the info 🙂
I read the recommedation to rather build a .NET-Type DLL rather than a C/C++Type DLL. Does this make a difference regarding the version conflict of the "tbb"-library?
P.S.:
It seems that different names exist for this DLL, I found a library called "ocl_cpu_tbb64.dll" / "ocl_cpu_tbb32.dll" the same size as the "tbb.dll" files in the "X86" and "x64"-folder.
01-16-2019 01:27 PM