02-11-2008 02:25 PM
02-11-2008 03:11 PM
02-11-2008 03:18 PM
02-11-2008 03:22 PM
02-11-2008 03:29 PM
Mappings might appear invalid if the model uses either Signal Storage Reuse or Block Reduction Optimization. These items are options you can set in the Simulink application software to reduce the memory footprint of the model. Disabling these options for the entire model makes all signals available for probing but increases the memory footprint of the model. You can mark individual signals as test points to maintain a reduced memory footprint while keeping certain signals available for probing. To make this change, load the model in the Simulink application software and perform the following actions:
For The MathWorks, Inc. MATLAB® application software release 13, right-click a signal and select Signal properties from the shortcut menu. Place a checkmark in the SimulinkGlobal(Test Point) checkbox and click the OK button to save changes.
For the MATLAB® application software release 14 and later, right-click a signal and select Signal properties from the shortcut menu. Click the Logging and accessibility tab, place a checkmark in the Test point checkbox, and click the OK button to save changes.
Note If you previously converted this model to a model DLL, you must convert the model to a model DLL again after marking signals as test points. |
Similarly, you might not be able to probe signals from Virtual Blocks such as Mux, Demux, Bus Selector, and so on. Marking signals from these blocks as test points makes the signals available for probing.
Refer to the Simulink documentation for information about Signal Storage Reuse, Block Reduction Optimization, Virtual Blocks, and test points.
You might not be able to manipulate model parameters if that model uses the Inline parameters option in the Simulink application software. This option writes a constant value to each model parameter. You must launch the Simulink application software and disable this option so the Simulation Interface Toolkit can manipulate the model parameters.
Refer to the Simulink documentation for information about inline parameters.
You can create mappings to parameters and signals of masked subsystems. However, if a subsystem is linked, or linked and masked, any mappings to parameters and signals of that subsystem appear invalid. Refer to the Simulink documentation for information about linked and masked subsystems.
If a model contains a subsystem that does not have any parameters or signals, that subsystem appears in the model tree when you create mappings. However, you cannot create mappings to/from that subsystem.
<SCRIPT type=text/javascript> if (typeof(Print_Link)=="function") { Print_Link(); } </SCRIPT>02-11-2008 03:34 PM
To debug the SIT RT vis you will need to create a project with your RT target and place the driver VI on this target. Your host VI will be on the windows machine. You would then deploy and run the driver VI from the project (you will need to ftp the model dll to the RT system directory) and can debug it just like a Windows based LabVIEW VI.
Instructions for adding RT targets to a project and debugging them can be found in the RT module How-to in the LabVIEW Help.
02-11-2008 03:47 PM
02-12-2008 12:36 PM
Hello,
Some update about the issue we discussed yesterday.
1. After I tried de-selecting the optimization options, the SIT connection manager was still set to run in local-host, so it did run correctly. But when it was changed to run on the desktop ETS, it again grayed out the screen, but no other errors. I also tried using a test-point on the signal line to be monitored, still the screen goes gray.Interesting thing is I am still getting an output from the DAQ card connected to the RT target. I can observe the signal on an oscilloscope connected physically through wires.
2. Also, I would like to get an idea if there is any minimum and maximum time-step that the desktop ETS can handle?Or is it solely dependent on how big the model is as this will increase the calculations while running the model? I have 1000e-6 as my time-step and the waveform coming out from the DAQ already looks stepped! SO increasing the time-step further is not the best option I guess…02-13-2008 06:18 PM
Hi Gayatri,
1. So you're not getting any error back? The code does send out the data. Is it not receiving the data properly?
2. It sounds like you might have reached towards the maximum end of the time step. Are you able to increase it any more? Does it change your signal?
3. If you have a bigger model it will increase the CPU Usage. However, the RT OS is meant to be be run at 100%, so CPU usage shouldn't be causing a TCP/IP error.
02-22-2008 10:02 AM