using matlab *.m functions in labview

[jattas]

Hi Hugo,

In a quick test in LV 2009, I found that xls performance was not as good as tdms or delimited textual files. Further, the functions for reading and writing xls files are implemented using ActiveX calls to Excel. Unfortunately this means that they are Windows-only (ie. will not operate on real-time targets).

It seems that functions like fread_delimited and fwrite_delimited (legacy names dlmread and dlmwrite) may be your best bet. The File I/O palette in LabVIEW also has many options in this area which may meet your needs.

jattas

[huguerreiro]

Hi jattas,

The solution I intend to folow is to convert the Matlab envoiorment into compatible labview files, can you tell me witch files are more efecient:

- *.mlv, *.tdm or *.tdms?

Thanks for all help

Hugo Guerreiro

[huguerreiro]

Hi again,

I'm facing some problems:

I tried to use de csvread MathScript function to read a 11026x1 array, it reads an 11026x1 array of zeros, why?

Using the xlsread makes the application slow but it reads all the required data.....

 When I call the one specific *.m user defined function that returns an nx1 array, used inside another *.m user defined function, the labview returns the following error:

"Error in function find at line 25.  This function is not defined for the number of parameters you supplied.
    D:\Hugo\Documents\LabVIEW Data\AvgLine.m
    D:\Hugo\Documents\LabVIEW Data\Analysis.m", wirh the code: "-90003".

Can you help me?

Best Regards

Hugo Guerreiro

[ttrr]

Hi Hugo,

Which version of LabVIEW do you use?

I try to read the attached csv file in both LabVIEW 8.6 and 2009. MathScript can read the data correctly by using either one of the following commands.

a = csvread('test.csv')

a = csvread('test.csv', 'A1..A4')

Would you please try it on you machine?

For you second problem, -90003 error is returned when you specify incorrect number of parameters for a function. Could you attach the command, line 25, that cause the error? Also note that find in LabVIEW 2009 can accept more inputs than that in LabVIEW 8.6.

By the way, if you need to deal with huge data file, reading and writing frequently, TDMS should always be your first choice in LabVIEW.

[huguerreiro]

Hi Ttrr,

 My LabView version is the 8.6, and I discover one of the problems:

- It seams that LabView don't supports fully the "find"Matlab function, at least in the way that I'm trying to use:

IndexLastTH = find(A1mean >= TH,1,'last');

I also going to try use the TDMS file format.

Thanks

Hugo Guerreiro

[ttrr]

Hi Hugo,

The syntax you mentioned is covered in LabVIEW 2009.

In LabVIEW 8.6, you can use the following workaround to get the same result.

IndexAll = find(A1mean >= TH)
IndexLastTH = IndexAll(end)

[cookjr]

Hi Hugo,

If you're still interested in reading/writing *.mat files in LabVIEW, there is a mat-file IO library that should work fine on a real-time target.  It can be downloaded at http://matio-labview.sourceforge.net/.  There are some examples included with the library to help you get started.

Jim

[huguerreiro]

Hi there,

I'm already able to integrate all my matlab code into LabView using MathScript. And thanks for that, but it reveals a disappointing solution. 

The code is to long to run in real-time on LabView, leading to a structural error in my project. Matlab takes around 1s to run the code, while the labview takes several seconds. The solution's I have, are:

- Translate all the Matlab code in to LabView Code;

- Or run two independent applications, one in labview (recording sound) and another in Matlab (analysing the sound recorded).

Any idea? will be welcome.

Thanks

Hugo Guerreiro

[jattas]

Hi Hugo,

There are a few other possibilities that we can try so that hopefully you won't need re-write your entire application. The first step is to isolate the bottleneck(s) in your code. Is every MathScript Node slow or is it just one node in a critical loop? Is the whole script slow or is it just one function call? Unfortunately MathScript nodes don't show up in the Profile Performance and Memory tool yet but you can get some numbers using timing functions like "tic" and "toc". If you would like some help with this step, feel free to post your code here. The MathScript R&D team has tools to look at what's going on behind the scenes.

Once we've identified the bottlenecks, there are a few different directions we can go. Perhaps the MathScript code is written in an inefficient way and could be improved. For example, maybe it's doing an operation in a loop that could be done outside the loop, or maybe it is using elementwise operations when it could be using vectorized ones.

Or perhaps the code is as efficient as possible and the problem is with MathScript itself. In that case, you could re-write just the time-critical portion of your code into LabVIEW code or a formula node. In addition, the MathScript R&D team could investigate the bottleneck and improve it in future versions of LabVIEW.

Please let me know if we can help in any way!

Thanks,

jattas

[kmcdevitt]

Hello Hugo,

Its good to see that you have achieved success in you MathScript endeavors on LabVIEW 8.6.

I reccomend you do some soul searching and some testing of MathScript on LabVIEW 2009 before you take that leap.

I already owned 10 copies of MathScript as part of our NI Developer Suites.

However, MathScript was taken away from me as part of the LabVIEW 2009 Upgrade.

This may have happened to you too, as I know it has happened to others. 

It happened to us even though all ten Serial Numbers were, and are now, currently on SSP.

Apparently everybody that owns Developer Suite and MathScript and has a current SSP has had their MathScript taken away from them as part of LavVIEW 2009 upgrade.

They will need to repurchase MathScript again.

So, as I have said, be cautious in your decision to upgrade to 2009.

Kevin