Archived: LabVIEW 8.0 MathScript Known Issues and Limitations

This list is not meant to be comprehensive; it is intended to make you aware of some key issues and to explain how to improve the performance of your code. We are dedicated to improving LabVIEW and MathScript. Patches and/or future releases of LabVIEW might fix or change the status of these documented issues and limitations.

MathScript does not work with extended ASCII characters or localized decimal separators
LabVIEW 8.0 MathScript does not currently support the LabVIEW Application Builder
LabVIEW 8.0 MathScript does not support MEX files (executable .m file scripts), sparse matrices, arrays with greater than 2 dimensions, cell arrays, or structures
User-defined function names in MathScript are case sensitive
You cannot specify default values for optional parameters in user-defined functions
LabVIEW 8.0 MathScript does not support 'return' and 'end' keywords
You cannot place a MathScript Node directly inside simulation diagrams from the LabVIEW Simulation Module
When you use a linear index on a matrix, LabVIEW returns the output in the same shape as the indices, and the reshape of the matrix incurs computational overhead
The destination for multiple function outputs cannot be an element of a matrix
MathScript does not share global variables between two application instances
Storage of variable state information in a loop imposes computational overhead if performed outside of a MathScript Node
The calendar function does not work if the system date format differs from the U.S. format

•  MathScript does not work with extended ASCII characters or localized decimal separators:
  
  This issue only affects:
  • English LabVIEW 8.0 running on a non-English, localized version of Windows.
  
  This issue does not affect:
  • English LabVIEW 8.0 running on an English version of Windows
  • Localized (non-English) LabVIEW 8.0 running on a non-English, localized version of Windows
  
  If you try to create a variable name or a string that has an accented character (for example, ChaîneDeux in French), MathScript returns the error “The current MathScript could not be executed. Please contact National Instruments with the script.” In addition, LabVIEW must not be installed on a PC with a user name that includes foreign characters or in a directory where any character in the full path to the LabVIEW executable contains an accented character, or MathScript does not work.
  
  The issue with the localized decimal separators is that MathScript only works with a period as the decimal separator. However, MathScript is built on top of LabVIEW. Since LabVIEW works with the system-specific decimal separator, this causes problems for MathScript. For example, x = -1:0.1:1; results in the error message, "You cannot specify a step size of zero for a range."
  
  You can use the following workarounds for the localized decimal separator issue:
  
  1. Change your system locale settings to English (or at least change the decimal separator to a period). The side effect of this is that all applications now use the new settings.
  2. Change the LabVIEW settings to ignore the system-specific decimal separator. To change these settings, select Tools»Options from the LabVIEW menu bar. On the Front Panel page, remove the checkmark from the Use localized decimal point checkbox. This change affects all LabVIEW VIs.
• 
  The issue with extended-ASCII characters is fixed for strings in LabVIEW 8.2. LabVIEW 8.2 MathScript does not support non-ASCII characters in variable names.
  
  
•  LabVIEW 8.0 MathScript does not currently support the LabVIEW Application Builder:
  
  After creating a VI-based application, you might want to create a stand-alone application or DLL to distribute the application. If any VI in your application uses a MathScript Node, you cannot build the application into an executable with the LabVIEW Application Builder. LabVIEW does not generate an error, and there is no workaround. Do not use a MathScript Node in LabVIEW applications that you intend to build.
  
  NOTE: Some very simple MathScript functions might build successfully into an executable, but overall, this functionality is not supported in LabVIEW 8.0.
  
  Fixed in LabVIEW 8.2.
  
  
•  LabVIEW 8.0 MathScript does not support MEX files (executable .m file scripts), sparse matrices, arrays with greater than 2 dimensions, cell arrays, or structures:
  
  The following line is an example of a cell array:
  
  A = {magic(3) 6.9 'string'};
  
  The following line is an example of a structure:
  
  a.day = 12;
•  
•  User-defined function names in MathScript are case sensitive:
  
  When you call a function foo defined in foo.m, you must type foo(x).
  
  Some .m file scripts expect case insensitivity. Therefore, if you call the function FoO(x), the function call does not work. All built-in functions already are case insensitive.
• 
  Fixed in LabVIEW 8.2.
  
  
•  You cannot specify default values for optional parameters in user-defined functions:
  
  This is typically done in other third-party math software by using the nargin function call to determine which inputs were provided and then assigning values to any missing arguments. LabVIEW 8.0 MathScript does not support the nargin and nargout functions. To call a function that is written to use default parameters, you must remove the calls to nargin and nargout and always provide all arguments. Because there is no current method to determine how many output arguments were requested, you should compute all outputs.
• 
  Fixed in LabVIEW 8.2.
  
  
•  LabVIEW 8.0 MathScript does not support 'return' and 'end' keywords:
  
  LabVIEW 8.0 MathScript does not support the return keyword used in other third-party math software. LabVIEW 8.0 MathScript also does not support the end keyword in matrix indexing. The return keyword is used to break execution and return from a function before reaching the end of the function definition. The following example shows a script that does not work with LabVIEW 8.0 MathScript:
  
  function c = foo(a, b)
if a == 2
return;
end
c = 5;
  
  You can use a flag variable as a workaround. Instead of issuing the return statement, set the flag variable to a certain value. Enclose the code following the old return statement in an if statement that checks the value of the flag variable.
  
  The following examples show scripts with the end keyword in matrix indexing that do not work with LabVIEW 8.0 MathScript:
  
  B = A(2:end)

B = C(2:end, 4)
  
  A workaround for the first example depends on whether A is one- or two-dimensional. In the one-dimensional case, you can use the length function instead of end, as shown in the following example:
  
  B = A(2:length(A))
  
  In the two-dimensional case, you can determine the size of the matrix and calculate the total number of elements, as shown in the following example:
  
  [m n] = size(A)
B = A(2:m*n)
  
  If you specify two indices, as in the second example, again determine the size of the matrix and use only the size of the dimension you need:
  
  [m n] = size(C)
B = C(2:m, 4)
• 
  
  Fixed in LabVIEW 8.2.
  
  
•  You cannot place a MathScript Node directly inside simulation diagrams from the LabVIEW Simulation Module:
  
  Currently, you cannot place a MathScript Node directly inside a simulation diagram. For a workaround, create a subVI with the MathScript Node and all necessary inputs and outputs. Drop this subVI into the simulation diagram, and it works as expected.
• 
  
  
•  When you use a linear index on a matrix, LabVIEW returns the output in the same shape as the indices, and the reshape of the matrix incurs computational overhead:
  
  For instance, the following example indexes all odd elements:
  
  A = rand(1000);
B = A(1:2:1000000);
  
  This example involves a reshape of the matrix and currently incurs a large performance overhead. You can achieve better performance by bringing the matrix back into LabVIEW (with a MathScript Node output variable) and performing the indexing operations on the diagram. In general, indexing a matrix decreases performance. If possible, structure your code to perform matrix operations as a whole rather than operating on individual rows, columns, or elements.
• 
  
  Fixed in LabVIEW 8.2.
  
  
•  The destination for multiple function outputs cannot be an element of a matrix:
  
  For example, if function foo returns two values, you cannot place either of the outputs directly into a subset of a matrix. If you do place the output directly into a subset of a matrix, MathScript returns the error “The current MathScript could not be executed. Please contact National Instruments with the script.” The following line provides an example of this usage that does not work in LabVIEW 8.0 MathScript:
  
  [vs(m, n) s] = foo(...)
  
  As a workaround, perform a two-step assignment:
  
  [a s] = foo(...)
vs(m, n) = a
• 
  
  
•  MathScript does not share global variables between two application instances:
  
  If you create two separate projects with a MathScript Node in each project, and you try to communicate between the two using MathScript global variables, the nodes in their respective projects do not see the global variables from the other project. Currently, the MathScript environment is linked to an application instance. As a workaround, bring the variable back from the MathScript Node and write it to a shared variable. You can read from the shared variable in the other project. In addition, only one LabVIEW MathScript Window can be running in any application instance at a given time.
• 
  
  
•  Storage of variable state information in a loop imposes computational overhead if performed outside of a MathScript Node:
  
  When you implement an algorithm in LabVIEW, you can choose graphical (native LabVIEW code), textual (LabVIEW MathScript), or a combination of graphical and textual. You can choose an approach based on personal preference or to improve code clarity. Choosing between one or the other also can affect execution performance. For example, as shown in the following figure, you might move a For Loop outside of a MathScript Node. Doing so decreases code performance and introduces some overhead due to the variable state being saved between loop iterations. You can avoid this overhead if you implement the loop entirely in MathScript because writing the loop in MathScript is more efficient.
  
  
•  The calendar function does not work if the system date format differs from the U.S. format:
  
  A common date format in some parts of the world is to return the day first (for example, 17/10/2005). This format causes the calendar function to return an error that states, “A problem occurred in a subVI call.” As a workaround, change the date format for your locale.

Refer to the LabVIEW MathScript section of the LabVIEW 8.6 Readme for more information about MathScript known issues in LabVIEW 8.6. You may also search through former LabVIEW version's readme documents for issues in those versions.