IXXAT CAN@net II/Generic User manual

CAN@net II/Generic
TCP/IP Gateway for CAN with Open Socket API
MANUAL
ENGLISH

HMS Technology Center Ravensburg GmbH
Helmut-Vetter-Straße 2
88213 Ravensburg
Germany
Tel.: [phone]
Fax: [phone]
Internet: www.hms-networks.de
E-Mail: [e-mail]
Support
For problems or support with this product or other HMS products please
request support at www.ixxat.com/support.
Further international support contacts can be found on our webpage
www.ixxat.com
Copyright
Duplication (copying, printing, microfilm or other forms) and the electronic
distribution of this document is only allowed with explicit permission of HMS
Technology Center Ravensburg GmbH. HMS Technology Center
Ravensburg GmbH reserves the right to change t
echnical data without
prior announcement. The general business conditions and the regulations
of the license agreement do apply. All rights are reserved.
Registered trademarks
All trademarks mentioned in this document and where applicable third
party registered are absolutely subject to the conditions of each valid label
right and the rights of particular registered proprietor. The absence of
identification of a trademark does not automatically mean that it is not
protected by trademark law.
Document number: 4.01.0086.20001
Version: 1.5

CAN@net II/Generic, Version 1.5
Content
3
1Introduction ....................................................................................5
1.1 Overview................................................................................. 5
1.2 Support ................................................................................... 5
1.3 Returning the Hardware......................................................... 5
2Functional Concept........................................................................6
2.1 Gateway Setup ....................................................................... 6
2.2 Bridge Setup........................................................................... 7
2.3 CAN ID Filtering...................................................................... 7
3Overview.........................................................................................8
3.1 Connectors of the CAN@net II/Generic................................ 8
3.2 Basic Device Configuration................................................... 8
3.3 Gateway Configuration.......................................................... 8
3.4 Bridge Configuration ............................................................. 9
4ASCII Protocol Server..................................................................10
4.1 ServerFunction..................................................................... 10
4.2 ASCII Protocol...................................................................... 10
4.2.1 Basic Message Format ..........................................................10
4.2.2 CAN Message........................................................................11
4.2.3 CAN Controller Command .....................................................12
4.2.4 Device Command...................................................................14
4.2.5 Error Message........................................................................16
4.2.6 Info Message..........................................................................17
4.3 CAN Message Filter.............................................................. 18
4.4 Message Sequencing........................................................... 18
4.4.1 Command Processing............................................................18
4.4.2Message Processing..............................................................19
4.5 Getting Started..................................................................... 20
5Web Interface................................................................................21
5.1 Main Page ............................................................................. 21
5.2 Device Configuration........................................................... 22
5.3 Filter Configuration.............................................................. 24
5.4 Expert Configuration............................................................ 27
6Writing Applications.....................................................................29
6.1 Windows Firewall Settings.................................................. 29

CAN@net II/Generic, Version 1.5
Content
4
6.2 TCP Streaming ..................................................................... 29
6.3 C Demo Application ............................................................. 30
A. Bridge Configuration Example....................................................32
B. FAQ List ........................................................................................34
Network Settings......................................................................... 34
Web Interface............................................................................... 34
Operation..................................................................................... 35
Bridge Setup................................................................................ 36
C. ASCII Protocol Short Reference..................................................37
Figures:
Figure 2-1 Gateway configuration .....................................................................6
Figure 2-2 Bridge configuration .........................................................................7
Figure 3-1 Connectors and displays of the CAN@net II/Generic......................8
Figure 4-1 CAN Controller Command Request/Response Cycle....................14
Figure 4-2 Device Command Request/Response Cycle.................................15
Figure A-1: Example for Bridge configuration..................................................32
Screenshots:
Screenshot 5.1 Main page...............................................................................22
Screenshot 5.2 Device configuration...............................................................23
Screenshot 5.3 Device configuration reply information...................................24
Screenshot 5.4 Filter configuration..................................................................25
Screenshot 5.5 Add CAN IDs reply information ..............................................26
Screenshot 5.6 Expert configuration ...............................................................27

CAN@net II/Generic, Version 1.5
Introduction
5
1 Introduction
1.1 Overview
The CAN@net II/Generic features simple, flexible access to a CAN system via
Ethernet. By supporting the TCP/IP protocol, the CAN@net II/Generic can be
accessed worldwide via Internet.
This manual is intended to help familiarize you with your CAN@net II/Generic
device. Please read this manual before beginning with installation.
1.2 Support
For more information on our products, FAQ lists and installation tips please refer
to the support area on our homepage (http://www.ixxat.com). There you will also
find information on current product versions and available updates.
If you have any further questions after studying the information on our
homepage and the manuals, please contact our support department. In the
support area on our homepage you will find the relevant forms for your support
request. In order to facilitate our support work and enable a fast response,
please provide precise information on the individual points and describe your
question or problem in detail.
If you would prefer to contact our support department by phone, please also
send a support request via our homepage first, so that our support department
has the relevant information available.
1.3 Returning the Hardware
If it is necessary to return hardware to us, please download the relevant RMA
form from our homepage and follow the instructions on this form. In the case of
repairs, please also describe the problem or fault in detail on the RMA form. This
will enable us to carry out the repair quickly.

CAN@net II/Generic, Version 1.5
Functional Concept
6
2 Functional Concept
The CAN@net II/Generic hardware provides connectivity to Ethernet and CAN
networks. The application firmware running on the CAN@net II/Generic
provides functions to access a CAN bus from virtually every Ethernet/TCP/IP
host.
The CAN@net II/Generic runs a server on TCP Port 19227, which is capable of
handling the ASCII Protocol specified in chapter 4. Any Ethernet/TCP/IP host
can connect to this server and exchange commands and CAN messages with it
using the ASCII Protocol. The server relays the commands and messages to
the CAN bus and vice versa.
The server is restricted to accept only a single connection to TCP port 19227.
Additional connection requests are rejected.
2.1 Gateway Setup
The picture below shows the standard configuration for a CAN@net II/Generic
functioning as a gateway to a CAN system.
In the gateway configuration, the CAN@net II/Generic usually is hooked to the
local intranet at the site where the CAN system is located. This allows any
TCP/IP host within the reach of this intranet to connect to the CAN@net
II/Generic and thus gain control of the CAN system.
Intranet
Internet
PC or
User platform
Socket
Ethernet
Ethernet
CAN@net II/
Generic
(Server)
CAN
Figure 2-1 Gateway configuration

CAN@net II/Generic, Version 1.5
Functional Concept
7
2.2 Bridge Setup
The picture below shows the standard "Bridge" setup for the CAN@net
II/Generic.
The bridge setup allows you to connect two CAN systems over an
Ethernet/TCP/IP network, e.g. the local intranet or even the internet. For the
bridge setup one of the CAN@net II/Generic takes over the role of the client
which connects to a CAN@net II/Generic in the role of a server.
Intranet
Internet
Ethernet
Ethernet
CAN
CAN@net II/
Generic
(Client)
CAN
CAN@net II/
Generic
(Server)
Figure 2-2 Bridge configuration
2.3 CAN ID Filtering
The CAN@net II/Generic application firmware includes a filtering mechanism
based on CAN Identifiers. The basis for the filtering is a filter list, which contains
the CAN Identifiers of interest. A CAN message with an Identifier contained in
the filter list is forwarded; all other CAN messages are discarded.
Filtering only applies to the direction CAN system TCP/IP network. In the
reverse direction, no filtering is available.
The CAN@net II/Generic provides functions to set or clear CAN Identifiers in
the filter list. It also allows you to write the filter list to the Flash memory so that
it can be loaded and used upon startup of the CAN@net II/Generic.

CAN@net II/Generic, Version 1.5
Overview
8
3 Overview
3.1 Connectors of the CAN@net II/Generic
The following diagram shows the connectors of the CAN@net II/Generic. The
pin assignment is described in detail in the manual “CAN@net II - Intelligent
PC/CAN Interface”.
The CAN@net II/Generic also has four LEDs. When connected to the power
supply, the Power LED is on. The CPU LED indicates the status of the Firmware.
For the Ethernet and CAN connectors two Duo-LEDs are available which
indicate the communication status. For more information on the LEDs, please
see chapter 3.2 “Indicators” of the manual:
“CAN@net II - Intelligent PC/CAN Interface”.
Figure 3-1 Connectors and displays of the CAN@net II/Generic
3.2 Basic Device Configuration
Before initial deployment of the CAN@net II/Generic, the device must be
configured. Please see chapter 4 Configuration” of the manual
“CAN@net II - Intelligent PC/CAN Interface”.
3.3 Gateway Configuration
In order to use a CAN@net II/Generic as server in a gateway mode (as
described in 2.1) it is sufficient to do a basic configuration.
Power
Etherne
t
CAN
LED

CAN@net II/Generic, Version 1.5
Overview
9
3.4 Bridge Configuration
For a bridge configuration, two CAN@net II/Generic devices are required. One
of them must be configured as server and the other one as client.
(1) The basic configuration, as described in chapter 3.2 "Basic device
configuration", must be done for both devices. For the CAN@net
II/Generic, which shall act as server, it is sufficient to do the basic
configuration.
(2) One of the two CAN@net II/Generic devices must be configured to act as
client. This can be done via the Web Interface; see the description in chapter
5.2 "Device configuration".
An example for the bridge configuration can be found in Appendix A.

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
10
4 ASCII Protocol Server
Every CAN@net II/Generic that is configured as server sends and receives data
on TCP Port 19227. This server handles the ASCII Protocol described in the
following sections.
4.1 ServerFunction
After power-up the CAN@net II/Generic automatically starts the protocol server
on TCP Port 19227.
The server accepts only a single connection. Additional connection requests are
rejected. After a connection is established, the server is ready to exchange data
and commands coded with the ASCII Protocol.
The ASCII Protocol is used to pack data (CAN messages) and commands for
the transfer over the Ethernet/TCP/IP network. E.g.: When the server receives
an ASCII Protocol message which contains a CAN message, it extracts the
original CAN message and sends it on the attached CAN bus. Messages seen
on the CAN bus are packed into the ASCII protocol and forwarded to the
connected Ethernet/TCP/IP client.
In addition to CAN messages, the server also handles commands. These can
be commands to start/stop the CAN controller, to set the CAN baudrate and so
on. It is also possible to retrieve the version numbers of the CAN@net II/Generic
firmware or of the ASCII-Protocol.
Whenever a connection to the server is closed or lost, the CAN@net II/Generic
is rebooted. The Device starts with the stored configuration.
4.2 ASCII Protocol
The following section describes the ASCII Protocol and how it is handled by the
ASCII Protocol server.
4.2.1 Basic Message Format
There are some basic rules the ASCII-Protocol does follow:
The messages are coded with ASCII characters
Valid characters are letters from a to z (no national characters) and numbers
from 0 to 9. There is no distinction between upper and lower case.
A message starts with a valid ASCII character and is terminated with \r\n. The
\r\n is separated by a space from the last significant character.
Directly after the \r\n the next message can follow.
Instead of using \r\n, any combination of \r and \n can be used (e.g. \r, \n, \n\n,
…).
Messages containing invalid characters are discarded.

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
11
Message contents like CAN Identifier or CAN data are noted in HEX notation
always. Other formats are not supported. The HEX specifier (0x…, ..HEX) are
omitted.
An ASCII-Protocol message consists of groups of ASCII characters, each
group separated by a space character (0x20).
More than one consecutive space characters (0x20) are reduced to a single
space character.
The groups of ASCII characters describe different types of messages or
commands contained in the ASCII-Protocol message.
The single characters of an ASCII-Protocol message are sent over the TCP
connection in readable order; beginning with the "message type" group of
ASCII characters and ending with the termination \r\n.
The ASCII-Protocol in its Version 1.0 supports 5 different message types which
are described in more detail in the following chapters. The message types are:
CAN message
CAN controller command
Device command
Error message
Info message
4.2.2 CAN Message
The ASCII-Protocol messages of type "CAN message" are used to exchange
CAN messages between the CAN@net II/Generic and the Ethernet/TCP/IP host
connected to server port 19227. The "CAN message" is used to exchange
information in both directions; to and from the CAN@net II/Generic.
When the CAN@net II/Generic receives a message on the CAN bus it packs
this CAN messages into an ASCII-Protocol message of type "CAN message"
and sends it over Ethernet/TCP/IP.
When the CAN@net II/Generic receives an ASCII-Protocol message of the
type "CAN message" from Ethernet/TCP/IP it unpacks this message,
translates it into a CAN message which it sends on the CAN bus immediately.
Message format:
M FTD ID XX XX XX XX XX XX XX XX \r\n
The groups of characters are separated by a space each. For a valid "CAN
message", the fields M, FTD, ID and \r\n must be specified. The groups shown
as XX correspond to the CAN data bytes and are optional; a "CAN message"
may contain 0 … 8 of these fields.

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
12
Detailed:
M Message type "CAN Message"
FTD CAN message details:
F - Frame Format (S – standard; E –
extended)
T – Frame Type (D – Data; R – RTR)
D –Data Length Code (0 through 8)
ID CAN Message ID
XX CAN Message Data; 0 through 8 Bytes long
\r\n Message terminator
Here are some examples of "CAN messages":
Extended Data, ID 0x100, Data [0x11 0x22 0x 33 0x44] :
M ED4 100 11 22 33 44 \r\n
Standard Data, DLC 7, ID 0x200, Data [0x1 0x2 0x3 0x4 0x5 0x6 0x7] :
M SD7 200 1 2 3 4 5 6 7 \r\n
Note: The messages are ASCII coded. Every single character of the example
message “M SD7 200 1 2 3 4 5 6 7 \r\n” will be one byte in the TCP paket:
“4D,20,53,44,37,20,32,30,30,20,31,20,32,20,33,20,34,20,35,20,36,20,37,20,0
A,0D”.
4.2.3 CAN Controller Command
Messages of the type "CAN Controller Command" are used to control the CAN
controller on the CAN@net II/Generic and to modify the settings of the filter
table.
Message format:
C
Command
Parameters
\r\n
The groups of characters are separated by a space each. For a valid "CAN
controller command", the fields C, Command and \r\n must be specified. The
field Parameters is optional and its usage depends on the exact Command.

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
13
Detailed:
C Message type "CAN Controller Command"
Command
Parameters Usage see the following table
\r\n Message terminator
Commands:
Command
Parameters
Description
INIT Baud rate
CAN controller standard initialization.
Possible baud rate values - 0, 10, 20, 50,
100, 125, 250, 500, 1000.
INIT CUSTOM BT0, BT1,
Name
CAN controller custom initialization with
register values BT0, BT1 in hex format and
baud rate name , for example for 800 kBd
(bt0 is 0x0, bt1 is 0x16) :
INIT CUSTOM 00 16 800_kBd
(BT0, BT1 are registers of the SJA1000
running at 16 MHz)
INIT AUTO -
The CAN controller tries to auto detect a
baud rate on the bus.
START
-
Start an initialized CAN controller
STOP - Stop a CAN controller
RESET
-
Reset a CAN controller
STATUS -
Device issues an info message which
contains the CAN controller status flags:
“I CAN status command received
I CAN status: [Init Mode] “
The Flags after “I CAN status:” are empty
or one or more of the following:
[Init Mode] CAN initialization mode
[Data Overrun] CAN data overrun
[Bus off] CAN bus off status
[Error Warning] CAN error warning level
FILTER ADD
CAN ID
Add CAN ID to the controller filter list
FILTER REMOVE CAN ID
Remove CAN ID from the controller filter
list
FILTER SEARCH
CAN ID
Search CAN ID within the filter list
FILTER CLEAR
-
Clear the filter list

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
14
FILTER ENABLE
-
Enable the filter list
FILTER DISABLE
-
Disable the filter list
FILTER LOAD
-
Load the filter list from flash
FILTER SAVE
-
Save the filter list to flash
FILTER SHOW -
Show content and status of the controller
filter list
Table 4.2.1 CAN controller commands
All messages of type "CAN controller command" are answered by the ASCII-
Protocol server with either an error message (see 4.2.5) or an OK packed in an
Info message (see 4.2.6).
Figure 4-1 CAN Controller Command Request/Response Cycle
It is good practice to issue CAN controller commands to the ASCII-Protocol
server only one at a time and then wait for the response. As some commands
may take longer to be processed than others, the timing of the response
messages may vary. So the sequence of responses to commands which were
issued in a row may be changed. And the ASCII-Protocol provides no
mechanism (like message identifiers) to match commands to their responses.
4.2.4 Device Command
Messages of the type "Device command" are used to exchange information
regarding the CAN@net II/Generic as a whole.
Message format:
D
Command
Parameters
\r\n
The groups of characters are separated by a space each. For a valid "Device
command", the fields D, Command and \r\n must be specified. The field
Parameters is optional and its usage depends on the exact Command.
Detailed:
D Message type "Device Command"
Command
Parameters Usage see the following table
\r\n Message terminator
CAN@net II/
Generic
(Server)
CAN Controller Command
Error or Info message

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
15
Commands:
Command
Parameters
Description
VER -
Device issues an info message which
contains the firmware version information
e.g.
“I CAN_at_net_II_ZZ_YY, FW V2.01.02,
HW V1.4, SerNo HWxxxxxx”
ZZ and YY are the last 2 bytes of the
device MAC address. HWxxxxxx is the
HW serial number.
PROTO -
Device issues an info message which
contains supported protocol version
information e.g.
“I ASCII Extended Protocol V1.1”
CONFIG
SAVE -
Stores the actual setting of the filter into
the flash. The filter settings are loaded
after a device reset or power on.
RESET
-
Device reset
Table 4.2.2 Device commands
All messages of type "Device command" are answered by the ASCII-Protocol
server with either an error message (see 4.2.5) or the requested information
packed in an Info message (see 0).
Figure 4-2 Device Command Request/Response Cycle
It is good practice to issue Device commands to the ASCII-Protocol server only
one at a time and then wait for the response. As some commands may take
longer to be processed than others, the timing of the response messages may
vary. So the sequence of responses to commands which were issued in a row
may be changed. And the ASCII-Protocol provides no mechanism (like message
identifiers) to match commands to their responses.
CAN@net II/
Generic
(Server)
Device Command
Error or Info message

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
16
4.2.5 Error Message
Messages of the type "Error message" are used to inform the ASCII-Protocol
client about problems or errors on the server side.
Message format:
E
Error number
Error description
\r\n
The groups of characters are separated by a space each. For a valid "Error
message", all fields must be specified.
Detailed:
E Message type "CAN Controller Command"
Error number Error code
Error description Readable error description
\r\n Message terminator
Error codes and their description:
Error
Code
Description
ERR_QUEUE_OVERRUN
0x10
Software queue overrun
ERR_DATA_OVERRUN
0x11
CAN controller buffer overrun
ERR_STATUS_SET
0x12
CAN error status set
ERR_STATUS_RESET
0x13
CAN error status reset
ERR_BUS_STATUS_SET
0x14
Bus off
ERR_MSG_FRAME_
FORMAT_UNKNOWN
0x20
Unknown message frame
format
ERR_MSG_RTR_FLAG_
UNKNOWN
0x21
Unknown message RTR flag
ERR_CONNECTION_
REJECTED
0x70
Device rejected incoming
connection because it is
already connected
ERR_ID_NOT_FOUND
0x75
ID not found in the filter list
ERR_ID_IN_LIST
0x76
ID is already in the filter list
ERR_LIST_FULL
0x77
ID was not added to the list,
filter list is full
ERR_CMD_UNKNOWN
0x80
Unknown command
Wrong parameter

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
17
ERR_CAN_BAUD_UNKNOWN
0x81
CAN init command received.
Baudrate is unknown
ERR_CAN_AUTOBAUD_
FAILED
0x82
CAN bus baud rate was not
detected
ERR_CAN_SET_BAUD_
FAILED
0x83
CAN controller failed to set
requested baud rate
ERR_INTERFACE_STATE_
WRONG
0x90
Interface is in the wrong state
to execute this command
Table 4.2.3 CAN@net II/Generic error codes
4.2.6 Info Message
Messages of the type "Info message" are used to feed the ASCII-Protocol client
with actual information. This message is sent only as a response to requests
like "CAN controller command" or "Device command". They will never be sent
in an asynchronous way without a previous request.
Message format:
I
Message text
\r\n
The groups of characters are separated by a space each. For a valid "Info
message", all fields must be specified.
Detailed:
I Message type "Info message"
Message text Readable message text
\r\n Message terminator
Example for an "Info message":
Response to a "CAN controller Command"; the command has been executed
successfully:
I OK \r\n

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
18
4.3 CAN Message Filter
As described in chapter 2.3 CAN ID filtering, the ASCII-Protocol server includes
a filtering mechanism for CAN messages. Filtering is done on the basis of CAN
Identifiers and is applied to the direction CAN bus Ethernet only.
The filter mechanism can be enabled or disabled via the Web Interface as
shown in 5.3 Filter configuration. With the filter list disabled, no filtering is applied
to the CAN messages; all messages are forwarded from the CAN bus to
Ethernet regardless of their ID. With the filter list enabled, only CAN messages
with Identifiers stated in the filter list are forwarded.
Upon startup of the CAN@net II/Generic, the filter list is loaded from Flash to
RAM. Now the filter list is ready for use and will be applied if filtering is enabled.
Modifications to the filter list can be made via the Web Interface and apply to the
filter list in RAM only. The modifications come into effect immediately after they
have been acknowledged by the Web Interface. If, for example, a new Identifier
has been added to the list, CAN messages with this new ID will now be
forwarded to the Ethernet.
Due to the fact that this filter list is kept in RAM, the modifications to it are volatile.
This means that with power down the modifications will be gone. Upon the next
startup, the old, unmodified filter list would be loaded from Flash.
If the modifications to the filter list should be kept, the user must write the filter
list from RAM to Flash. The Web Interface offers a "Save" button to do this.
When done, the filter list including the latest modifications is stored in Flash and
will be loaded automatically upon the next startup.
For all possible operations on the filter list see 5.3 Filter configuration.
4.4 Message Sequencing
In some cases it might be important to understand how and in which order the
ASCII-Protocol server processes commands and messages.
4.4.1 Command Processing
When the ASCII-Protocol server receives any command, it tries to execute it
immediately. When done, it responds with an acknowledgment or an error
message to the client. Due to the fact that command processing takes more or
less time for different commands, race conditions for the responses can occur.
It is recommended to wait for the response on a previous command before
sending a following command.
This behavior is also referred to in chapters 4.2.3 and 4.2.4.

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
19
4.4.2 Message Processing
The timing behavior for forwarding CAN messages from the CAN bus to the
Ethernet or vice versa depends on the workload the CAN@net II/Generic has to
handle. Also the network connection has influence on the transmission time for
CAN messages. Measurements show that these times can vary from 2 … 200
msec or possibly worse in extreme situations.
When the workload on the CAN@net II/Generic is so high that it cannot process
all messages, the excess messages are discarded and an error message will
be issued. This is valid for message forwarding in both directions.
Regardless of the timing issues or even the loss of messages, it is guaranteed
that the order of the messages is not changed. A message which was seen on
the CAN bus first will be transmitted to the Ethernet side first. This is valid for
both directions.

CAN@net II/Generic, Version 1.5
ASCII Protocol Server
20
4.5 Getting Started
This chapter describes the necessary steps to start the CAN data exchange
between the ASCII-Protocol server and the client.
After Power Up, the CAN@net II/Generic is busy booting. The ASCII-Protocol
server is started and ready to receive and process commands. This is indicated
by the CPU LED, which is blinking with a frequency of 1Hz.
The next step is to initialize the CAN controller hardware. Because the CAN
controller is not started yet, it is not possible to exchange CAN messages. Any
CAN messages received by the ASCII-Protocol server during this state are
discarded.
The necessary steps are as follows:
Issue a CAN init command to the ASCII-Protocol server. This command also
sets the desired CAN bus baud rate. The command "C INIT 500 \r\n" for
example will initialize the can controller hardware to 500 kBit/sec.
Wait for the ASCII-Protocol Server to respond, either with an error message
or with an OK.
Issue a CAN start command “C START” to the ASCII-Protocol server. This
command will put the CAN controller hardware into operating mode.
Wait for the ASCII-Protocol Server to respond; either with an error message
or with an OK.
Now the ASCII-Protocol server is fully configured and operational. If there was
any CAN data sent to the ASCII-Protocol server during this setup session, the
data has been discarded.
(After a “C START” command is acknowledged with OK), the ASCII-Protocol
server can receive data from the CAN bus and forward it to the ASCII-Protocol
client.
An example for these necessary steps can be seen in the coding example
described in section 6.2.