Block

Mask

Description

This function block holds a C function. It is used to manage multiple signals for the TestDrive application.

It also links the LabVIEW interface to the RT-Lab controller without the OpComm acquisition tool of RT-Lab. This results in many of the controls found on the LabVIEW graphical user interface (GUI) not being signals or parameters of the RT-Lab simulation model. This has an impact on the way to build the model which will differ considerably from other TestDrive module models.

Parameters

Blob Id

The blob id uniquely specified in the LabVIEW GUI enables the binding between the GUI and that block. If two acquisition cards are present on a carrier board, both cards' channels can have their own GUI for the user to easily analyze the acquisitioned data. For this to be possible, you will need to have two scope blocks with individual Blob Ids.

Another possibility is to link more than one card to one OpVirtualScope which connects to one GUI. The limit in this case is that all acquired data must be of the same type and have the same number of samples per step.

It is also possible to link more than one OpVirtualScope to a card. The limit in this case is the same as above: same data type with the same number of samples per step.

Note: A model with two 4-channel cards is slower than one with a single 8-channel card.

Maximum Buffer Size (Seconds)

This parameter defines the duration of all active traces that are constantly buffered. This is the maximum observable trace length. When in triggered mode this will also be the maximum duration that can be shown prior to the trigger occurrence.

The buffer size can be as big as the system’s RAM can allow (and CPU speed) and as small as the step size. It is strongly recommended NOT to set the size to the step size.

Maximum Scope Width

This parameter is used to set the maximum pixel-width of the scope.

Number of Traces

This parameter is used to give the C function the number of channels so that the code can demux the signals correctly.

The smaller the number of channels, the faster the communication will be since less acquired data is sent through the network. This gives the user the possibility to reduce data loss. It is to be noted that many other factors such as the data type, the number of samples per step, the scope width, the active channels, etc. influence the communication speed. So, limiting the number of traces might not change the communication speed dramatically.

Note: The maximum number of traces that one block can handle is 32, whatever the means of having 32 traces. For example, it could be 4 OP6228 modules with 8 traces each or 1 OP5130 with 32 traces.

Input Data Type

This option makes the C function cast the incoming channels' data to any Simulink type. It is most useful when the acquired data is encapsulated while being transferred from the acquisition card to the Simulink model (for example, two 16-bit integers into one 32-bit integer).

This method computes faster and uses less memory than the Simulink “conversion” block.

The default value in this field is auto which means it takes the Simulink type and does not cast data.

Inputs

Channels

This input is a concatenation of all the samples of all the traces into a single 1-D vector. The data is ordered as shown in the figure below, where s_ij represents the j^th sample of the i^th trace.

It must be noted that all traces must be of the same data type and have the same number of samples. In the example above, there are N samples for each of the M traces.

Enables

This input is a uint32. Each bit of this uint32 is assigned to a trace. This input tells the S-Function which traces are to be considered. If a trace is disabled, it will not be considered when displaying data on a fault trigger or when saving a .MAT file.

The first trace is the first bit on the right. The 32^nd trace is the first bit on the left. In other words, the first trace is the least significant bit (LSB) and the 32^nd trace is the most significant bit (MSB).

For example, if the Number of Traces is three and the second trace is to be disabled, the result will be 101 in binary or 5 in decimal numbers.

Arm

This signal refers to the state of the acquisition system. If the system is armed, this signal will be at 1 and 0 if the system is not armed.

When the system is armed, it processes data that can then be displayed, and it is looking for a fault trigger. If a fault trigger is found, the system disarms (the user can also manually disarm the system) and the S-function is disabled. Data is no longer processed. This means that no new data can be displayed, and no trigger can be detected unless the system is rearmed.

Triggers

This signal is a 1-D vector containing the level of the 2 triggers and the number of execution steps that separate the two.

The table that follows presents the possible breakdowns of the signals composing the Triggers input:

PreTrigger %

This input is the percentage of the display that precedes the trigger that should be displayed and/or saved. It gives the possibility to observe the waveform before the fault trigger happened to improve analyses.

If the preTrigger % is set to 20%, for example, 20% of the waveform displayed will be before the point where the fault trigger happened and 80% after the trigger.

Scaling

This is a 1-D vector containing 4 elements: [a b c d]. The scaling function (aX + b) / (cX + d) is applied to the data of all traces. The scaling information is also written in the saved files. Files opened in the scope automatically use the scaling information included in the file. It is to be noted that the data files opened in MATLAB cannot use the scaling.

External Disp Trigger

You can use your own trigger detection for the Display Trigger. This input is very similar to the first element of the Fault Trigger input: negative values are ignored; positive values are interpreted as the index of trigger in the input data vector.

Outputs

No outputs.