Labview Matlab script command window bug

[Carlomeriti]

Hi all

I tried Matlab script on a Windows XP SP3 PC with labview 2009 and Matlab 2008.

Everything looks fine except for the fact that the first input line of my code is not showed in the command window.

Then I moved on a Windows XP SP2 PC with the same labview and Matlab R2006b (7.3.0).

Here the commands display and input are not working properly in the command window. 

For example if I write in LV MatlabScript    x=input('text')    then in the command window i'm not able to see the text, even if the program is waiting my input.

If I write in LV MatlabScript        disp(x) then in the command window I have no answer.

All this commands are working properly ONLY IF directly written inside the command window (skipping LV MatlabScript).

Thanks for your help.

[AntonisV]

Hello Carlomeriti,

Do you receive any error when trying to use these commands?

After a small research I located a Knowledge Base article where it is described that "Commands such as input require the user to interact in the command window of MATLAB. They will not properly run in the MATLAB Script Node in LabVIEW".

Can you please take a look?

http://digital.ni.com/public.nsf/allkb/3770DDA4593BF5D6862567D0007A31E6?OpenDocument

[Carlomeriti]

Thank you very much for your help.

Unfortunately, the post that you suggest is both useless and out of topic.

In that post NI mixes error 1048, that I never saw in my script, and the problem that commands like input can run with errors.

The solution proposed at the end is not solving my problem: I don't need a visualization in labview, I need to see the text part (e.g. "enter a real number") in the command window of matlab prompted by the LV script.

[smercurio_fc]

I believe the article does answer your question. From the article:

---

Commands such as input require the user to interact in the command window of MATLAB. They will not properly run in the MATLAB Script Node in LabVIEW. The following is a screenshot of a MATLAB Script Node that calls the input command.

---

That specific article was providing examples of why you'd get an error code 1048. A.V. wasn't saying that's what you were getting. He's indicating that one of the reasons you'd get that error code is if your script was assigning a variable via the input command. Since the input command doesn't work, the variable would not be assigned and you'd get that error. So, the article is a reference, specifically, to using the input command, which is what you are trying to do. The solution is to provide the value via a front panel control.

[Carlomeriti]

Dear smercurio_fc,

thanks for your reply.

The problem is that the line that you tagged it's wrong

---

Commands such as input require the user to interact in the command window of MATLAB. They will not properly run in the MATLAB Script Node in LabVIEW. The following is a screenshot of a MATLAB Script Node that calls the input command.

---

This is not always true, as I stated in my first post

---

I tried Matlab script on a Windows XP SP3 PC with labview 2009 and Matlab 2008.

Everything looks fine

---

The problem happens when I change configuration; in any case I NEVER get an error 1048. The only thing is that on the command window is not visible the text message associated to the input command (e.g.. "enter a real number").

So it is possible to have problems with the input command without having error messages (that's why I was talking about mixing in my previous post).

About the solution proposed in the post:

1)They are talking about putting an input variable in labview but, as you can see, in the figure of the block diagram the variable b is an output, not an input.

2)This wouldn't solve my problem anyway, because my problem is not related to the input value, that I can enter in the command window, but is related to the display part of the command input. As you can imagine it is hard to input a number if the message "enter a real number" is not visible in the command window. You can see that the command window is waiting for something, but you don't exactly know what. 

That's why the problem, unfortunately, is still unsolved.