Library
rtlab/Miscellaneous
Block
The OpVirtualScope block allows a user to display, log and manage multiple signal in TestDrive application.
Figure 1: OpVirtualScope block
Mask
Figure 2: OpVirutalScope mask.
Description
The OpVirtualScope block is used to manage multiple signals for the TestDrive application.
It 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
| ID | The blob id uniquely specified in the LabVIEW GUI enables the binding between the GUI and that particular 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.
|
|---|---|
| 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 the 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 sij represents the jth sample of the ith trace.
Figure 2: OpVirutalScope mask.
Description
The OpVirtualScope block is used to manage multiple signals for the TestDrive application.
It 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
| ID | The blob id uniquely specified in the LabVIEW GUI enables the binding between the GUI and that particular 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 the 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 sij represents the jth sample of the ith trace. |
|---|