dll, matlab an LadVIEW

[Prathiksha]

Hello,

I'm trying to run a user-defined matlab function in labview using the mathscript node but this function calls another user defined function which inturn calls a mex file. I had implemented this function seperately in matlab and it works fine but in labview it cannot find the mex file. How can I solve this problem?

[timtamslam]

Howdy Prathiksha,

To start, I want to make sure we are clear on the differences between the MathScript Node and the MATLAB® Script Node.

The MathScript Node is designed to execute .m style code natively within the LabVIEW environment (and run-time). LabVIEW uses its own set of libraries to execute the code defined in the MathScript Node. You can check this document for more information on MathScript.

The MATLAB® Script node is designed to transfer the code defined within the script to MATLAB®'s run-time environment (via ActiveX with MATLAB® as a COM Server) for execution. So, any code defined within the Script Node will be executed using MATLAB®'s libraries and application memory.

First, I would make sure that using MathScript is the route you want to take because using the MATLAB® Script Node may provide some ease of use.

You mentioned that LabVIEW "cannot find the mex file". Can you elaborate on this? Are you getting error? Can you post how you are attempting to call the .mex?

[MengHuiHanTang]

It might not be completely true, but to my understanding MathScript is a LabVIEW-generated environment to run a .m code. Not any .m code, only the code/functions NI implemented. You can find a whole list of functions that are implemented/supported by LV. If you don't see your functions in that list, your m code won't run in MathScript Node.

From what you described, I think the best way is to call your MatLab code through ActiveX. This way your m code is guranteed to run because it is executed in MatLab itself; the downside is you won't be able to use parallell computing, because the ActiveX is single-threaded.

[timtamslam]

That's correct MengHaiHanTang. You can find an abridged list of MathScript functions here,

Abridged NI LabVIEW MathScript Function List

http://www.ni.com/white-paper/3803/en/

The full list is released with the help documentation,

MathScript RT Module Functions

http://zone.ni.com/reference/en-XX/help/373123C-01/lvtextmath/msfunc_classes/

[Prathiksha]

Hello Timothy,

I used the mathscript node because i had mistaken it to be the matlab node.......sorry i'm new to labview.......i did try to implement it in the matlab node ....however i kept getting errors.....sometimes it would be 1047....so to solve it i would close my labview vi and once again open matlab and after it loads i would run the vi......sometimes it would be 1050 stating that my output variable is not defined(it's a binary image).......and about the mex file(this is for a different matlab program).....i had matlab compile it before in the command window using mex histc_weighted_mex.c command. I used it only initially when i first got the user-defined function from the internet and hadn't called the mex file afterwards anywhere in my program...i didn't get any errors though on running my code in matlab....and even in the matlab node there are no commands to compile the mex file....the program at the node calls a user defined function FRST which inturn calls another user function histc and this finally calls the mex file.

There is also another issue. Whenever the matlab window opens i seem to get this error:

Warning: Calling MEX-file 'E:\SimulationInterfaceToolkit\5.0\Lib\NISITServer.dll'.
MEX-files with .dll extensions will not execute in a future version of MATLAB.
Error using NISITServer
Unable to open library SIT_InterfaceWindow.dll.

Error in matlabrc (line 215)
NISITServer;

Could this be the cause of the problem that i'm facing???

[timtamslam]

Hey Prathiksha,

The error 1047 usually links back to the ActiveX script server not starting properly on the machine. I would look at the steps in this document,

Why Do I Get Error 1047 When Trying to Use The MATLAB® Script Node in LabVIEW?

http://digital.ni.com/public.nsf/allkb/2B3FF46C8512C4F786256CF30071BE53

Error 1050 is usually more generic and it comes up when there are issues with data types/inputs/outputs between the Script Node and the LabVIEW Environment. In the case you mention where you received an error 1050, it looks like there wasn't an output variable defined. I would make sure that you have one setup. If you need more assistance with this error, please post your script code and what you're expecting to output so that we can see which section is specifically conflicting.

The message you're seeing in the command window is definitely important in the context of the Simulation Interface Toolkit but I don't know that it is interfering with your current issues. So, that is likely a red herring. But if you want to address it, here is what you can do

It sounds like the NISITServer function is not executing properly because the MEX-file its calling (NISITServer.dll) still uses a .dll extension which may not be supported by the version of MATLAB® you're using. The NISITServer.dll is updated to a mexw32 in later versions (I believe its fixed in 2010) of SIT. Do you have access to a newer version of SIT that you can use? If we can get the version of SIT updated, we should have a mex that works with your version of MATLAB®.

MATLAB®  is a registered trademark of The MathWorks, Inc.

[Prathiksha]

Hello TimothyA,

I did get the program to work.....instead of importing the script which calls the user-defined functions from matlab i typed it on the node. I think the changes that were made in the program before execution of the node was not saved and this could have been the problem. Anyway it seems to be woking fine for now. I'm planning to upgrade my matlab software(R2012b) to a higher version as my license is on the verge of expiring.So i guess that error might not show up in the newer version. 

I had compiled my mex file long back in matlab ....and I was wondering whether my script node should compile this mex file everytime it executes the program???

[timtamslam]

Great! I'm glad you've gotten to the point where your code is now running.

The issue with the SITServer not running is likely to do with our software version because its trying to use a .mex we produced thats still in .dll format and not mexw32. So, you'll want to make sure you upgrade our software side as well! When it comes to model interfacing/HIL, Simulation Interface Toolkit (SIT) was the software used to interface compiled models between our softare and The MathWorks, Inc. software. But if you do upgrade I would recommend looking into VeriStand and th Model Interface Toolkit.

For your last question, the MATLAB® Script Node will not perform any compilation. If the script node you're using calls a .mex, it will simply be calling it into execution in MATLAB®. Similar to if you were calling a .dll.

MATLAB®  is a registered trademark of The MathWorks, Inc.

[Prathiksha]

Thank you ......i have one last question.....i observed that when i ran the program for the first time upon opening the vi the execution time taken in the matlab script node is very large in order of 2 sec.....but afterwards the execution time reduces to 100msec. I guess this is because labview has to establish connection with the matlab environment.But since mine is a real-time application this is creating an issue.Could you suggest a way to avoid this problem?

[timtamslam]

I am not sure on the specifics behind the scenes of what causes that long delay, but you are on to the right idea. The time it takes to start the server communication and start the MATLAB® run-time is likely responsible for this delay.

There are many things to consider when talking about software determinism for real-time systems. One of the biggest things is OS choice. Without the use of a Real-Time OS, you're already going to be a bit limited in the level of determinism you'd be able to obtain.

That aside, the way to approach any issue with reducing jitter is to understand the source. In this case we have interprocess communication (via ActiveX) between two applications. Here are a couple general recommendations, 

1. Reduce the number of running applications (have all of your code running in one process, ideally)

2. Use a more deterministic method of interprocess data transfer (prebuffered deterministic FIFO's are a common approach, but not always an easy option)

3. Reduce the load on the computers processor such that it prioritizes your most important processes. (another hard thing to do with windows)

I would focus on section option one, as it would be simplest to implement in your setup. So, you have a choice... Remove either LabVIEW or MATLAB® from the equation. The way to do this, is by building the code you develop in either environment into a binary that could be called by another program. For example, can you build your MATLAB® code into a .dll and then call it from LabVIEW (or vice versa)? This may not be possible, depending on what functions you are using, but it is something worth looking into.

We may be getting into a much larger discussion here but this will at least get you moving in the right direction and thought process. Let me know if you have more questions or thoughts and we can continue to discuss which path seems most applicable for your end goal.

MATLAB® is a registered trademark of The MathWorks, Inc.