Frequently Asked Question
Press "Ctrl + F" to find the keyword of your interest.
If you wish to have a direct link access to the video timestamps, please follow these instructions.
Found this video helpful? Why not take the whole HIL Specialist course? A Certificate is waiting for you for free at HIL Academy.
Would you or your organization benefit from having these videos narrated in your native language? Contact us and let us know if you wish to contribute.
TRANSCRIPT
Hello everyone! In this lesson, we will be looking at how to implement the CAN
bus protocol in the Typhoon HIL toolchain.You can see how this component fits into
the family of available components in the Typhoon HIL toolchain here.
For this lesson, we will focus exclusively on CAN Setup, Send, and Receive components, as other CAN
components feature similar configurations.CAN bus stands for Controller Area Network
protocol. It is a bidirectional serial bus communication method that allows electronic
subsystems to be linked together and interact within a network. At the physical layer,
it uses differential transmission on a twisted-pair wire, also known as a two-wire.
CAN is a multi-master protocol, which means that any node can initiate communication in
the network. Finally, to be able to communicate, each node in the network
must operate in the same bitrate and at least two nodes or more must be present in
the network so that it can work properly.CAN bus messages are small (at most eight
data bytes) and are protected by a checksum.There is no explicit address in the messages.
Instead, each message carries a numeric value ID which controls its priority on the bus and
may also serve as an identification of the contents of the message.
Two standards are defined for CAN bus message specification:
CAN 2.0A, which has an 11-bit identifier, and CAN 2.0B, which has a 29-bit identifier.
Only HIL devices with dedicated CAN controller hardware can implement CAN bus communication.
These are currently HIL404, 604, and 606 devices. Each of these has two CAN controllers embedded
that can be physically accessed through standard 9 pin D-sub connector in the back of HIL device.
Both CAN 2.0A and CAN 2.0B standards are supported here.
Also, it is important to mention that handling of Remote frames is currently not supported.
Now let s look at some of the components that comprise the CAN communication protocol in
the Typhoon HIL Control Center toolchain.The first component is CAN setup. It can be
found under the Communication section of the Library Explorer, inside the CAN bus
section. This block is used to configure the CAN controllers settings for the chosen HIL device.
Exactly one CAN setup component must exist in the model when using CAN protocol.
If you double click on the component, it opens the properties window shown here. From this
dialog window you can specify the baud rate and the execution rate for each CAN controller.
Once our setup is configured, we can focus on the messages we want to send with specific CAN
controllers. For this, we use the CAN send component. By opening the properties window,
we can choose which controller to use. We can also specify the data input to the component: either
the dialog window here or an imported DBC file.If we chose Dialog window as our data input,
we can also specify the message ID, the standard to follow, the message length
and how it is going to be transmitted (on event or on timer). Additionally, we can define our
messages manually by clicking the add symbol button at the bottom of the properties window.
Here we can define the name, length, byte order, data type, scale, offset,
and other options about the message specification. Once the messages are fully defined, we can click
the refresh button and it will show all messages defined in the signal information block.
The CAN receive component is similar to the CAN send component.
In order to receive a message and unpack it correctly, it is important to specify
it properly in the signal information section of the property s windows.
Instead of defining the messages manually, both CAN Send and CAN Receive components can import
DBC files to define the messages. The process of defining messages through DBC files is the
same for both components, so let s look at how to implement it using a Send component.
The DBC file type is primarily associated with CANdb by Vector Informatik GmbH.
The file name extension .DBC is used to store all information that describes the network.
To load a DBC file, we must choose CANdb file for the Data input property and navigate to the
desired file using the Import DBC file button. If the file is parsed correctly, the Choose
message combo box will be automatically populated with the message names from the file. Choosing
different messages will change the message and signal parameters in the dialog as shown here.
A loopback test is a useful way to check that a system and its
data transmission hardware is working. For a controller area network linked to a device,
a message loopback to the same test device is simple to achieve if it has two CAN adapters,
as is the case for HIL404, 602+, and 604. Here you can see how to wire two CAN adapters in the HIL
device in order to perform a loopback from CAN adapter 1 to CAN adapter 2 and vice-versa.
At its simplest, CAN bus wiring is very straightforward.
It is a case of joining the two CAN wires from each adapter together correctly. The CAN high
data line from one CAN adapter is connected to the CAN high data line of the next CAN adapter,
and likewise for the CAN low data line.The basic CAN wiring for a DB9 connector is
to join pins 7 together, transmitting CAN high, and pins 2 together, transmitting CAN low. For
bench testing low baud rate CAN buses, the network will usually work without a termination resistor
at 100k baud or less. However, for higher speed networks and long cables, a 120-ohm termination
resistor is required at each end of the CAN bus, wired between the CAN high and CAN low lines.
With this we conclude our introduction to CAN bus protocol in the Typhoon HIL toolchain.
In the next lesson, we will be looking at some practical applications through
the demonstration of a multi-protocol gateway.
