LabVIEW running in Windows supports Matlab script nodes, which allow you to embed Matlab script directly into a LabVIEW diagram; however, this requires that the Matlab engine also be running in the Windows operating system.
The real-time operating system used by LabVIEW RT does not support the Matlab engine and consequently does not support Matlab script nodes. However, if you translate the script into C, you might be able to run it under the real-time operating system via a code interface node or call library function in LabVIEW. The code interface node allows you to link to external C code, which has been compiled into a LabVIEW sub-routine, while the call library function links DLLS to LabVIEW.
We do not yet officially "support" the use of call library nodes or
code interface nodes in the real-time environment, but I do know that customers are doing it and have been successful. The reason we do not officially support these nodes is because there is currently no way to debug the compiled external code from within the LabVIEW environment, and we also do not publish a comprehensive list of all supported functions.
Hint: The real-time operating system supports a significant subset of the Win32 API and I would imagine most (if not all) of the ANSI C library. Again, this is not officially supported yet, but it is possible in many cases.
To answer your other questions, LabVIEW allows the user to establish code priority, which is fully respected by the real-time operating system we use. As for RS-232, this is a handshaking protocol and is therefore not a capable of "real-time" performance. When performing instrument control via RS-232 or GPIB, we recommend a multithreaded application, which confines the instrument control to a separate lower pr
iority thread, allowing the time-critical code to operate in its own high priority thread.
