NI does not actively maintain this document.
This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
You can contact us by phone, email, or the discussion forums. Visit the NI Website to contact us. If you are contacting NI in regards to a specific issue, be sure to reference the ID. If you have feedback on this document, please contact NI on this NI Developer Zone post.
National Instruments is committed to maintaining compatibility with Microsoft Windows technology changes. However, NI has become aware of a number of issues of potential significance regarding Microsoft Windows 7. To learn how Windows 7 affects your use of NI products, visit ni.com/info and enter the Info Code windows7.
The following items are known issues in MathScript RT 2010 sorted by Date.
| ID | Known Issue | |||||
|---|---|---|---|---|---|---|
| 163320 Return | MathScript 'bitrevorder' function returns incorrect output vector orientation when called with a string When you call the MathScript 'bitrevorder' function with a string input, it returns both outputs as column vectors instead of row vectors. Workaround: N/A
| |||||
| 173387 Return | After removing functions that cause warning glyphs from User-Defined Functions, the VI looks broken After removing the function that causes warning glyphs in a User-Defined Function (UDF), the Run button of the VI looks like its broken and so do the wires. Workaround: Running the VI or clicking with the mouse inside then outside of the Node fixes the errors.
| |||||
| 194534 Return | MathScript node reports "Code could not be generated" when using Execution Trace Toolkit VIs When trying to use the MathScript execution trace toolkit functions, LabVIEW may return a "Code could not be generated" error for the MathScript node. This occurs if you are calling rt_starttrace, rt_stopsend, rt_stopsave, rt_loguserevent, or rt_loadsend and have not installed the Exeuction Trace Toolkit as part of the LabVIEW Real-Time installation. Workaround: Rerun the LabVIEW Real-Time installer and select to install the Execution Trace Toolkit.
| |||||
| 194964 Return | RT Target may crash when closing the block diagram of a running VI with the MathScript Probe If you are running a VI on a Real-Time target with a MathScript Probe attached to a MathScript node, closing the block diagram may cause the target to crash. Workaround: Close the MathScript Probe before closing the block diagram.
| |||||
| 195525 Return | MathScript search path incorrectly shows one of the paths to be invalid When the project is moved, one of the paths in the search path wrongly shows up as invalid. Workaround: After saving the project, open the search path page and click ok.
| |||||
| 235596 Return | Mathscript RT Module for MAC will not install on LabVIEW 2010 Evaluation While installing the MathScript RT 2010 Module for MAC on top of a LabVIEW 2010 Evaluation version, the MathScript Module installer reports that "You cannot install LabVIEW 2010 MathScript RT module on this volume. LabVIEW 2010 must be installed first." Workaround: N/A
| |||||
| 174668 Return | Removing inner function in .m file breaks VI When a referenced .m file contains two functions, one of which calls the other, removing the bottom function (and changing the top function to not depend on it) breaks the caller VI. Workaround: This is just an extraneous error appearing in the error list window. If all the other errors in the caller VI are fixed, the VI becomes good.
| |||||
| 193443 Return | Deployment to RT fails when the Matrix datatype is wired to a MathScript node Deployment to RT target fails when the Matrix datatype is wired to a MathScript node Workaround: Use the 'Matrix to Array' primitive to convert the Matrix data type to array before wiring to the input of the MathScript node.
| |||||
| 279908 Return | Subplot window can not be closed If two subplot windows are created, the old one can not be close by the x button on top right corner of the plot window. Workaround: N/A
| |||||
| 210391 Return | DAQ MathScript aoch function creates wrong task type This should create a software timed analog output function that performs a single point update. Instead, it creates an Analog Input Custom Voltage with Excitation task and tries to assign the analog output channels to this analog input task Workaround: N/A
| |||||
| 226729 Return | Error -90001 when no solution exits with linsolve When the input matrix is near singular. linsolve returns an error because no solution exists. However, currently the error returned is not indicative of this. The current error is -90001: A problem occurred in a subVI call. Workaround: N/A
| |||||
| 232284 Return | Attaching a probe to large MathScript Node while running on RT can cause connection loss If a large MathScript Node is running on a RT target and you try to attach a probe, you occasionally lose connection to the target. If you then reconnect, the probe will work normally. Workaround: N/A
| |||||
| 234573 Return | Auto-detect output does not return a strings datatype For some specific scripts, the MathScript node will have no auto-detected type for an output that should be a string. Workaround: N/A
| |||||
| 234580 Return | Running 'clc' clears the output of some commands executed after calling it If 'clc' is used, it should clear the output window then run the script that follows it. The output window should populate with the output of the rest of the script. Instead, 'clc' ' clearis the output of some of the later commands in the same script. Workaround: N/A
| |||||
| 242487 Return | Cannot drag multiple variables between local and global categories If multiple variables are selected from the tree in the MathScript Window and dragged between local and global partiton/variable, only the one will move. Workaround: N/A
| |||||
| 281000 Return | LabVIEW MathScript hangs when calling a large model When loading a script with a large model (generated from another software tool), LabVIEW MathScript will hang. This behavior is due to the fact that LabVIEW runs out of memory when processing such a large model. Workaround: N/A
|
Document last updated on 7/22/2011