LabVIEW MathScript RT Module

cancel
Showing results for 
Search instead for 
Did you mean: 

Some Basic Features That Don't Appear to be Supported :(

So I'm tasked with getting some MathCAD documents converted into Mathscript so they can be easily used in my LabVIEW programs.  Looking over the documentation I have the following concerns:

 

1.  Is it possible to define a function in a MathScript node?  This does not appear to work in the same way as in Matlab.  I don't want to have a .m file for each of my functions.  I'd rather define them all in the MathScript node.

 

2. The whole "search" path thing is crippling to code portability.  Why can't location of my VI be part of the search path for .m function files.

 

3. Lack of indentation features :(.  How can I write a text program without a way to indent?

 

I'm sorry, but this is kinda crappy.  Please tell me that these things are supported and I'm just ignorant.

 

-Nic

0 Kudos
Message 1 of 9
(8,399 Views)
Just curious: How do you convert from MathCAD to Mathscript????
0 Kudos
Message 2 of 9
(8,395 Views)
I'm sorry.  Convert wasn't the right word.  Translate is a better word.  And you do it by typing and using your brain.
0 Kudos
Message 3 of 9
(8,393 Views)

"NOTE: Changes you make to the search path list apply only to the MathScript Nodes in the main application instnace." 😞 😞

 

Is MathScript still in beta?  Are we beta testing for National Instruments or something?  I'm sorry, but this is just sad.  This is suppose to be one of those "reasons" to get the Professional version over the base version of LabVIEW... it just leaves a lot to be desired.

0 Kudos
Message 4 of 9
(8,388 Views)

Nickerbocker wrote:

Is MathScript still in beta? 


Mathscript is a relatively recent addition to LabVIEW, and as such does not have the same legacy as plain G code. Still, it seems to work pretty well for most of us.

 

Mathscript received significant improvements in 8.6. What version do you have?

 

Personally, I tend to do everything with wires, because my brain does not work well within the confines of the limiting abstraction of text based code. Have you tried implementing your algorithm with wires instead? What are you actually trying to do?

 

If you feel you have a good idea on how to improve the software, I would strongly recommend to use the product suggestion center. 🙂

Message 5 of 9
(8,373 Views)

Thanks for the reply.  I'm running LabVIEW 8.6 (although I'm considering going back to 8.2, due to the buggy mixed signal graph indicator).  I have a few suggestions for NI on how they can improve Mathscript...

 

I got my code to run in LabVIEW, but it was a bit of a struggle.  I programmed for a couple of years using Matlab, and constructs are implimented a little differently.

 

Ultimatly, I think I am most dissapointed in the awkwark imlementation of the m-file paths.  This could be easily solved if the directory of the LabVIEW VI was automatically the first place to look for m-files (as it is in Matlab).  If I wanted to share my VI's and m-files with someone, I would have to explain how to put those m-files in their MathScript path.  Oh, right...if they need to debug it in the MathScript window they have to add the directory by using the "addpath" command <<sigh>>.

 

There are also some language differences.  LabVIEW cries foul with the "end" statement at the end of my function code, but for Matlab this is something to be expected.  I can have subroutines and functions in one file, but I can't have my "main" code in that same file.  So I have a "mymain()" function that contains my code, and the supporting functions beneath it.  Then in my MathScript block, i just call this mymain() function and supply the arguments that are wired to the block.

 

I would prefer to just have the code in the MathScript block, because that would give me easier access to it and the ability to troubleshoot my overall code quicker.

 

0 Kudos
Message 6 of 9
(8,365 Views)
Hello Nic,

Thank you for the feedback!  Let me address the issues you presented:

What multiple function definition behavior do you use in The MathWorks, Inc. MATLAB® software that you find lacking in LabVIEW MathScript?  LabVIEW MathScript is generally compatible with scripts written in the MATLAB language syntax.  One way to reduce the number of .m files you have for your user-defined functions is to write your functions in one file.  One caveat to this approach is that the .m file must have the same name as the first function defined in the file.  Also, any additional functions can only be called from within that file (that is, only the first function has global scope).  Unfortunately, it is not possible to define functions in the MathScript node at this time, but it is something we are considering.  There are other issues that come up when thinking about this.  Would you like the functions you define in a node to be available only to that node or to all other MathScript nodes on the diagram?  Or in that application instance?  Perhaps a way to select which nodes can access those functions?  Or a way to provide access to those functions to the MathScript Window, too?

The search path difficulty you speak of is present in other software as well.  If you move code to a different machine, you will first need to set the search path (perhaps with just a 'cd' command) before that software can find your code, too.  Searching the current directory to find .m files is a fundamental difference from the behavior of LabVIEW MathScript.  A problem with searching the same directory as the VI is that there is no directory until the VI is saved and you can certainly run a VI without saving it.  However, if you perform the same operations as you did in other software before running your code, you will find that MathScript works as well.  You can call the 'cd' function (note that you must enclose the path in single quotes, though) at the beginning of your node and then that directory will be searched.  However, using the 'cd' function results in reduced run-time performance of the MathScript node.

In LabVIEW, you can also drop a primitive to get the current VI's path.  You can strip the VI's name from the path and wire the path to the MathScript node.  You can then call the 'path' or 'addpath' command in MathScript to change the path.  These functions also have run-time performance implications in MathScript.  Due to the performance issues present with 'cd,' 'path,' and 'addpath,' we have implemented a more efficient way to set the search path.  It is as you discovered: go to Tools >> Options >> MathScript: Search Paths.  As you note, this will only affect the path of MathScript nodes in the main application instance.  If you wish to change the path for a LabVIEW project you've created, right-click on the "My Computer" target, choose Properties and then "MathScript: Search Paths."  If you wish to change the path for the MathScript Window, go to File >> LabVIEW MathScript Preferences >> MathScript: Search Paths.  Note that when you set a path in the main application instance, the locations of any .m files found in that path are saved when the VI is good.  If you transfer the VI to another machine with the .m files in the same relative location to the VI, they will still be found and you don't need to worry about setting the path on that machine.

You are absolutely correct about the indentation.  The text editing features are rather limited in LabVIEW and we are aware of it.  However, improving it gets prioritized below other features.  You can always use spaces to indent your lines.

Using the 'end' keyword to denote the end of a function definition is not required in MathScript.  If an error is thrown with the keyword present, this is most likely a bug.  I will file a bug report to investigate it.  For now, you can simply remove the end keyword from the bottom of each function definition.

Is it possible to have your "main" code in the same file as your function definitions in other languages?  I have not seen this mixture, but if you are mentioning it as a suggestion for improvement, it is best to use the product suggestion link that altenbach provided.  I can see how it would provide easier access to your code, but it would also be more limiting in terms of code reuse.

I appreciate your time in providing feedback.  I believe you can use the search path in MathScript in the same way that you are used to in other software, but setting the search path through the options dialog will result in better performance.  Filing a product suggestion will provide us with a formal mechanism for tracking suggestions.  If you can, please provide as much information as possible as to how you'd like functions defined in nodes to behave (note the questions I posed earlier).  If you have other comments, please feel free to let us know.

MATLAB® is a registered trademark of The MathWorks, Inc.

Grant M.
Staff Software Engineer | LabVIEW Math & Signal Processing | National Instruments
Message 7 of 9
(8,355 Views)

Hi!  Thanks for your reply Grant.  I'll fill out a suggestion form when I get a chance and have gathered my thoughts some more.  I do get an error with the "end" at the end of a function.  I'm pretty sure that it is a requirement in Matlab, but I do not own Matlab so I cannot verify.

 

I think NI should strongly the feature of searching for m-files in the working folder that a calling VI is saved in.   Matlab may require a "cd" command, however there is an obvious indicator of the working directory and this is integrated with the script editor file browser which makes it more-or-less transparent.  Basically, if I'm in Matlab and i send a buddy a number of .m files he can decompress them and use them with ease.  Just like in C programming, there are just rational assumptions to be made about other files that exist within the same folder.

 

I do like your suggestion of implementing the "cd" command using an input string that contains the current VI's folder.  It is a shame that this comes at a performance cost...I'm a little confused as to why this is but because of it I am reluctant to use it (most of my mathscript will be executed within LabVIEW loops).

 

I got my code working.  I used an external text editor with a tab feature to do it.  But it works, all the same.

Message Edited by Nickerbocker on 11-18-2008 04:39 PM
0 Kudos
Message 8 of 9
(8,347 Views)
Hello Nic,

We will consider adding support to search the current directory in a future release.  In the meantime, if you are looking for a simple location where you can dump a bunch of files and be able to call them without much effort, there is a default directory that MathScript uses for such a purpose.  It is your "My Documents\LabVIEW Data" directory.  MathScript will search that directory for .m files without any work on your part.

Note that if you set the MathScript search path through the Tools >> Options dialog, you only need to do this once.  This setting is saved on your machine and will be restored in your next LabVIEW session.  If you set the search path this way and then create a VI that calls many .m files from a directory you added, the locations of all the .m files are also stored when you save the VI after it compiles.  This way, you can send the VI and your collection of .m files to a friend and he can open it without having to worry about setting the search path on his machine.

The reason that 'cd' causes a performance issue is related to what the function does.  It changes the search path for MathScript at run-time.  You can pass any arbitrary string to this function, so there is no way for us to know which directory has been used.  This causes all of our decisions about which function to call to be delayed until run time, too.  By providing a list of search paths in the Options dialog, we can analyze the script ahead of time and generate appropriate code knowing that everything is well defined.

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