回复： Re: 回复： basic commands don't work on Linux

[kandreas]

I was very happy to read that LabVIEW 8.6 brought MathScript support for Linux.

However the following very simple VI does not run (see attachment). If I try to load the attached .wav file, I get an error "Unknown symbol on line 3:wavread". Does this mean that the command "wavread" is not supported on Linux?

Alternatively, my small VI supports a .mat file to be read. This time I get a different error message: "File not found. ..."

This VI works perfectly for both .mat & .wav file on Windows. How can I get this running on Linux?

On a side note: MathScript is still not able (on Windows & Linux) to load .mat files that have been created on Linux ...

 

 

[ttrr]

Hi,

Yes, the wavread function only works on Windows system.

Regarding the load problem, it should be a bug. I will file a bug report. To make your VI work, I slightly change the code. Please see the attached snapshot for detail.

I do not have a .mat file which has been create on Linux for test. Would you please attach one such that I can have a try?

Thanks!

[kandreas]

where can I find a list about what function in MathScript is supported on what operating system?

your fix works! thanks! Do you have a link so I can follow up the bug report?

please find attached a .mat file that was saved on Linux. This is the same data as I've attached in my original posting. Labview complains now:

"Error -90031, Unknown output variable". 

I suspect this problem is due to the different file encoding on Windows & Linux. Up until today, whenever I wanted to load a .mat file in Labview I had to first load it in Matlab on Windows and then save it before I could use it - very tedious ...

[ttrr]

Hi,

The best place to know the platform that a function supports is in its help. Please go to ni.com. Then, search 'MathScript' with the function name. You can find the platform information from Installed With part in the function help, such as wavread.You should check the LabVIEW 8.6 Help.

Thanks for attaching the .mat file. I will try it and let you know my investigation later.

[ttrr]

Hi,

I have tried the .mat file you attached. However, I did not see any problem to load it on Windows and OpenSUSE systems. The data, pbk which is 10k-by-1 double array, was successfully loaded into MathScript Windows.

[kandreas]

---

ttrr wrote:

Hi,

I have tried the .mat file you attached. However, I did not see any problem to load it on Windows and OpenSUSE systems. The data, pbk which is 10k-by-1 double array, was successfully loaded into MathScript Windows.

---

I can only load the data, if I rename the variable inside the .mat file, so it has the name "pb".

however, if the .mat file is created on Windows, the variable can have any name and will be returned correctly.

[kandreas]

---

ttrr wrote:

Regarding the load problem, it should be a bug. I will file a bug report. To make your VI work, I slightly change the code. Please see the attached snapshot for detail.

---

this did work fine for all my standalone VIs, but if I put this vi into a lvproj file, I get an error, as I've posted here:

http://forums.ni.com/ni/board/message?board.id=170&message.id=377160

Message Edited by kandreas on 01-03-2009 10:53 AM

[ttrr]

---

kandreas 写:

---

ttrr wrote:

Hi,

I have tried the .mat file you attached. However, I did not see any problem to load it on Windows and OpenSUSE systems. The data, pbk which is 10k-by-1 double array, was successfully loaded into MathScript Windows.

---

I can only load the data, if I rename the variable inside the .mat file, so it has the name "pb".

however, if the .mat file is created on Windows, the variable can have any name and will be returned correctly.

---

Hi kandreas,

One of my colleagues extracted the .tar.gz file by WinZip and failed to load the .mat file in MathScript on Windows system. He found that there are additional bit shifts in the file. It looks like the difference is that WinZip has inserted 0x0A after each 0x0D character (the usual Unix --> Windows line ending fix to add a new line after a carriage return). This might be because the file is a .tar.gz file and WinZip is trying to "do the right thing."  When he copied the file directly from the Linux system, it can be loaded just fine. So it seems the issue is how you are unzipping the file on Windows system.

By default, WinZip will do this conversion for .tar file. To disable this conversion, you could go to the Miscellaneous setting in Configuration page of WinZip and disable TAR file smart CR/LF converion. Hope that this will solve your problem.

[ttrr]

---

kandreas 写:

---

ttrr wrote:

Regarding the load problem, it should be a bug. I will file a bug report. To make your VI work, I slightly change the code. Please see the attached snapshot for detail.

---

this did work fine for all my standalone VIs, but if I put this vi into a lvproj file, I get an error, as I've posted here:

http://forums.ni.com/ni/board/message?board.id=170&message.id=377160

Message Edited by kandreas on 01-03-2009 10:53 AM

---

Hi kandreas,

I guess that you problem is that MathScript Node returns error when you build an application. This might be true, since no all MathScript function can work on Run-Time Engine. You can find the function list that are not supported in LabVIEW Run-Time Engine here.

[kandreas]

---

@ttrr wrote:

 

Hi kandreas,

I guess that you problem is that MathScript Node returns error when you build an application. This might be true, since no all MathScript function can work on Run-Time Engine. You can find the function list that are not supported in LabVIEW Run-Time Engine here.

---

I understand the Run-Time Engine's limitations. But no, the problem I have is, when I simply want to "Run" the vi. No build process involved.

If I replace the path(path, a) line with addpath(a) it works. This is super strange.