Matlab window issue

Hi Chris,

I’m learning how to use the Matlab window. One small question, and a problem:

  • What does “process {x} events” mean? Why is it 0 sometimes, and 1 other times?

  • I’ve written an m-file that plots some data every time it’s called. From your example, the way this gets called is that “sync” is set from 1 to 0. My MWorks program cycles through blocks of trials, setting sync = 1 at the start of the block, 0 at the end, then back to 1 immediately. The data from the first block gets plotted, but not for successive blocks. Stopping and starting the program doesn’t fix the problem. In fact, if I try to unload the program after the m-file has been called, the client stops responding and I have to force quit. Would you mind helping me figure out what’s going wrong?

Thanks,
Evan

Hi Evan,

What does “process {x} events” mean? Why is it 0 sometimes, and 1 other times?

If “Collecting Data” is checked but “Process X events” is not, then the MATLAB bridge will collect the selected events but will not invoke your script. If you subsequently check “Process events”, the collected events will be sent to your script at that time.

The data from the first block gets plotted, but not for successive blocks. Stopping and starting the program doesn’t fix the problem. In fact, if I try to unload the program after the m-file has been called, the client stops responding and I have to force quit.

I think this is a bug. I see it with MATLAB R2014a, but not with R2011a. Let me dig in a little further and see what’s going on.

Thanks,
Chris

Hi Evan,

It looks like the client freeze is related to this issue. It appears that under MATLAB R2014a, the MATLAB engine API (specifically the engGetVariable function) gets stuck when the variable value is an int64 array. The only feedback we get is a rather unhelpful message sent to the console:

{Error using save
Can't write file stdio.
} 
Error writing to output stream.

I assume this is a bug, not a design choice.

The fix is to ensure that your MATLAB script returns a double array. I’ve attached an updated matlab_window_demo.m and will also post it to the tutorial.

Cheers,
Chris

Attachment: matlab_window_demo.m (499 Bytes)

Hi Chris,

Thanks for figuring that out. I was using a struct (of doubles), but either way using the double array fixed the problem. I guess it would be nice to be able to use other data types (like structs), but this works so that would be a low priority item if anything. Maybe it would help to submit a bug report to Mathworks?

Also, how did you know the problem was in the return value from the matlab script? Just that console message?

  • Evan

Maybe it would help to submit a bug report to Mathworks?

Yeah, that’s probably a good idea.

Also, how did you know the problem was in the return value from the matlab script? Just that console message?

I ran MWClient in the Xcode debugger and saw that it (1) hung at engGetVariable and (2) produced that console message. Feeding the console message in to Google led me to this thread, which suggested that the data type of the variable was the problem.

Actually, I fully expected this to be an MWorks bug, so I was both pleased and surprised to discover that it wasn’t.

Chris

Just an update - I finally submitted a ticket to Matlab about adding support for other data types in the engGetVariable function.

Hi Chris,

I heard back from The Mathworks. They passed along an example program. From the rep:

I have created a sample C program file ‘demo.c’ which demonstrates the usage of ‘engGetVariable’ method to get the ‘struct’ and ‘cell array’ data structures from that MATLAB environment to the C environment. I have also added the appropriate comments wherever necessary inside the code.

In order to compile demo.c program, please use following command at MATLAB command line:

mex -client engine demo.c

This will generate an ‘exe’ file. Please execute this file using windows command prompt to see the output of ‘printf’ statements inside the code.

I don’t have anything waiting on this functionality. Just wanted to add the update.

Evan

Attachment: demo.c (1.94 KB)

Hi Evan,

The example program demonstrates the same bug:

>> mex -client engine demo.c  
Building with 'Xcode with Clang'.
MEX completed successfully.
>> quit
$ DYLD_LIBRARY_PATH=/Applications/MATLAB_R2014a.app/bin/maci64 ./demo 

 Creating structure 'sampleStructure' 

 Retrieving structure 'sampleStructure'
Error using save
Can't write file stdio.

And there it hangs.

It sounds like the MathWorks guy tested his example on Windows. Maybe you should tell him to try it on a Mac.

Thanks,
Chris

Relaying from Mathworks:

I tried to run ‘demo.c’ program on Mac operating system. I was successfully able to >run it on Mac OS X 10.9.2 from system terminal. Following are the steps which I >followed for compiling and running this program:

  1. At the beginning, I made sure that the ‘PATH’ environment variable includes /bin
    path.
    If it is not present in your case, then you can use the following command to include that path:
    setenv PATH ‘/bin’:$PATH

    where is the MATLAB root directory. You can run ‘matlabroot’ >command at
    MATLAB command line to get matlab root directory path.

  2. I then executed following commands in order to set the environment variable
    ‘DYLD_LIBRARY_PATH’ properly.

    setenv DYLD_LIBRARY_PATH ‘/bin/maci64:<matlabroot/sys/os/maci64>’

  3. I compiled demo.c program from MATLAB command line using following command:
    mex -client engine demo.c

  1. I ran demo program from the same system terminal as below

    ./demo

Hi Evan,

I still see the bug:

$ PATH=/Applications/MATLAB_R2014a.app/bin:$PATH DYLD_LIBRARY_PATH=/Applications/MATLAB_R2014a.app/bin/maci64:/Applications/MATLAB_R2014a.app/sys/os/maci64 ./demo

 Creating structure 'sampleStructure' 

 Retrieving structure 'sampleStructure'
Error using save
Can't write file stdio.

I tried it on two machines, one running OS X 10.9.5, the other 10.8.5, and I got the same result both times.

If there a way for me to get in touch with this person directly? Or should I just open another bug report?

Thanks,
Chris

Hi Chris,

Apparently this bug is specific to Mac/2014a, and will be fixed in the 2014b release. Not sure why Mathworks didn’t catch that initially; the OS/release version was included in my original service request. Sorry about the time waste on this.

  • Evan