LabVIEW MathScript RT Module

cancel
Showing results for 
Search instead for 
Did you mean: 

Mathscipt path issue

Solved!
Go to solution
I am developing a VI that requires a mathscript node (to replace a matlab issue). I am building from two different machines; one in the lab and one in my office. There are external functions needed. I have placed these functions in the same location under My Documents\Labview Data on both computers. After I setup the search paths, it works on one machine but not the other. Am I failing to consider something? I setup the search paths with the main VI open.
0 Kudos
Message 1 of 9
(8,873 Views)
Hello,

Where exactly did you place your external .m files?  Directly in the "LabVIEW Data" directory or in a subdirectory of that?  By "setup the search paths" do you mean you configured this through the Tools >> Options >> MathScript menu?

By default, MathScript will search in the "My Documents\LabVIEW Data" directory on each computer for external .m files.  However, it does not search subdirectories of that folder.  If you want your files to be found automatically, you must place them directly in that folder.

If you have configured the search path settings through the Tools >> Options menu to look in different folders on your drive, LabVIEW will save the relative path from the VI to the .m file with the VI.  This makes it possible to store .m files next to the VI, transfer the files to another machine, and have it work without any path-setting effort.  However, if you intend to edit the MathScript node on a separate computer, you must then set the path through the Tools >> Options menu in order for MathScript to continue to find the .m files.

If your files are saved in subdirectories under the "LabVIEW Data" folder, then the .m file locations are still saved with relative paths.  However, if your login differs on the two computers, the path to the "LabVIEW Data" folder will be different.  This could explain why MathScript does not find the files.

Grant M.
Staff Software Engineer | LabVIEW Math & Signal Processing | National Instruments
0 Kudos
Message 2 of 9
(8,862 Views)

Grant - As I mentioned, I have placed these .M functions in the same location under C:\Documents and Settings\jmasse\My Documents\LabVIEW Data on both computers. (Using the default path works on one PC but not the other.)

And I have verified the path through the Tools >> Options menu ON BOTH SYSTEMS. They are setup identically via the Tools >> Options menu.

I have a common repository for the files I share between systems and I will download the lastest files onto each system but each environment is configured individually.

 

Each system has its own LabView Prof Develop 8.5, so each LabView environment is configured via the Tools >> Options menu. Each system has the .M files under C:\Documents and Settings\jmasse\My Documents\LabVIEW Data.

 

Like I mentioned, even the default path will not work on one system. Is there something else that got ommitted during loading of LabView or something wierd like that?

0 Kudos
Message 3 of 9
(8,855 Views)
Hello,

It definitely sounds like something weird is happening.  When you save your VI on the system where everything is working, is the VI broken?  Take one of the .m files that is not found when you load the VI on your other system.  Can you call that .m file from the MathScript Window?  Can you drop a MathScript node on a new VI and successfully call the .m file?

Grant M.
Staff Software Engineer | LabVIEW MathScript | National Instruments
0 Kudos
Message 4 of 9
(8,851 Views)

The Vi is not broken. The only way I can tell that there may be a path issue is when I run the VI that it gives me a line# error. That line is when the mathsript node encounters the external function.

As for the Mathscript Window, I am not sue if that would work since I pass in many parameters to the Mathscript Node.

 

I am wondering if it is not a path issue but a mathscript issue. Now that I realize it, there are other external functions that seem to work OK but it is 1 particular function that gives me the error - three times - each time it is called. What is strange is that it works on one PC but not the other and both environments are identical.

0 Kudos
Message 5 of 9
(8,838 Views)
Hello,

If the VI is not broken on the system where everything is working, but yet returns an error on the line with the external function, then most likely you are running the MathScript node in reduced performance mode.  What error do you see on the system where you said the VI doesn't work correctly?  The reduced performance mode is indicated by a small yellow warning glyph in the node, either in the top right or on the line that contains the function that puts the node in this mode.  Although, this should not affect the running of your code.  In this mode, the MathScript node still uses the search path settings you've configured through the Tools >> Options menu.  However, it cannot analyze any external .m files until run time.  This is why you don't see any errors until you run the VI. 

It sounds like the error is in the function itself.  This might help you investigate the problem.  However, if you can post the VI and the .m file, it would help us to investigate the problem.  Also, are you using MathScript within a project?

Grant M.
Staff Software Engineer | LabVIEW MathScript | National Instruments
0 Kudos
Message 6 of 9
(8,834 Views)

Grant - thanks for sticking with me. There is no warning glyph in the upper right hand corner and this is part of a project (though when I troubleshoot I just open the lower Vi containing the node). I may provide a copy of my work but it will probably work on your machine since it runs on my office machine. (I'd like to have you look at one last thing before I send it.)

 

There is a strange LabView phenomenom between the two machines. When I open a probe for the Mathscript node, on the good system it pops right open (about 5 seconds) but the other system takes over two minutes and it starts loading all the mathscript VIs and dlls at this point instead of the beginning like the good machine does. I'd hate to say it but it looks like I need a rebuild. Any last minute suggestions prior to this?

0 Kudos
Message 7 of 9
(8,830 Views)
Okay, if there is no warning glyph, then it seems to be able to find all the external functions.  There is just a run-time error on one of the machines.  Since this VI is in a project, the path settings it uses are actually in a different spot.  You need to right-click on the "My Computer" target and select "Properties."  From there, you will see the MathScript configuration options for the project.  The paths are saved with the project, so when you take a project to a new machine, they should be already set.  However, you may want to check this list on the problem machine to verify there are no bad paths.  Are you loading the VI from within the project on the problem machine?

Can you post what the run-time error message says?  What version of LabVIEW are you using?  Are you loading VIs that were created in a previous version of LabVIEW?

I am not sure why you would see the behavior with the probe.  My suggestion would be to try your code on a 3rd machine before reinstalling.  It may be that there is something specific about your good machine and not a problem with other machines.  Other than that, I'll need more information to help further -- the error returned from MathScript and your code if possible.  Even if it works on my machine, I'll have an idea of what you're doing (e.g. long scripts, nested .m file calls, etc.) to help more.  Unfortunately, I'll be out of the office next week, but I can help more when I return.

Grant M.
Staff Software Engineer | LabVIEW MathScript | National Instruments
0 Kudos
Message 8 of 9
(8,828 Views)
Solution
Accepted by j.masse

Grant - thanks for the help. I found another post regarding an "Error -90051 occurred at Error in line 68. You specified an invalid number of input parameters for this function." that I was getting in the popup window. It mentioned that he purposely broke the .m file so that LabView would see the broken .m file. He then restored the .m file to its original state and viola, LabView was happy. So I tried it and the same happened. After many days of banging my head, the solution was to have Labview see a broken .m file and then fix the .m file. Sounds like a LabView issue to me. Anyway thanks for the help.

Message Edited by j.masse on 08-26-2009 10:40 AM
0 Kudos
Message 9 of 9
(8,780 Views)