classVersion_0_9
Version 0.9 (Oct. 17, 2005)
Extends from Modelica.Icons.ReleaseNotes (Icon for release notes in documentation).
Information
First Beta-Version of the library.
The Modelica_LinearSystems2.Controller library (previously called Modelica_LinearSystems.Sampled) is based on the Sampled library from Nico Walther (master thesis from the electrical engineering at the HTWK-Leipzig, supervised by Prof. Müller, HTWK, and Prof. Martin Otter, DLR). Based on the experience in using the Sampled library, new features in Modelica as well as in Dymola, the Sampled library was considerably restructured, and newly implemented. The following main changes have been performed:
- The library is based on the input/output signal connectors of the Modelica standard library 2.1 (and higher). Previously, it was based on version 1.6. Similar as in 2.1, all blocks have been de-vectorized (more convenient for the user in the standard case. Modelica allows now easy vectorization of blocks).
- The previous parameter "method" was split into "blockType" (continuous/discrete) and "methodType" (discretization method). It is therefore easier to switch between a continuous and a discrete representation because one does not have to remember which discretization method was used previously when switching from a continuous to a discrete representation.
- The main options (blockType, methodType, sampleTime, initType) are set globally in component SampleClock via inner/outer and no longer in every component. The default defined in SampleClock can be changed in every component. Since in many cases just the defaults are used, it is now much more convenient to define the sampling setting and switch between different representations.
- In every component, the Integer parameter sampleFactor is present that defines the sampling time of this component as a "sampleFactor" multiple of the base sample time defined in sampleClock. This allows a more easier definition of standard multi-rate systems (in the previous version, in every component the actual sample time had to be defined). In the future, more advanced sampling options might be added, e.g., via user definable trigger signals.
- The previous Filter sublibrary was replaced by two components Filter and FilterFIR that model IIR and FIR filter. There are now more options for IIR filters (additional Bessel filter + normalized/non-normalized filters).
- The previous NoiseGenerators sublibrary was replaced by component Noise. In most applications only this Noise component is needed in sampled data systems and not the other variants in the previous NoiseGenerator library. It is then easier for a user to just select this component and not be forced to first figure out what component to use.
- The discrete representations of the blocks are changed such that no past values of the input signals u are accessed. For linear systems this is always possible via a state transformation. The benefit is that it is easier to initialize the block. Previously, it was necessary to define somehow the initial values of pre(u). This was not always made in a consistent way. Since in the new version no pre(u) is present, it need not be initialized.
- The sampling definition was changed. Previously, some when clauses have been
evaluated during initialization and via the sample() operator at the
initial time again (i.e., the when block was evaluated twice at
the start time). Some blocks have not been evaluated during initialization and
therefore in some cases the discrete variables have been not properly
initialized. In the new version, all when-clauses are active during
initialization and they are evaluated again at the next sample time:
when {initial(), sample(Ts,Ts)} then // active during initialization and at time = Ts, 2*Ts, 3*Ts, ... ... end when;Furthermore, parameter startTime was removed (= first sample time of when-clause after the initialization) since this is nearly never needed in a practical application and therefore this parameter could be removed (and no longer confuses users). - The continuous representations of all blocks are implemented such that as much structure as possible is preserved in order that index reduction is possible. For example, if a transfer function has more poles as zeros, then the output of the block might be differentiated n times (n = number of poles - number of zeros) without introducing derivatives in the inputs. A detailed explanation is given at the end of the info layer of component ZerosAndPoles. Previously, transfer functions and especially filters did not have this feature. Therefore, it was not possible to use the filters of the previous Sampled library as pre-filters in an inverse model. This is now possible. In such a case, a Bessel filter is most appropriate, because it does not introduce osciallations as the Butterworth and Chebyhev filter do and it is faster as the critical damping filter, see the description of the filter function. Previously, a Bessel filter was not supported.
- Previously, blocks have been implement with a large if-clause in which the different representations have been defined. In the new version, the discrete representations are defined in a separate block that are activated via a conditional declaration, if the block is discrete. (conditional declarations have been only recently introduced into the Modelica language version 2.2). The benefit is that the implementation is simpler and that there is no longer any overhead for the continuous block (all equations and variables from the discrete representation are removed during translation).
- Previously, for all simple blocks (such as FirstOrder) the different discrete representations have been specifically derived and implemented. In the new version, all blocks are first transformed to state space form with a function call and then the discrete state space system block is used for the discrete representation. This approach is less error prone and the implementation is much simpler.
- Special data structures for linear systems have been introduced in form of records and accompanying functions operating on these records. As a result, also the input parameters of some blocks, such as StateSpace or TransferFunction are now records instead of arrays. It is then possible to generate such system representations by appropriate function calls and supply the result as record instance to the corresponding block.