LabVIEW MathScript RT Module
MathScript Nugget #11: Advanced Features of User-Defined Functions
In MathScript Nugget #10, I introduced the basics of creating user-defined functions in .m files and calling them from the MathScript Window and Node. In today's nugget, we'll move on to some of the more advanced features of user-defined functions.
A .m file called from the MathScript Node is very similar to a subVI called from the block diagram of a VI. You can see this relationship in several ways.
First, .m files appear in the VI Hierarcy Window (View>>VI Hierarchy) just like VIs do. You can even see sub-functions and nested calls to functions. Here's the VI hierarchy for the "MathScript using Riemann Zeta" example that ships with LabVIEW. Notice how it contains both VIs and .m files.
The second way that .m files are like VIs is context help. As described in MathScript Nugget #2, if you view the Context Help Window (Ctrl-H) while hovering your mouse over a call to a user-defined function, you will see a bunch of information about the function: its name, path, and description (gathered from the first comment lines of the .m file). This is just like when you mouse over a call to a subVI and you see the icon, name, and description of the VI. I find the path information particularly useful when I'm trying to see which copy of my .m file LabVIEW is calling.
The third feature of .m files that's borrowed from VIs is the way they show up in the Error List Window. If your .m file contains an error, the VI that calls it will be broken. If you click on the broken run arrow, the error list window will show the user-defined function that's broken with a red 'X' next to it. This makes it really easy to find errors, especially if you're working on a large hierarchy of .m files.
Most importantly, if you fix the error and save the .m file, the LabVIEW will detect the change, the errors in the error list will go away, and you'll be able to run your VI.
The last way that .m files behave like subVIs is when you move your application. The calling VI stores a relative path to the .m files that it calls so that it can find them when you load it later. If you move your application to another directory or send it to someone else, MathScript will be able to find the .m files that it calls as long as they remain in the same location relative to the caller VI. You don't even have to set the MathScript Search Path. However, LabVIEW will only remember the relative location as long as the MathScript Node remains in a good state. If you continue editing it and cause it to break at any point, the location information will be lost and you'll have to set the search path to include the new location for LabVIEW to find the .m file again.
I should point out that the above features will only work in the MathScript Node (not the MathScript Window), and they'll only work if the caller MathScript Node doesn't have any warning glyphs.
Congratulations: now you're a MathScript user-defined Function power user!
jattas
LabVIEW MathScript R&D
ps. Check out all the MathScript Nuggets!
A .m file called from the MathScript Node is very similar to a subVI called from the block diagram of a VI. You can see this relationship in several ways.
First, .m files appear in the VI Hierarcy Window (View>>VI Hierarchy) just like VIs do. You can even see sub-functions and nested calls to functions. Here's the VI hierarchy for the "MathScript using Riemann Zeta" example that ships with LabVIEW. Notice how it contains both VIs and .m files.
The second way that .m files are like VIs is context help. As described in MathScript Nugget #2, if you view the Context Help Window (Ctrl-H) while hovering your mouse over a call to a user-defined function, you will see a bunch of information about the function: its name, path, and description (gathered from the first comment lines of the .m file). This is just like when you mouse over a call to a subVI and you see the icon, name, and description of the VI. I find the path information particularly useful when I'm trying to see which copy of my .m file LabVIEW is calling.
The third feature of .m files that's borrowed from VIs is the way they show up in the Error List Window. If your .m file contains an error, the VI that calls it will be broken. If you click on the broken run arrow, the error list window will show the user-defined function that's broken with a red 'X' next to it. This makes it really easy to find errors, especially if you're working on a large hierarchy of .m files.
Most importantly, if you fix the error and save the .m file, the LabVIEW will detect the change, the errors in the error list will go away, and you'll be able to run your VI.
The last way that .m files behave like subVIs is when you move your application. The calling VI stores a relative path to the .m files that it calls so that it can find them when you load it later. If you move your application to another directory or send it to someone else, MathScript will be able to find the .m files that it calls as long as they remain in the same location relative to the caller VI. You don't even have to set the MathScript Search Path. However, LabVIEW will only remember the relative location as long as the MathScript Node remains in a good state. If you continue editing it and cause it to break at any point, the location information will be lost and you'll have to set the search path to include the new location for LabVIEW to find the .m file again.
I should point out that the above features will only work in the MathScript Node (not the MathScript Window), and they'll only work if the caller MathScript Node doesn't have any warning glyphs.
Congratulations: now you're a MathScript user-defined Function power user!
jattas
LabVIEW MathScript R&D
ps. Check out all the MathScript Nuggets!
