TRND – Real-time trend recording

Block SymbolLicensing group: STANDARD

Function Description
The TRND block is designed for storing of up to 4 input signals (u1 to u4) in cyclic buffers in the memory of the target device. The main advantage of the TRND block is the synchronization with the real-time executive, which allows trending of even very fast signals (i.e. with very high sampling frequency). In contrary to asynchronous data storing in the higher level operator machine (host), there are no lost or multiply stored samples.

The number of stored signals is determined by the parameter n. In case the trend buffer of length l samples gets full, the oldest samples are overwritten. Data can be stored once in pfac executions of the block (decimation) and the data can be further processed according to the ptype1 to ptype4 parameters. The other decimation factor afac can be used for storing data in archives.

The type of trend buffers can be specified in order to conserve memory of the target device. The memory requirements of the trend buffers are defined by the formula $s \cdot n \cdot l$ , where $s$ is the size of the corresponding variable in bytes. The default type Double consumes 8 bytes per sample, thus for storing $n = 4$ trends of this type and length $l = 1000$ , $8 \cdot 4 \cdot 1000 = 32000$ bytes are required. In case the input signals come from 16-bit A/D converter the Word type can be used and memory requirements drop to one quarter. Memory requirements and allowed ranges of individual types are summarized in table 1.1 in this reference guide.

It can happen that the processed input value exceeds the representable limits when using different type of buffer than Double. In such a case the highest (lowest) representable number of the corresponding type is stored in the buffer and an error is binary encoded to the iE output according to the following table (the unused bits are omitted):

Range underflow

Range overflow


Error

Input	u4	u3	u2	u1	u4	u3	u2	u1
Bit number	11	10	9	8	3	2	1	0
Bit weight	2048	1024	512	256	8	4	2	1

In case of simultaneous errors the resulting error code is given by the sum of the weights of individual errors. Note that underflow and overflow cannot happen simultaneously on a single input.

It is possible to read, display and export the stored data by the REXYGEN Diagnostics diagnostic program.

Inputs

u1..u4	Analog inputs to be processed and stored in the trend	Double (F64)
RUN	Enable execution. The data are processed and stored if and only if $RUN = on$ .	Bool
R1	Input for clearing the trend contents. The buffers are cleared when $R1 = on$ . This flag overpowers the RUN input.	Bool

Outputs

y1..y4	Analog outputs of the block set once in pfac executions of the block to the last values stored in the trend buffers	Double (F64)
iE	Error code, see the table above	Long (I32)

Parameters

n	Number of signals to process and store in the trend buffers $↓$ 1 $↑$ 4 $⊙$ 4	Long (I32)
l	Number of samples reserved in memory for each trend buffer $↓$ 0 $↑$ 268435000 $⊙$ 1000	Long (I32)
btype	Type of all n trend buffers $⊙$ 8	Long (I32)
	1 .... Bool 2 .... Byte 3 .... Short 4 .... Long 5 .... Word 6 .... DWord 7 .... Float 8 .... Double 10 ... Large
ptype $i$	The way the signal $u i, i = 1 \dots 4$ , is processed. The last pfac samples are processed as selected and the result is stored in the $i$ -th trend buffer. $⊙$ 1	Long (I32)
	1 .... No processing, just storing data 2 .... Minimum from the last pfac samples 3 .... Maximum from the last pfac samples 4 .... Sum of the last pfac samples 5 .... Simple average of the last pfac samples 6 .... Root mean square of the last pfac samples 7 .... Variance of the last pfac samples
pfac	Multiple of the block execution period defining the period for storing the data in the trend buffers. Data are stored with the period of $pfac \cdot T_{S}$ unless $RUN = off$ , where $T_{S}$ is the block execution period in seconds. $↓$ 1 $↑$ 1000000 $⊙$ 1	Long (I32)
afac	Every afac-th sample stored in the trend buffer is also stored in the archives specified by the arc parameter. There are no data stored in the archives for $afac = 0$ . Data are stored with the period of $afac \cdot pfac \cdot T_{S}$ , where $T_{S}$ is the block execution period in seconds. $↓$ 0 $↑$ 1000000	Long (I32)
arc	List of archives to store the trend data. The format of the list is e.g. 1,3..5,8. The data will be stored in all listed archives (see the ARC block for details on archives numbering). Third-party programs (Simulink, OPC clients etc.) work with an integer number, which is a binary mask, i.e. 157 (binary 10011101) in the mentioned case.	Word (U16)
id	Identification code of the trend block. This identifier must be unique in the whole target device with the REXYGEN system (i.e. in all archiving blocks). Disabled for $id = 0$ . $⊙$ 1	Word (U16)
Title	Title of the trend to be displayed in the diagnostic tools of the REXYGEN system, e.g. in the REXYGEN Diagnostics program $⊙$ Trend Title	String
timesrc	Source of timestamps. Each data sample in trend buffer is stored with a timestamp. For fast or short term trends where you are interested in sample-by-sample timing more than in absolute time, choose CORETIMER – REXYGEN internal technological time which is incremented by nominal period each base tick. For long running trends where you are interested mostly in absolute time shared with operating system (and possibly synchronized by NTP), choose RTC. Other values are intended for debug or special purposes. $⊙$ 1	Long (I32)
	1 .... CORETIMER – technological time – at current tick 2 .... CORETIMER-PRECISE – technological time – at block execution 3 .... RTC – real time clock (wallclock) from operating system – at current tick 4 .... RTC-PRECISE – real time clock (wallclock) from operating system – at block execution 4 .... PFC – raw high precision time (PerFormanceCounter)

[Previous] [Back to top] [Up] [Next]