Avoid caching of Matlab m-files?

[M_N]

Labview 7.1.1f2, MatLab 7.0 (and verified that Labview is using this version through regedit)

I am trying to call, from the Matlab Script block, a m-file script.  This works with no problem the first time, but as I'm still developing the application, I find that if I make changes to this m-file, the changes do not seem to appear in LabView unless I restart the program (effectively restarting the Matlab server).  Changes in the code that actually is within the Matlab script block are updated immediately after changing.

It seems like the LabView/Matlab combination is caching the m-files, but I can't figure out a way around that, either via LabView or Matlab commands.  Anyone encounter this before and know a way around it?

[amiramke]

Hi

I encountered this problem before. I used labview 5.1 and matlab 6.1

The only way I found to resolve this issue was to use the "clear all" command in Matlab at the beginning of the script. The problem with this solution was (And my memory is a bit hazy, because this was 4 years ago in a different company and a different country) that it somehow affected the variables being transfered from labview to matlab and vice versa.

So, I realized that the best way was to save the variables to files (I used the Matlab script for that) and communicate between labview and matlab with writes/reads to these files:

It went something like this (This is just an example for saving x, y and z in a specific format)

save('c:\matlab6p1\work\1','x','-ascii','-double','-tabs');
save('c:\matlab6p1\work\2','y','-ascii','-double','-tabs');
save('c:\matlab6p1\work\3','z','-ascii','-double','-tabs');

I also had a lot of trouble with the Matlab not finding the m files I altered during run time although I specifically added their paths, so I also had to use the next (In the script):

addpath(genpath('c:\Matlab-files\'))

eventually everything worked perfectly.

I'm sorry I can't bring you the exact code and be more detailed. I don't have all my notes from that time.

Ami

[M_N]

Aha, that's the trick.  Not "clear all" at the top as you mention, as that will wipe out the input/output variables, but instead, using "clear functions" will wipe all the internal compiled m-files from the matlab server memory without touching anything else.  This may mean that there's a bit of a pause in loading the script up, but this is can be commented out from the matlab script block before moving out of development.

Thanks for the bead on that.

[Nishant]

Hiii, M_N

             I want a help in regard to call the m file into LabVIEW from MATLAB, i just have started to work on LabVIEW and MATLAB communication, and i even dont know that how to call the m file into the MATLAB script node in the LabVIEW? so can you please provide me simple example that shows me how to call the m file into MATLAB script node in LabVIEW?

Thanks,
Nishant

[M_N]

I don't have any examples to give out, the only suggestions I can make are this:

- Make sure that your m files are either already in the path that MATLAB is using, or that you set the path prior to calling them within the LabView MATLAB script box.  (You can pass a path string into the MATLAB box, and then use "path(path,p);", if p is your input string.

- Call the m file as you would any other MATLAB m file from within LV.

- If you can run the LabVIEW w/ MATLAB block once but have problems, you can do some basic debugging by copying all the code you have directly into the MATLAB server window which should launch when you create a MATLAB script box or open a VI with one of these.  That MATLAB window behaves just as the MATLAB console would - you just don't have all the nice benefit of the GUI that MATLAB has, but at least you can see results a lot faster and easier than trying to get back info from LV.

- "disp" commands don't work, but I've found that you can put small text points for debugging as calls to "errordlg".  Not perfect, but at least it helps to figuring out where LV or MATLAB may be getting hung up.