Matlab vs. C DLL

[MWA_05]

I have an algorithm written in Matlab that I need to integrate into a LabVIEW VI.  In our current version of the software, we use a DLL written in C that I compiled in Visual Studio through a long period of trial and error.  I need to make some significant updates to our code and would much prefer to keep it in the Matlab environment that I’m more comfortable with.  Unfortunately, using a MathScript node is not an option due to the complexity of the algorithm and our desired processing speeds.

Initially I thought I would buy the Matlab Compiler and use it to create the DLL, which I’d then call in LabVIEW, problem solved.  However, after reading through several threads about Matlab DLLs on the discussion board, I am concerned about all of the issues that people seem to have had when trying to do this.  Can anyone offer some insight into whether these Matlab DLLs usually cause problems in LabVIEW VIs or if these are isolated incidents?  Do they always need to be called through a secondary C DLL?  Thanks in advance!

[jattas]

Hi MWA_05,

I work on the MathScript R&D team and I'm interested in your comment that "using a MathScript node is not an option due to the complexity of the algorithm and our desired processing speeds." We would love for there to be no barriers to using MathScript. If you get a chance, could you elaborate a bit more on the limitations that you encountered? Were there language features missing from MathScript? Was a specific function or operation not fast enough? If you are able to post code that didn't work well in MathScript, we'd relish the opportunity to inspect it and see what we can do with it!

Thanks,

jattas

LabVIEW MathScript R&D

[MWA_05]

Jattas,

Thanks for your message - I would love for there to be no barrier to MathScript, too!  Our algorithm is proprietary so unfortunately I can't post the code for you.  When I stated that the node was not an option due to the complexity of the code, I meant that there are over 100 lines of code that include a variety of operations and, while there is no problem with including the actual commands, I have not been able to make the LabVIEW software run fast enough using this approach.  We acquire data at 1 kHz and even using the DLL, can only process and output results at 100 - 200 Hz.  Using the MathScript nodes slows it down considerably more, though the last time I tried this was in LabVIEW 8.5.  Please let me know if you think the upgrades in LabVIEW 2009 might help.  

MWA

[minnellac]

It's been a little while since the last time I did this, but I think I can answer some of your questions. One, there's a good chance that the c-dll will run faster than the Matlab dll, unless you are using some functions that were heavily optimized for Matlab. You can use the compiler to create a dll and call it from LabVIEW, but you will have to create some sort of interface to convert the datatypes (outside of LabVIEW). You may have better luck if you use an older version of Matlab. 6.5 and prior would actually generate compiled code, and as long as you have the 90 or so dlls installed correctly, would run very quickly. These compiled dll's were also easier to call, but still require an interface to LabVIEW. Since Matlab 7 (R14), the compiled code will run exactly like it does in Matlab (i.e., with the same performance), and is easier to get compiled and running (just install the runtime). Previously, not everything would compile. Now, if it runs in Matlab, you can use the Matlab compiler to create a dll. We've created an internal c-library of functions that allow us to create and handle the pointers to the Matlab datatypes so we can work with Matlab generated code all in LabVIEW, but it is still a hassle. Unfortunately, I can't share this library.

A better option, but not always feasible is to use Real Time Workshop to create c code from your Matlab code. This can be done quickly, and will generate an actual dll that has traditional datatypes. These can be called directly from LabVIEW. Unfortunately, RTW requires Simulink and Matlab, and all of that will set you back ~$15k if you don't already have it.

Of course, there is always the Matlab script node, which works fine as long as you don't mind having Matlab installed on your test machine. This is the way we usually go for initial testing or quick demonstrations. It's much easier to modify the Matlab code this way during debugging. I'm not positive, but I think you can build an executable in LabVIEW and still call the Matlab script node, which can target a script explicitly somewhere in the file system. That way, you can tweak the "analysis" portion of the code on a built executable even without rebuilding in LabVIEW.

Finally, the Mathscipt nodes. I wish they would work, but we rarely actually get anything to work in them. The problem is that everyone developing m files does so in Matlab, not Mathscript. Then when we try to take something they've built and get it running in Mathscript we are bled to death by a million little cuts. I don't think structures or cell arrays work, and it just seems like we always run up against a little annoying thing that keeps us from using them. We are even paying for the Mathscript RT licenses now (or soon anyway) just in case someday we get something to work. I'm not a Matlab guy myself, so I can't really explain the problems clearly, but it seems like the code always has to be re-done for Mathscript, and that is not something the Matlab guys are too enthusiastic about.

sorry if I rambled a bit.

Chris

edit: wow, all my linefeeds disappeared.. FIXED

[jattas]

MWA,

Execution speed in MathScript has improved dramatically since LabVIEW 8.5. While it depends on what operations you're performing in your script, we have seen scripts that run 10s, 100s, or even 1000s of times faster in 2009 SP1 than in 8.5. I'd strongly encourage you to test out your code in the latest LabVIEW. (Although you should be aware of one other change with 2009: National Instruments separated MathScript into a separate module in 2009 which means it must be purchased separately from LabVIEW).

If you do give this a shot, the biggest thing to watch out for is warning glyphs. These yellow triangles might appear in your MathScript Node if you're calling certain built-in functions. If they do appear, they indicate that the MathScript Node is operating with reduced performance--in many cases, performance will be back to 8.5 levels. The good news is that the warning glyphs are usually fairly easy to avoid. Check out this post for more information.

Chris,

Thanks for helping MWA out with the DLL questions. I can sympathize with your comments about the difficulties in bringing code into MathScript. We are trying to make this process as simple as possible. For example, support for structures and cell arrays is on our roadmap. If you (or one of your colleagues) can describe any of the other issues that you've had, I'd be happy to hear about them so we can rectify them in future versions and offer workarounds in the meantime.

jattas

LabVIEW MathScript R&D

[MWA_05]

Chris,

Thank you so much, that's all very helpful.  I will look into the Real Time Workshop, that may be the best solution for me at this point.

Jattas,

We don't have the MathScript in 2009, but I do have Matlab on the computers I'll be running the software on.  Do the Matlab script nodes have the same improved processing speed or is it just the MathScript nodes?

MWA

[jattas]

Hi MWA,

The big performance improvement in 2009 is limited to MathScript Nodes.

If you're interested, you can download a free 30-day evaluation version of MathScript for 2009 from ni.com/mathscript.

Good luck!

jattas

LabVIEW MathScript R&D

[johnsold]

MWA,

In the third post in this thread you mentioned acquiring data at 1 kHz and processing at 100-200 Hz.  You did not mention how much data you were acquiring or the nature of the processing.  I think you could describe that without compromising your proprietary algorithm and it would give us a better understanding of what you are trying to do.

If your data can be processed in relatively small chunks, then running those chunks in parallel on separate cores may be the way to get the increase in speed you need.  LabVIEW lends itself to parallelism and uses multicore processors effectively.  I do not know Matlab well, but I do not think it as good at breaking things up in parallel as LV.

Lynn

[minnellac]

Like I said before, I'm not one of the Matlab guys, but I don't think you can parallelize your code very well. Some math libraries are multithreaded by their nature (some image processing stuff, etc.), but you can't make your code run multiple threads without the Distributed Computing Toolbox (which gives you a for loop that works like the LabVIEW parallel for loop, and maybe some other capabilities). I'm not sure if Mathscript is any better in this regard, but presumably you can run multiple simultaneous mathscript nodes (??). There is no connection between Mathscript and Matlab Nodes btw. Matlab script nodes work through Matlab's COM interface I believe; you are effectively just passing everything to Matlab for it to process, and then it passes the results back. The Inputs and Outputs from the Node are just variables in the Matlab Workspace.

You algorithm must be chugging away pretty hard on those numbers. We routinely run frequency domain analyses on data coming from DSA cards at 200kHz in "real-time" on pretty standard PCs. Maybe you can more efficiently break up the data into chunks. It will probably run faster if you pass data in to the algorithm in larger blocks than 1 sample at a time, but that will depend on your algorithm. In the case of the Matlab script node, you will have communications overhead, so you will want to minimize the number of transfers. Maybe running your process once per second would be better. The Matlab script node will never run faster than doing the same thing in Matlab natively, so if it's slow there, you need to look for ways to speed up your code, or ways to speed up your computer.

Jattas, thanks for the feedback. I really want it to work, so the next time it comes up I'll try to document the issues.

Chris

[MWA_05]

Lynn,

Thank you for your suggestions.  We are acquiring very small amounts of data but unfortunately I don't think that parallelizing the code will work for this program. 

Chris,

The algorithm runs pretty quickly in Matlab so I don't think that is the problem.  In the past we were using the MathScript node and not the Matlab script node (which, as you noted, are different), so now I am trying to test out the Matlab script node to see if that helps.  I had been hoping to avoid going that route since it requires Matlab to be installed on the computer but if it improves the processing speed without having to use a DLL then we'll make it work. Thanks again for all of your advice, it's been very helpful.