LabVIEW 2012 and Matlab script server error

[DanX]

I just installed LV 2012 and upgraded some code that runs Matlab scripts. Now when I run it, it gives me a server script error (1047). I am using Matlab 2007. Anyone have the same problem? Anyone know of a solution?

I assume it has to do with the script server not registering correctly. But I can run the same exact code in LV 2011 with no problem while LV 2012 gives me an error. Same computer, etc.

Thanks in advance for any help you might be able to provide.

[IanS]

Hi,

As I don't have a matlab license, I can't replicate this problem, but I have found a knowledge base article which may help you: 

Why do I get Error 1047?

It highlights a few ideas for how to get it working

[DanX]

Spoiler

Thanks Ian,

I did try #1. and #2. in the knowledgebase page without success. Then I went to see if I had the same problem with LV2011 (and I didn't). Since it seemed to be dependent on the LV version, I thought it was unlikely that the solutions offered on this page would work.

But I will look at them again if no one else can offer a solution.

Thanks.

DanX

[transfererror]

Hi DanX,

I experienced the same error with LV2012. And I haven't solved it.

But I found out, that the error only occurs if your VI with the Matlab script node has a connected terminal or not. See attached figure. This is an reproducable Labview bug in the current version.

Best regards

transfererror

[DanX]

Thanks. So what you are saying is that if it is a stand-alone VI with no connection, it will work? But otherwise not? This is helpful but difficult to deal with - I have to have my subVIs with Matlab scripts connected. What version of Matlab were you using? I wonder if that could effect the behavior.

I hope someone from NI can take a look at this. This seems like a pretty big bug.

DanX

[transfererror]

DanX,

currently I'm working with Matlab 2011b. But I don't think that this is relevant, since the same Malab version works fine with Labview 2011. All of my subVIs have a connected terminal, so I agree with you, that this is a pretty big bug. I already reported this behaviour to the NI support team, and I hope that they will fix it.

transfererror

[Y3G]

Hi,

Strange I have bearly the same error. but at my case the server does not even initialize. I have Matlab R2010b 64 bit and running LV2009 32bit, is this the reason?

Thanks

[Sev_K]

I ran into the 1047 error message when I first ran my VI, however, restarting LabVIEW resolved the issue. After restarting LabVIEW 2012 I was able to execute a subVI with a MATLAB script node without errors. I've attached the example code I used. 

[transfererror]

Sorry,

I missed to give you a workaround I got from the National's support team:

"Use a local variable or perform some sort of string operation between the control and the MATLAB Script node.
Using an inplace element structure also resolves this without creating data copies"

In other words: You have to perform some calculations with the incoming variables (for example adding 0 to numerical variables) of your subVi.

The developers know of this error and are working on a solution.

Best regards

transfererror

[DanX · Accepted solution]

Thanks "transfererror", this helped me identify the work-around. 

For everyone struggling with this, this is what I learned:

1. This only affects variables that are passed into a subVI from the connector pane (i.e., local variables not connected to the connector pane don't seem to have this problem).

2. It seems to only affect 1-D vectors or 2-D arrays. The reason that the example VIs inserted by Sev_K didn't apply to this problem is that datatypes that aren't arrays don't have this issue.

3. So to fix my problem, I just inserted an addition of 0 to all the vectors and arrays that were passed into the subVI. I guess what this does is copy the variable to a local buffer and perhaps this is the reason it fixes it?

Anyway, the work-around seems to work. I don't know what the cost is in terms of speed or memory but I don't care much about that for my application (some real-time applications that use Matlab scripts may need to consider this).

Perhaps this information can help NI identify and fix this bug.

DanX