GETPA – Block for remote array parameter acquirement

Block SymbolLicensing group: STANDARD

Function Description
The GETPA block is used for acquiring the array parameters of other blocks in the model remotely . The block operates in two modes, which are switched by the GETF parameter. For $\mathtt{\text{GETF}}=\mathtt{\text{off}}$ the output arrRef is set to the value of the remote parameter at the start and every time when the remote parameter changes. If the $\mathtt{\text{GETF}}$ parameter is set to on, then the block works in single-shot read mode. In that case the remote parameter is read only when rising edge (off$\to$on) occurs at the GET input.

The name of the remote parameter is determined by the string parameter sc (string connection), which has the form <block_path:parameter_name>. The path to the block whose parameter should be read can contain hierarchic levels separated by dots followed by the block name. The path can be either relative or absolute:

• Relative:
  • Starts with a ’.’ character, indicating the level where the GETPA block is placed. Examples of paths: ".CNDR:yp", ".Lights.ATMT:touts".
  • Starts with ’..’ characters, indicating a level above the GETPA block. Examples of paths: "..CNDR:yp", "..Lights.ATMT:touts".
• Relative to Task: Starts at the root level of the task where the GETPA block is located. The string has to be prefixed with ’%’ in this case. Examples of paths: "%CNDR:yp", "%Lights.ATMT:touts".
• Absolute: A complete sequence of hierarchic levels down to the block. For referring to blocks located in the driver task (see the IOTASK block for details on configuration) the ’&’ followed by the driver’s name is used at the beginning of the absolute path. Examples of absolute paths: "task1.inputs.ATMT:touts", "&EfaDrv.measurements.CNDR:yp".

The order and names of individual hierarchic levels are presented in a tree-like structure within the Diagnostics section of the REXYGEN Studio program.

Warning: If the remote parameter is in a task other than the GETPA block, block execution is delayed until the remote task is completed. It is necessary to avoid the so-called race conditions and guarantee the correct value reading. Therefore, it is recommended to include the GETPA block in a slower task (longer period/execution time) and read parameter in a faster task (shorter period/execution time). In the opposite situation (e.g. the GETPA block in a faster task), the SETPA block should be used in a slower task.

Note 1: If parameter GETF = off and source array is in same task as the GETPA block, data are not copy into intermediate array, but output is direct reference to original array. It save resources (cpu time and memory). The nmax, etype parameters are ignored in this case.

Note 2: If multiple GETPA blocks are used to read arrays in another task, it is not guaranteed that all arrays will be read in one period of the second task. It is only guaranteed that the GETPA block executed earlier will read the array from the same or earlier period of the second task than the GETPA block executed later. The execution order can be seen in the REXYGEN Studio program diagnostics.

Note 3: The remote parameter must be a primary array (for example CNA:acn, RTOV:xVec, MX_MAT:ay). The array reference (like CNA:vec, RTOV:yVec, SUBSYSTEM:Outport) is not supported.

Note 4: The INCONN block can also be used to read the value remotely.

This block propagates the signal quality. More information can be found in the 1.4 section.

2024 © REX Controls s.r.o., www.rexygen.com