...
Subsystems can be used to organize your layout into coherent groups. To create a subsystem, drag out the Subsystem module from the Subsystem folder, then double click or right click and select ‘Navigate In’ to design the internal system. If more I/O is needed, add System Input and Output pin modules from the Subsystem folder of the module browser. #SettingSearchPaths
...
You can navigate through hierarchies either with the tabs at the top of the canvas, or by right clicking the canvas and selecting ‘Navigate Up’.
...
Click and drag the entire subsystem module from the canvas and to the Module Palette, either on an existing module directory or in the empty space.
Right-click the subsystem module and select the “Create Reusable Subsystem” option.
A new dialog window appears, titled “Create New Reusable Subsystem”, with the following entry fields (see figure below). Complete and edit these fields accordingly for this Reusable Subsystem:
...
Root Directory - root folder for the Reusable Subsystem’s generated folders/files (see generated Folders/File section)
...
Class Name - Unique file name for the generated output files.
...
Browser Path - Category in which module will appear under in the module palette
...
If the subsystem was dragged onto an existing module directory in the Module Palette, this will be automatically populated with that existing directory name. Otherwise, this will be automatically populated with the new directory name “Reusable Subsystems”.
...
Browser Name - The name of the module that will appear in the module browser
...
Canvas Legend - The text which will appear in the reusable subsystem block when on the Canvas.
...
Search Tags - Search terms to locate this module in the Module Browser
...
Pin Data Types - Valid data types for module input pins (can select multiple types)
...
Compiled Subsystem – If checked, creates a Compiled Reusable Subsystem (see Compiled Reusable Subsystems)
Once the fields are set, click OK, and the Reusable Subsystem will be created.
...
...
Note: the standard subsystem is not automatically replaced with the new reusable subsystem on the canvas. This action is left to the user to drag out to the canvas needed.
Generated Folders/Files
When a user clicks OK and creates a new Reusable Subsystem, Designer generates the necessary output files and folders, and adds them to the appropriate MATLAB paths. The location of this generated output depends on the Root Directory that was entered at creation time. This folder structure should not be modified by the user to ensure the Reusable Subsystem’s compatibility with Designer. See below for information about the generated output.
...
By default, the module browser will filter out deprecated modules and missing modules (not present on the connected target). To toggle these filters, open the Designer File->Global Preferences dialog and toggle the “Show deprecated modules” checkbox. Beneath the checkbox, there is also a dropdown menu which provides the option to show all modules, filter by target, or filter by ModuleList.h (see below). Deprecated modules will appear in the browser with a yellow exclamation mark overlay, and missing modules with a red x.
...
Note: The image above was captured while connected to a target which does not contain the advanced module pack, therefore InvertN is missing.
...
If the layout’s Build Configuration is currently set to Debug, the Generate Target Files window will append “_debug” to the preliminary generated file’s “Save Basename” field. The user is free to edit the basenames before generating.
...
Note: Build configuration only affects the layout at the PC level. AWE uses a Designer->AWECore dynamic instantiation model, so the Debug modules are simply not instantiated on the target layout. Overflow Detection.
...
The CPU usage progress bar will turn Red, indicating that the CPU usage has exceeded 100 %. If the overflow condition is transient in nature, it is possible that the cpu bar may not show this condition.
The overflow detection LED (red dot) in the top right corner turns ON. The LED will stay ON until the Design is stopped, thus alerting the user of the overflow in the current run.
The CPU overflows counter on the top right corner counts the number of overflows detected across the layout (including clock divided sublayouts) until the Design is stopped. This count indicates that one or more overflows happened since the last time AWE Server queried the target for profiling values (by default this is done at 10 Hz). In theory the server could have missed some overflow events occurring at the target between the last query and the current query. As a result, this counter may not reflect the exact number of overflows occurring on the target.
...
Note: This feature is currently supported only for AWECore based targets and is not supported on Native or AWECoreOS targets.
...