date=2021-03-16
History: This FBlocks for building data structs are defined newly about march-2019, used in some applications, but are documented yet only now in 2020-january. Some changes were done in 2021-march, especially the syntax of the data was changed, with more capabilities.
1. Approaches
Object Orientation
ObjectOrientation as such means, bundling of data to their operations. For Simulink FBs (Function Blocks) it means, any FBlock, or Module, has its specific data. The assembled data of a FBlock or Module can be presented and forwarded with the simulink standard equipment via a bus. But how it is with set-operations.
Using FBlocks written in C or C++ offers the possibility to store data. Simulink supports it using S-Function. The here presented S-Functions stores data programmed via parameter. It is not necessary to compile the S-Function depending on the modelling requirements.
Code generation support, Accelerator:
For code generation (Simulink embedded coder) this FBs produces a Headerfile while simulation is started which presents the connected and parametrized values in a struct with access operations (getter, setter). The tlc-File to control the target language compiler for the Simulink coder takes special run-time-parameter, which are produces too on runtime of the FBs. So the generated code is optimized for access to the bundled data depending of the model-specific properties of the instances in the model.
Access to the data via inspector:
Last not least there is a FBlock Service_Inspc and one or more tools to access the data. The Service can also run in the target system, the data are bundled ObjectOriented there too. It is data viewing, which is an important medium to explore and evaluate the software in runtime.
2. Special data struct FBlocks in C
@ident=structC
It is possible to program the data for the graphic modules in typedef struct definitions with getter and setter operations which are compiled as special Sfunctions, see [[Topic:.Smlk_de.C_ObjO.genSfH.].
For special issues a special solution in C as Sfunction may be proper.
The disadvantage for a common usage is: Small changes in the model may need adapting in the C-sources and newly translating the Sfunction (mex-Compiler). It is a break in the concept of the currently engineering.
Therefore a set of Sfunctions ready to use are provided in the lib/Inspc.slx Library. This library is favorized because the data are able to inspect too. The service_Inspc is not necessary for this FBlocks. See next chapter.
3. Overview …DataStruct_Inspc FBlocks
@ident=dStructFB @date=2020-01-12
The right image shows the FBlock in the library:
The both left Types DataStruct definition FBlocks should be placed in a module to build the data struct.
-
DataStructMng_Inspcis the managing FBlock for one data struct. The number of inputs depends on parametrizing. An example is contained in the LibrarylibVishia_Incpc. -
DataStruct_Inspcextends the inputs. It builds a chain with any number of it and the only onDataStructMng_Inspc. This chain can be used to arrange some data inputs in several positions of the 'module'-FBlocks or maybe in local subsystems of this FBlock model.
The right shown Types of DataStruct access FBlocks can be places especially in other modules or in the same module for data exchange. The comment on the library and the given templates for parametrizing may shown its functionality.
The input of this FBlocks is a handle (as reference). This handle can be connected to all other handle outputs, not only to the DataStructMng_Inspc. The access is done via reflection: In the initial phase the correct data are searched by the given (parameter) access path. In the run phase this address is given, stored and used. Hence the access is fast.
Because the input is for the initial Tinit time, the connection is always an Aggregation (UML), not an Association which can be changed during run time.
-
getTinit_DataStruct_Inspc: Reads and positions a value in the initial phase. The value is unchanged in Runtime. The initial phase is finished only if this value is available. Usual it is an handle (reference) to another datastruct. But also values can be gotten initially. -
get_DataStruct_Inspc: Reads and positions a value from the appropriate datastructin the run time. There is anytime a delay of 1 (unit delay) between written value and read value though the writing (into aDataStructMng_Inspcor viaset_DataStruct_Inspc). Hence no numeric loops can occurre. This behaviour is achieved by invoking the update routine (instead output), which is executed on end of a step time operation. -
set_DataStruct_Inspc: Writes a value in the run time to the appropriate datastruct. -
callFn_DataStruct_Inspc: This is a specific operation which uses the function call capability (Function-Call Subsystem) of simulink, respectively it is an event mechanism. -
trgFn_DataStruct_Inspc: It is the opposite functionality to trigger a Function-Call Subsystem to execute an event.
The last both operations are able to use as a method call in Object Oriented thinking, or especially as an event mechanism. It can be used for events for Statechart-FBlocks. This functionality includes a event queue for the function calls, able to use for a standard event-queue behaviour for state charts in Simulink adequate to the approaches for example in UML (Harel-Statemachines).
4. Inspector data access
The FBlocks to build and access Data are arranged in the Library lib_Inspc.skx because a substantial feature is the assignability to data with the Inspector Service.
The access via Inspector is a core feature. It was originally developed for data access in embedded target systems (programmed in C or C++) and adapted to Simulink especially for C-S-functions. Because of data of the object oriented approach should be able to view and set with diagnose tools, the Inspector approach in integrated here, but it is not necessary for work only with the data structures. Especially the service_Inspc FBlock is only for simulink and should be placed outside of code generation. For the inspector service in the target system special C-sources are necessary which are adapted to the special conditions of the target.
The right image shows the clipping from the lib_Inspc with this FBlocks. A part of the image above (chapter above) is visible. The first output of the DataStructMng_Inspc is an adequate node input for the add_DataBide_Inspc. It it is added as data node is is arranged in the data tree of the inspector viewing tool. The same can be done with any user-defined S-function which has reflection deterministic (it is necessary to define the data).
The only one time necessary service_Inspc processes the data traffic with the viewing tool of the inspector, via socket connection. The right GetValue_Inspc FBlock enables access to any data which is added as node, from the simulink model level.
The time signal Function blocks, containing in this lib_Inspc too, can be added as node too (not shown here, see [[todo].
5. Examle of the DataStruct_Inspc FBlock family
The following application notes are derived from a example model src/test/Smlk/+InspcCtrl/InspcCtrl.mdl, see referenced zip file. The model contains two PID controller, one with simulink standard FBlocks (from Continous-Standard-Library), the other one is created as S-Function from the libVishia_Ctrl library. The model contains a parameter optimization with measurement of the area of the controller deviation. The data between the modules are exchanged with the DataStruct…Inspc FBlocks from the libVishia_Inspc library.
5.1. Example with DataStruct_Inspc FBlock usage
The FBlock with 'M' named thiz is the DataStructMng_Inspc from the lib_Inspc.slx. The Inputs are connected from several signals inside this module. The types and sample times of the signals can be different. In this image the types are visible (Display - Signals and Ports - Port Data Types) is switched on to demonstrate it.
The output of this FBlock is a handle as uint32-type in the Tinit-Sampletime. It is named controller because it presents the data for the module. The handle is converted to a pointer to the data in the using Sfunctions, for target code the handle presents the 32-bit-memory address of the data immediately and optimized.
The inputs 5 and 6 are handle from other DataStructMng_Inspc-Fblocks and from C/++-programmed S-Functions which uses Reflection. In this example the pid2 is the thiz-Output from the PID_Ctrl FBlock which is such an S-Function. The value is a handle which is transferred in the Tinit-time (here designated as D2). In ObjectOrientation associations and aggregations are distinguished. That are references to other Objects. Aggregations are connected in the startup phase, and after them they are fix. Associations can be switched on runtime. That is the wording of UML. The Tinit step (or sample-) time is the one where initial wiring for aggregations are done. It is support by this FBlock: The special feature is: The types of the input references are checked. It is a type check on startup time in this module, independent of this feature the types are checked in the using Blocks again. The type check here helps to detect model errors local in the module.
The Number -22 for this both Inputs is a designation for access rights for the Inspector tool. The access and changing of values can be secured via a password.
The right image shows an example from another module, it is the parameter optimizer module which has its own data. In this case the data f_Y12 is associated via a small get_DataStruct_Inspc connected via the thiz From - Goto pair instead directly usage of this signal. It is a delay of one sample step because the calculation order is: writing to the thiz-FBlock is done at least (it is a data destination in data-flow-order), but reading from the f_Y12-FBlock is done first, it reads the value from the last sample time. This is a principle. Access to the data accesses the data from the last sample time inside the same module.
5.2. Example of a set and get in another module
Image: Application access example
The image above shows the access to the data of the struct of the last chapter. It is assigned in another module via a port connection. The Fblock after the inport checks the type of the handle on runtime of Simulink and determines the type of access for the generated code via tlc-files. It is get_DataStruct_Inspc FBlock with the shown above parametrizing: Only the input type will be checked (in Simulation startup time) and determined (for code generation, access in tlc-File). The output is the same handle as the input.
The 2 connected FBlocks read data. The =par_PID gets the value on init time for aggregation, in this example from the parameter Fblock to the PID controller FBlock. The yellow values shows handles which represents pointer values. The f_Y12 outputs the value of the Variable f_Y12.
The DataStructMng_Inspc and DataStruct_Inspc can define a variable but set it only with an initial value. This possibility should be discussed under the Object Oriented aspect:'
The image right shows a set_DataStruct_Inspc FBlock for the signals tunefY12. This signal is build in the controller and set into the data of the module parOptimizer. From view of the parOptimizer it is an input for the optimizing process. The parOptimizer determines the meaning of this input. The controller should deliver the proper signal on run time. But an initial value is set on the appropriate DataStructMng_Inspc FBlock in the own module. The set_DataStruct_Inspc is, so to speak, a set operation (setter) which can called from outside for an Object (the module).
5.3. Example of polymorphism
The polymorphism is an important capability of ObjectOrientation: An instance can be associated via an basic type, the usage should not know the exact implementation type. This helps to deal with several versions of implementation, maybe because a development progress, maybe because different implementation variants in a more universal basic frame. https://en.wikipedia.org/wiki/Polymorphism_(computer_science)
The below image shows an enhancement from a DataStructMng_Inspc chain of Type Controller_ObjMod to a Type Controller_B_ObjMod. The story to do so is:
-
Firstly the right FBlock of DataStruct are defined for the module. Other modules uses this Type
Controller_ObjMod. -
As an enhancement of this module more signals should be used in its interface to outside. Some other connected modules and the test environment will be used them.
-
It may be easy to enhance the given DataStruct organization with the some more signals. But in this case all using modules should be compiled newly, because the data
structis changed. But some of the modules are tested already and the developer team cannot spend time to adapted the module. They should be left unchanged. -
Another story may be: One or some connected modules need a more universal interface. They should be connected to several special incarnations of this module type but with a more universal access. This story is the common approach for using polymorphism in ObjectOrientation. The story above is a story from the practice.
Image: Super and Sub Type with DataStructMng
The solution, showing right, shows the first interface unchanged, with the right FBlock of DataStructMng_Inspc. The output type is unchanged, it is Controller_ObjMod. The generated header files are unchanged (important!).
The left FBlock thizsub is the new one. It is a DataStructMng_Inspc too which thiz-Output is connected to the 7. input of the otherwise unchanged DataStructMng_Inspc right. In the right DataStructMng_Inspc-Fblock there is a checkbox inherit in the parameter dialog. Because of this connection the left DataStructMng_Inspc receives the Type and the memory amount from the right one, via back writing via the given reference. The left DataStructMng_Inspc creates the memory for both and assigns the data of the right one as superType, it is inheritance for C++ or a embedded struct on start of the sub struct for C.
The output pointer refers really a data struct with the more comprehensive data of Type Controller_B_ObjMod but the access type is Controller_ObjMod nevertheless. This is the known subtype/superType arrangement from inheritance in ObjectOrientation.
5.4. Example Access into sub modules with polymorphism
This right image shows the access to the polymorph given data inside the controller, but the polymorphismus is not considered here. The common thinking situation is the following: Another component may use a module in its originally or basic form, without knowledge of any derivation. This is true especially if a derivation in a specific module was done for specific requirements, but the other existing and reused components will be stay unchanged. No adaption should be necessary. The input myDevice is connected from myDevice from the image below. The input type Device_ObjMod is given to check in simulation, and for code generation. It checks the correct type in Simulink startup-runtime and forces an error message on faulty connection. That is important because the input is somehow wired, errors are possible.
The output of this =controller determines the type of the known controller, not the really derived type. See the image "Super and Sub Type with DataStructMng" in the chapter above. The real accessed data are of type:
typedef struct Controller_B_ObjMod_t {
union { Controller_ObjMod_s super; ObjectJc object; } base;
float test[2];
} Controller_B_ObjMod_s;
~ but that fact is unknown in this module. From this view of the Controller the shown values are read (a getter access) and evaluated in this module.
The yellow boxed area can be a Fblock in a Simulink library. The Controller_ObjMod can be established as one library. Then it can contains some such yellow Fblocks. This Fblock can be considered as operation of the class `Controller_ObjMod`. It is a static (not dynamic linked) operation. The calling of a class-operation in C++ is exactly the same as the usage of a lib-module in Simulink.
5.5. Function call, overridden operations, dynamic linkage
To work with dynamic linked operations (virtual), the operation cannot be included or called immediately, in C++ it is linked on runtime via the so named virtual table. The proper counterpart in Simulink is a Triggered Subsystem, see [[!../../smlk/html/TriggeredSubsystem.html]. The triggered subsystem is arranged inside the maybe inherited main module for the controller, the inherited module can contain another incarnation for the triggered subsystem. The trigger is forced in the using module. The trigger does not know what is executed, that is the late linkuage of dynamic calls.
…TODO
5.6. Object Oriented and modulare view in graphical programming
A modular design is subdivided into components, higher-level and sub-modules. This is particularly noticeable in graphic programming.
The following wording is used, in coordination to the wording of ObjectOriented inheritance and abstraction with the subType and superType:
-
A component is a part of an application.
-
A component may consist of sub components and modules.
-
A module can contain sub modules. Notice that in Objectorientation a subType is a more specialized but more comprehensive type as its superType, the more abstract one. Therefore the wording 'superior module' for a more comprehensive or parent module is not used to prevent confusion to the wording 'superType'.
-
The interface to a sub module can present by a subType which’s superType is a more abstract type. The sub module is contained in its parent module.
-
A parent module is the module which contains a considered module.
-
A function block (Fblock) is the usage of a module in a Graphical Programming Diagram. The FBlock can be a module which contains some more Graphical connected Fblocks inside, or a module from a library which can present an operation of a class (see chapter above), a standard Simulink Fblock or a Sfunction, which’s content in written in C(++) or maybe as Matlab script.
-
An Fblock can be considered as operation. In conclusion an operation can be present as module. Of course inside it can call other operations, which are present as FBlocks or sub modules.
-
An operation is the same as a 'method' in ObjectpOriented slang. The usage of the wording 'operation' instead 'method' is ordinary in UML too.
The usage of wording module is related to instances in this focus. 'Module' is also used for the structure of sources in programming, but that is another direction of thought.
image:../../../smlk/img/Parent_DataStruct_sample.png|parent dataStruct]
With this linguistic basics let’s have a look to build parent modules. The image above can be designated as a component, or a parent module of some sub modules. It does contain only less processing of signals, more interconnections of its sub modules. The DataStruct of this component or parent module is build in the same way as a all DataStruct in the above examples. Only the input signals are typical outputs of the sub modules. Because the DataStructMng_Inspc does not gather signals in the Tinit initial step time, some signals of the fast step time are connected. The other TinitDataStruct_Inspc (here only one, typically maybe more) gathers the Outputs from the modules which are aggregations to the sub modules from view of this module, wired in the Tinit step time.
The type of data of the myDevice is Device_ObjMod, appoint as parameter in the DataStructMng_Inspc FBlock.
The used wording is:
-
abstraction for a more universal view to a module.
-
superType for the abstract access.
-
subType for the implementing data definition
-
inheritance: Usage of a more universal class (module) to build a more specialized comprehensive module.
-
derivation: Describes the relation between a subType and its superType, derivation and inheritance are synonym. The inheriting module has the subType.
-
Type is the C-type of a reference. It means the Type of a class of C++ too.
-
class is more comprehensive as Type. A class contains the usage as type, and all defined attributes and operations. From view of Graphical Programming a class can consist of more as one function blocks. Each FBlock can present an operation of the class. They can be assembled in a Simulink-library which presents the class.
This terms should be applicated to GraphicalProgramming with Simulink now.
6. Parameter Dialog for the DataStruct FBlocks
@ident=dataStructPar @date=2020-01-12
This chapter describes the exact writing rules to the examples in the chapter above.
6.1. Parameter of FBlock DataStructMng_Inspc
The DataStructMng_Inspc has the following parameter:
-
filedir - genSource: Usual you should use a string variable here, not a
'string literal': If the variable contains'', an empty string, no header will be generated. This is proper for only simulation, especially on a repeated simulation loop. The String should be set with the directory path (absolute or relative to the simulink working dir) if the simulation is running before code generation is done. Then a headerfile with the Type of DataStruct as filename`.h` will be written in this directory. It presents a Cstructwith the given connections including access routines (get/set) proper to all connected get/set_DataStruct_Inspc FBlocks. This header is used for code generation (Simulink Embedded Coder). The tlc-File for this FBlock is prepared to include this Header with invocation of the getter and setter instead the FBlock code. Therefore some so name Runtime-Parameter are written internally inside the Simulink data which are used in the tlc-File for target code generation. With them the FBlocks for …DataStruct_Inspc are optimized for the target code. -
Type of DataStruct: This is the name of the created header file and the name of the `typedef struct ` inside the header. It will be used in the generated code. For inspector access this is the type name, not the name of the reference, see FBlock add_DataNode_Inspc.
-
If the checkbox inherit is set, an additional input (the last if chain is not set, else before last) is given which should be wired from the first output of another DataStructMng_Inspc-FBlock, as shown in the image (snapshot from the
libVishia_InspcSimulink-library). That is the enhancement to the sub (more comprehensive) data structure where this dataStruct is member of, a super struct. If this checkbox is not set, no input for that is given. Note: For inheritance nestedstructare used, possible with programming in C. C++ classes are not used till now. -
If the checkbox chain is set, an additional last input for chaining is given. This input should be wired from the only one output of a DataStruct_Inspc FBlock, which can add more inputs of data. See image.
-
inputs: It is a free text field but with a well defined syntax. The content will be evaluated on start of the Simulation, it determines the built data struct in memory, its reflection information, the content of the generated header file and the number of data inputs.
The content of inputs is parsed using the C implementation of the java class org.vishia.util.StringPart which was originally translated from Java2C. It is found as emC/J1c/StringPartJc.c. The parsing algorithm is manually written contained in emC_Inspc/Inspc_FB/DataStruct_Inspc.cpp in the operation parseLineDef…(…). It can be described with ZBNF-Syntax. The ZBNF parser is not used here, but the syntax definition in ZBNF language shows the parsing algorithm. The ZBNF syntax description language is explained on the fly. It may be intuitive understandable, it is similar BNF (Backus Naur Format) or EBNF:
-
An important difference to EBNF and Xtext is: The terminal symbols are written immediately, not in apostrophes. But also the syntax control characters are written immediately. To distinguish it from text characters, this specific text characters are written with a leading backslash
\as transliteration, as known for\netc. as in C/++. It is
\[ \] \{ \} \< \> \| \? \. \ \\ \n \r \t
-
A syntax definition starts with
name::=as in BNF. The dot.is the end of a syntax definition. A dot in the text is written with\. -
A space in the syntax script can be a white space with comment in the input. To force a space `\ ` is used (backslash with following space).
-
[…]is optional input,[…|…]is a choice (alternatives),[…|…|]means one alternative, or nothing. -
{….}is a repetition,{….?….}is a repetition with back bough, repeats only with and if the part after?matches. -
<subsyntax?semantic>represents a sub symbol,<$?semantic>is an identifier with the given meaning,<#?number>parses a number.
The main syntax is:
inputs::={ <variabledef> ? [ ,<?copyProperties> | ; ] } [;].
The inputs consist of several variabledef in a loop, separated by , or ;. A terminating ; is optional but recommended. If a , is used, the semantic <?copyProperties> means that the next variable has all the same variableDef properties except the name. Any variabledef Defines one input for the FBlock.
A <variabledef> contains:
variabledef::=
{ = <?mInputInit>
| ( <$?structType> )
| [{<$?path>?\.}]<$?name>
| -<#?accessRights>
| : [ <simpleTypeChar> [{ * <#?arraysize> }]
| <$?type> ]
}.
-
It is generally a repetition. It means the order of the elements is not determined. But all expect the
pathandnamestarts with a defined character:= ( - :which facilitates the parsing algorithm. -
The
=with the<?mInputInit>semantic means, the input for the variable is used only in the init phase to initialize the variable. It is either for handle references (which are wired on initialization as aggregation) or for constant values or for values which are initialized and set by a set_DataMng_Inspc FBlock in run time. -
The
structTypeis written in(…). ThestructTypehas non sense in this parameter dialog, but it is used for access, with the same parser. -
An identifier (syntax written as`<$?..>`) is either the name of the element, or possible a path if a dot
.follows after the identifier. For this FBlock apathhas no sense, but it is for the description of access. An identifier is as in Java or C/++, starting with a letter, containing also digits and_. Upper and lower case are distinguished. -
The
accessRightsare discussed in the chapter #Inspc.<#?…>means, after-a positive integer number is expected. -
The type is written after a colon
:. TheprimitiveCharis shown below. After aprimitiveCharoptional some (typical one)arraysizeas simple number with leading*also as separator can be given. -
Alternatively the
typecan be given as identifier also with leading:. Then the element is a reference as handle with this type. -
If the type is missing, for this FBlock it is determined by the input signal type. If the type is given, the model checks the agreeability with the connected signal. But consider, after a comma
,the type from the definition before is used.
The standard types (primitives) should written with one char:
simpleTypeChar::= [D <?double> |F <?float> |J <?int64> |I <?int32> |S <?int16> |B <?int8> |d <?double_complex>|f <?float_complex> |U <?uint32>|W <?uint16>|V <?uint8> |j <?int64_complex> |i <?int32_complex> |s <?int16_complex> |Z <?bool>|C <?char8> ]
For Simulink it is float for single. The shown types are the C-Codegeneration used types.
6.2. Parameter of FBlock DataStruct_Inspc
Image: Parameter of DataStruct_Inspc
It is similar the DataStructMng_Inspc, equal for the inputs field.
The unique short sub name should be an short identifier for any chain member. It is used only internally on code generation for identifier building for access.
The image shows a constant as value intmax('uint32'). This is 0xFFFFFFFF or an unsigned -1. This can be used for any handle with a null value, and also for the chain input in this example with no more chaining, instead deactivate the check box for chain.
6.3. Parameter of FBlock get_DataStruct_Inspc
Image: Parameter of get__DataStruct_Inspc
The Dialog for get_DataStruct_Inspc is similar the other Function Blocks shown in the image above.
-
Tstep: You should note a numeric variable or a number. It is the step (sample) time of the access. The data are that data from the last execution of the writing FBlock.
-
showName: It is only for the labeling in the model. Often it should be identically with Type: Name.
-
Type: Name Here the same syntax is valid as for one vairableas in inputs of a DataStruct_Inspc
variabledef::= { = <?mInputInit> | ( <$?structType> ) | [{<$?path>?\.}]<$?name> | -<#?accessRights> | : [ <simpleTypeChar> [{ * <#?arraysize> }] | <$?type> ] }. -
The
accessRightsare not used here. It is only formally possible in syntax. -
The
(TypeData)as( <$?structType> )is necessary for code generation (accelerator or simulink coder) if the input is not immediately connected to a DataStructMng_Insc FBlock. If it is connected immediately, the code generation detects the structType from that src FBlock’s parameter. If the structType is given as parameter, it is additionally checked. -
The
<simpleTypeChar…or<$?type>as type of the output is necessary here to determine the output properties for the model. The type can be evaluated, and it is checked on startup run time (in Tinit step time), but not on initialization of the model. If the type is missing, a back propagation may be possible. -
,,name,,: This element from the connected DataStructMng_FB is accessed with this FBlock. The access is checked on startup (Tinit step time). If the access is not possible, an Simulink runtime error message is shown. If the type is faulty, also an error message is shown.
-
,,path,,: A ,,path.to.name,, is especially possible if any data inside a module from a sub module should be accessed.
Examples for a element parameter:
-
name: Only the name is given. The type of the element comes from the wired connection in the model. It is back propagated here. -
name :F*2: The element and the output is a float with 2 elements. -
(Type) name :D2: The type of the input is theType. This type will be tested in Simulink in the ,,Tinit,, step time and used for Code generation as pointer type for access (casted from the handle). This is usefully especially for access to aSuperTypefor Polymorphism in DataStruct. -
(Type) name :OutputType: The output is a handle with the given type. -
aggr.name :I: Theaggris the name of an aggregated elements. Either it is an access to data in C-core SFblocks, or an access to references Data inDataStruct. The Output isint32here.
6.4. Parameter of FBlock getTinit_DataStruct_Inspc
Image: Parameter of getTinit_DataStruct_Inspc
The FBlock and the Dialog for getTinit_DataStruct_Inspc is similar the get_DataStruct_Inspc. The difference is: The output is offered in the startup phase respectively the ,,Tinit,, step time. Only if the output value is available (handle is not 0), the startup phase is finished. This is especially for aggregation wiring.
With this FBlock the following can be done:
-
If only a ,,(StructType),, is given, no name, no output type, this FBlock checks the input, and offers the same handle on output. This is helpfull if a ,,DataStructMng_Inspc,, from a remote module via some port connection is referenced, and the following access FBlocks should not all completed with this ,,(StructType),, in its parameter. It is also proper for the view to the model: Such a FBlock declares centralized the input type.
6.5. Parameter of FBlock set_DataStruct_Inspc
Image: Parameter of set_DataStruct_Inspc
The FBlock and the Dialog for set_DataStruct_Inspc is similar the get_DataStruct_Inspc. It is for writing data.
7. Connection and Access via Inspector Service
The Inspector Service cann access all data which are based on ObjectJc, and all data which’s reflection are known beside its struct definition. The DataStructMng_Inspc is based on ObjectJc. The reflection of 'DataStructMng_Inspc' are created dynamically depending of the parametrizing and connected signals.
You only need connect the most superior DataStructMng_Inspc to the Inspector Service. All submodules are successfully connected if you build a tree of DataStructMng_Inspc proper to the tree of module structure.
The image shows the connection:
image:../../img/InputValues_Inspc_ServiceInspc.png|Connection to Inspc Service]
A add_DataNode_Inspc FBlock is used. That FBlock contains an argument for the name of the DataStructMng_Inspc data struct for the access. For the inspector service concept see [[Topic:.Smlk_Inspc.FB_ObjOConn.inspc.].
In this constellation you can open the Inspector-Tool and view fields of the first level. You see:
More aggregations (modules) are existing if more as one are registered via 'add_DataNode_Inspc', for example parts or the whole simulation environment.
If you click into myDevice you see the modules and signals of the device of the first level according to the DataStructMng_Inspc FBlock and the deeper levels:
If you have the access password:
The passwords are hard coded in the standard implementation of the Inspector GUI and the emc access sources:
-
111 till 444 for the 4 access levels, 11 only access, not modify, till 44.
If you use the Inspector and a target system for a customer, you should implement the necessary special password protection.
You see more fields, especially 'super' via super.thiz1 you can access internas of the FBlock to view its implementation, as developer access:
This shows data, which are gathered from the simulink model on startup of the simulation: TstepMin minimum of step times of all inputs, here 0.0001 s, index of the ports etc.