Page 1
CAN@net NT 100/200/420
Generic Protocol 2.1 for Gateway Mode V6
SOFTWARE DESIGN GUIDE
4.02.0332.20000 1.7 en-US ENGLISH
Page 2
Important User Information
Disclaimer
The information in this document is for informational purposes only. Please inform HMS Networks of any
inaccuracies or omissions found in this document. HMS Networks disclaims any responsibility or liability for any
errors that may appear in this document.
HMS Networks reserves the right to modify its products in line with its policy of continuous product development.
The information in this document shall therefore not be construed as a commitment on the part of HMS Networks
and is subject to change without notice. HMS Networks makes no commitment to update or keep current the
information in this document.
The data, examples and illustrations found in this document are included for illustrative purposes and are only
intended to help improve understanding of the functionality and handling of the product. In view of the wide range
of possible applications of the product, and because of the many variables and requirements associated with any
particular implementation, HMS Networks cannot assume responsibility or liability for actual use based on the data,
examples or illustrations included in this document nor for any damages incurred during installation of the product.
Those responsible for the use of the product must acquire sufficient knowledge in order to ensure that the product
is used correctly in their specific application and that the application meets all performance and safety requirements
including any applicable laws, regulations, codes and standards. Further, HMS Networks will under no circumstances
assume liability or responsibility for any problems that may arise as a result from the use of undocumented features
or functional side effects found outside the documented scope of the product. The effects caused by any direct or
indirect use of such aspects of the product are undefined and may include e.g. compatibility issues and stability
issues.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 3
Table of Contents
Page
1 User Guide ........................................................................................................................... 3
1.1 Related Documents ................................... ... ... ......... ... .....................................................3
1.2 Document History .. ... ... ......................................................................................... ... ........3
1.3 Trademark Information ................... ... ... ...... ... ... ................................................................ 3
1.4 Conventions............................................ ............ ... ... ......... ............................................. 4
2 TCP Server Function ............................................................................................................ 5
3 ASCII Protocol ...................................................................................................................... 6
3.1 Basic Message Format ............................................................... ... ... ......... ... ..................... 6
3.2 Processing of Messages. ... ......... ................................................................................ ........ 7
3.2.1 TCP Stream Handling .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . 7
3.2.2 How to Handle Incoming Messages .... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . 7
3.3 Using ASCII Protocol for Remote Access . ... ........................................................................... 8
3.4 C-API for Customer Specific Expansions............................................................................... . 8
4 Message Types .................................................................................................................... 9
4.1 Message..................................................................................... ... ......... ... ..................... 9
4.2 Cyclic Message ..... ... ... ...... ... .......................................................................................... 10
4.2.1 CYC INIT .... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . 10
4.2.2 CYC UPDATE ............................ .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 11
4.2.3 CYC STOP . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . 11
4.3 CAN Commands.............. ......... ... ... ............ .................................................................... 12
4.3.1 Initializing the CAN Controller ..................... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 13
4.3.2 Configuring the Filter. . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 16
4.3.3 Starting the CAN Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 18
4.3.4 Stopping the CAN Controller . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 18
4.3.5 Requesting the Status . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 19
4.4 Device Commands................................................................................... ... ......... ... ... ..... 21
4.4.1 DEV OPMODE ............ ... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . 21
4.4.2 DEV IDENTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 21
4.4.3 DEV VERSION ............. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . 21
4.4.4 DEV PROTOCOL . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 21
4.4.5 DEV INTERFACES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . 22
4.5 Events.................................................... ............ ... ... ......... ... ........................................ 22
4.6 Responses ... ......... ... ......................................................................................... ... ... ...... 22
4.6.1 Positive Response. .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . 22
4.6.2 Negative Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 22
4.6.3 Device Response ..... .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 22
4.7 PING REQUEST . ... ......... ... ......................................................................................... ... .. 23
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 4
5 Example ............................................................................................................................. 24
6 List of Error Codes ............................................................................................................. 25
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 5
User Guide 3 (26)
1 User Guide
Please read the manual carefully. Make sure you fully understand the manual before using the
product.
To use all features and described commands the latest version of the CAN-Gateway Configurator as well
as the latest firmware of the CAN@net NT must be installed. For documentation of firmware versions
below V6 contact Ixxat support.
1.1 Related Documents
Document
Installation Guide VCI Driver
User Manual CAN@net NT 100/200/420
User Manual CAN-Gateway Configurator
User Manual CAN@net NT C-API
1.2 Document History
Author
HMS
HMS
HMS
HMS
Version
1.0 June 2016
1.1
1.2
1.3
1.4 January 2019
1.5
1.6
1.7
Date
October 2016 Adjusted filter examples in 4.2 CAN commands
July 2017 Added information about CAN@net NT 420
April 2018 Adjusted PING REQUEST and title
March 2019 Layout changes
March 2020 Enhanced description of cyclic transmission, added description of remote mode,
November 2020 Added link to programming example
Description
First release
Minor corrections in chapter 4, added command for cyclic message, updated error
codes
firmware version V6
1.3 Trademark Information
Ixxat®is a registered trademark of HMS Industrial Networks. All other trademarks mentioned in
this document are the property of their respective holders.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 6
User Guide 4 (26)
1.4 Conventions
Instructions and results are structured as follows:
► instruction 1
► instruction 2
→ result 1
→ result 2
Lists are structured as follows:
• item 1
• item 2
Bold typeface indicates interactive parts such as connectors and switches on the hardware, or
menus and buttons in a graphical user interface.
This font is used to indicate program code and other
kinds of data input/output such as configuration scripts.
This is a cross-reference within this document: Conventions, p. 4
This is an external link (URL): www.hms-networks.com
This is additional information which may facilitate installation and/or operation.
This instruction must be followed to avoid a risk of reduced functionality and/or damage
to the equipment, or to avoid a network security risk.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 7
TCP Server Function
2 TCP Server Function
In the Gateway mode the device is acting as a TCP server and transmits and receives data on the
TCP port that is defined with the CAN-Gateway Configurator. The default TCP port is 19228.
Connection:
• Server exclusively accepts a single connection.
• Additional connection requests are rejected.
• Server exchanges data and commands with the ASCII protocol.
The server receives Ethernet ASCII protocol messages, extracts the original CAN message and
transmits the CAN message to the selected CAN bus. Received CAN messages are packed into the
ASCII protocol and forwarded to the connected Ethernet TCP/IP client. The server also handles
commands.
The device automatically starts the protocol server after power-up. When a connection to the
server is closed or lost, the configuration is restarted if PING is activated, but the CAN connection
is neither stopped nor reset.
5 (26)
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 8
ASCII Protocol 6 (26)
3 ASCII Protocol
The ASCII protocol is used to pack data (CAN messages) and commands for the transfer over
Ethernet TCP/IP network.
The ASCII-Protocol in version 2.1 supports 6 different message types:
• Messages (both directions)
• CAN Commands (from client to server)
• Device Commands (from client to server)
• Events (from server to client)
• Responses (from server to client)
• Ping Request
Commands have to be confirmed. Before a new command can be transmitted an answer has to
be received.
The ASCII protocol can be used in two ways:
• by implementing the ASCII commands on the host side
• by using the C-API ixcan (reference documentation of the C-API functions is contained in the
API package)
3.1 Basic Message Format
Basic Rules of ASCII Protocol:
• Messages are coded with ASCII characters exclusively.
• Valid characters:
– letters from a to z (no national characters)
– no distinction between upper and lower case
– numbers from 0 to 9
• Messages start with a valid ASCII character and are terminated dependent on the settings in
the CAN-Gateway Configurator with
\r\n, \r, or \n (End-Of-Line).
• Directly after End-Of-Line the next message can follow.
• Messages containing invalid characters are discarded.
• Message contents (e.g. CAN identifier, CAN data) are noted in HEX notation. Other formats
are not supported. HEX specifier (0x...) is omitted.
• 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.
• No space characters before and after a CAN message
• 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 transmitted over the TCP connection
in readable order; beginning with the “message type” group of ASCII characters and ending
with the termination \n.
• Maximum string length (including termination) is 268.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 9
ASCII Protocol 7 (26)
3.2 Processing of Messages
3.2.1 TCP Stream Handling
The communication from and to the CAN@net NT is handled as TCP stream. When reading data
from the TCP socket the host might receive or read only parts of a CAN message or a command
response. Since only complete messages can be processed, the host must wait for the remaining
data and then process the complete CAN message or command response. Wether a message is
complete or not, the host identifies based on the end of line termination (dependent on the
operating system and the respective settings in the CAN-Gateway Configurator with \r\n, \r,
or \n).
An programming example that shows how to analyze the received message stream is included in
the CAN-Gateway Configurator download package in C:\Users\Public\Documents\HMS\Ixxat
CAN-Gateway Configurator\Examples\ASCII.
3.2.2 How to Handle Incoming Messages
The communication from and to the device is handled asynchronous.
Example
A CAN status command/response sequence can be interrupted by incoming CAN messages.
tx: CAN 1 STATUS
rx: M 1 CSD 123 02 22 33
rx: M 2 CSD 345 02 55 AA
rx: R CAN 1 ----- 100
This is especially the case when working with more than one CAN controller. The ASCII message
parser on the host side has to take care on that and handle receiving ASCII messages on an event
basis.
The host message parser has to distinguish the following types of messages:
• CAN message, like M 2 CSD 01 C4 97 00 00 00 00 00 00
• Positive response (R ok)
• Negative response (R ERR <error-number> <error-description>)
• Device response, like R CAN CAN
• Events like E 1 BUSOFF
• CAN status response, like R CAN 1 ----- 100
CAN Message
Receiving CAN messages follows the definition of transmitting messages in Message, p. 9.
Example
M 1 CSD 100 55 AA 55 AA
M 2 CED 18FE0201 01 02 03 04 05 06 07 08
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 10
ASCII Protocol 8 (26)
3.3 Using ASCII Protocol for Remote Access
Remote access is possible with ASCII version 2.1. Older versions do not support remote
access.
If Remote access is enabled via the CAN-Gateway Configurator, a device that is used in Bridge
mode can be accessed in ASCII Gateway mode simultaneously. To use remote access the CAN
controller must already be configured and started by the Bridge mode configuration in the CANGateway Configurator.
The CAN controller is controlled via the Bridge and all ASCII commands related to the control are
blocked, this means the CAN controller cannot be stopped or modified via ASCII commands.
Cyclic messages cannot be defined via ASCII commands in remote access. CAN messages can be
sent and received via the ASCII protocol. To receive CAN messages on the host side via ASCII
commands, the messages must be added in the Mapping table of the Bridge configuration in the
CAN-Gateway Configurator. The ASCII device commands, including the command STATUS can
also be used in Remote Access.
The operation mode (remote/shared or ASCII Gateway/exclusive) can be checked with command
DEV OPMODE.
3.4 C-API for Customer Specific Expansions
Instead of implementing the ASCII commands on the host side, it is also possible to use the Ixxat
CAN API for C. The CAN API for C uses the ASCII protocol interface to access the CAN@net NT.
The C-API ixcan converts the API calls into corresponding ASCII commands according to the ASCII
Gateway Mode of the CAN@net NT. With the application that uses the C-API ixcan the CAN@net
NT can be accessed exclusively or in shared access with a Bridge configuration.
For more information about the C-API ixcan see User Manual CAN@net NT C-API ixcan on
www.ixxat.com/support-bridges-gateways.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 11
Message Types
4 Message Types
4.1 Message
Used to exchange CAN messages between the device and the Ethernet TCP/IP host and to
exchange information in both directions, to and from the device.
When a device receives a message on the CAN bus:
• CAN message is packed into an ASCII protocol message of type Message and transmitted
over Ethernet TCP/IP.
When device receives an ASCII-Protocol message of type Message from Ethernet TCP/IP:
• Message is unpacked and translated into a CAN message.
• CAN message is transmitted to the CAN bus.
Make sure, that the CAN controller is in running state before a message is transmitted (see CAN
Commands, p. 12). Otherwise the message is discarded. If the device is in running state and no messages
can be transmitted (e. g. invalid bus connection) the device discards one message every 10 ms to prevent
a data jam.
M <port> <format> <identifier> [<data-byte>] | dlc=<dlc>]
9 (26)
Parameter
Parameter
port
format Message format according to CFT:
identifier Message identifier (in HEX)
data-byte Only in data messages.
dlc Only for remote frames (RTR) in Classic CAN mode, valid values 0–8
Description
CAN port number (NT 100: 1, NT 200: 1...2, NT 420: 1...4)
• C – Controller type (C – CAN, F — CAN FD)
• F – Frame Format (S – Standard, E – Extended)
• T – Frame Type (D – Data, R – RTR)
Remote frames (RTR) are only supported by Classic CAN.
Classic CAN: up to 8 (blank separated) data bytes (in HEX)
CAN FD: up to 64 (blank separated) data bytes (in HEX)
Example
Classic CAN data message:
M 1 CSD 100 55 AA 55 AA
CAN FD data message:
M 2 FED 18FE0201 01 02 03 04 05 06 07 08
Classic CAN remote frame:
M 1 CSR 101 dlc=05
Return Value
None
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 12
Message Types
4.2 Cyclic Message
Cyclic message commands are disabled for ASCII remote access. For a Local Bridge
configuration cyclic messages can be configured in the CAN-Gateway Configurator.
With the cyclic messages commands it is possible to send up to 16 CAN messages from the
CAN@net NT cyclically and precisely timed. Each message can be configured and the
transmission started and stopped individually. A configured CAN message is transmitted once in
the defined cycle time. Even if more or less of the configured CAN message are received.
By changing the cycle time the following settings are possible:
• To reduce the number of CAN messages that are transmitted to the receiver, the cycle time
can be increased.
• To increase the number of CAN messages that are transmitted to the receiver, the cycle
time can be reduced.
If no current CAN message is received, it is possible to transmit default messages or earlier
transmitted messages to the receiver.
To automatically stop the cyclic transmission a repetition counter can be defined. The repetition
counter is decremented after each transmission of a CAN messages and if the counter reaches
the value 0 the cyclic transmission is stopped.
10 (26)
The cyclic transmission is started with the reception of the first CYC UPDATE message.
Valid Order of Use
► Make sure, that all cyclic messages are stopped (see CYC STOP, p. 11).
► Define the cyclic message (see CYC INIT, p. 10).
► To start the transmission, update the cyclic message (see CYC UPDATE, p. 11).
4.2.1 CYC INIT
Initializes a cyclic message. The command can only be executed when the message is not yet
transmitted.
CYC INIT <msg_num> <port> <time> <count>
Parameter
Parameter
msg_num
port
time
count
Description
Message number, valid values: 0–15
CAN port number (NT 100: 1, NT 200: 1...2, NT 420: 1...4)
Message cycle time in units of 0.5 ms, valid values: 1–65535 (= 0.5 ms to 32767.5 ms)
Maximum number of transmit repetitions, if a further update message is missing after the
start of the transmission. Valid values: 0–65532. Value 0 sets endless transmission. After
an update message the count is restarted. If the counter expires, the cyclic message is
stopped.
Example
CYC INIT 0 1 200 10
CYC INIT 15 2 2000 0
Return Value
Return value
R ok
R ERR <error-number> <error-description>
CAN@net NT 100/200/420 Software Design Guide
Description
Function succeeded
See List of Error Codes, p. 25
4.02.0332.20000 1.7 en-US
Page 13
Message Types
Remark
To start the transmission, call CYC UPDATE.
4.2.2 CYC UPDATE
Starts the transmission of an initialized cyclic message and updates the cyclic message . The
command can only be executed if the message is initialized.
CYC UPDATE <msg_num> <can-message>
Parameter
Parameter
msg_num
can-message
Example
CYC UPDATE 0 M 0 CSD 101 21 22 23 24 25 26 27 28
CYC UPDATE 15 M 0 CSD 101 21 22 23 24 25 26 27 28
11 (26)
Description
Message number, valid values: 0–15. Message must be initialized.
Updated CAN message, for information about the message format see Message, p. 9.
Parameter port of the updated CAN message must be 0. The message is transmitted to the
CAN port that is configured in CYC INIT.
Return Value
None
Remark
The start of the transmission of cyclic messages is independent of the CAN connection. If a cyclic
transmission is started, but the CAN is not started, the cycles before the CAN start are lost. For
example if a cyclic message is defined to be sent 60 times with a cycle time of 1 second and
updated (transmission started), but the CAN connection starts 10 seconds after the cyclic
message, only 50 messages are sent. The 10 first transmissions are lost.
4.2.3 CYC STOP
Stops the cyclic transmission of the message.
CYC STOP <msg_num>
Parameter
Parameter
msg_num
Example
CYC STOP 0
CYC STOP 15
Description
Message number, valid values: 0–15.
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
CAN@net NT 100/200/420 Software Design Guide
Function succeeded
See List of Error Codes, p. 25
4.02.0332.20000 1.7 en-US
Page 14
Message Types
4.3 CAN Commands
Fig. 1 CAN states
The commands that are used to control the CAN controller on the device and to modify the
settings of filter table are described in the following chapters.
12 (26)
Valid Order of Use
► Stop the CAN controller (see Stopping the CAN Controller, p. 18).
► Initialize the CAN controller (see Initializing the CAN Controller, p. 13).
→ Filter settings are deleted and all messages are rejected.
► Configure the filter (see Configuring the Filter, p. 16).
► Start the CAN controller (see Starting the CAN Controller, p. 18).
► Stop the CAN controller (see Stopping the CAN Controller, p. 18).
In Remote mode the CAN controller is controlled via the Bridge and all CAN control
commands are blocked. Only CAN STATUS can be used.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 15
Message Types
4.3.1 Initializing the CAN Controller
Make sure, the CAN controller is not in running state before initialization.
With the initialization the CAN controller loses its filter settings and all messages are
rejected. Configure the filter after initialization.
CAN INIT
Initializes the CAN controller with the baud rate value.
The following baud rates are possible (in kBd):
• CAN: 5, 10, 20, 50, 100, 125, 250, 500, 800, 1 000
• CAN FD arbitration phase: 5, 10, 20, 50, 100, 125, 250, 500, 800, 1 000
• CAN FD data phase: 500, 1 000, 2 000, 4 000, 5 000, 6 667, 8 000, 10 000
CAN <port> INIT <mode> <baudA> <baudD> <iso>
13 (26)
Parameter
Parameter
port
mode Operational mode
baudA Classic CAN: Baud rate value in KBaud like 125
baudD Baud rate in KBaud for data phase (only with CAN FD)
iso
Description
CAN port number (NT 100: 1, NT 200: 1...2, NT 420: 1...4)
STD = Standard
LISTEN = Listen only
CAN FD: Baud rate value in KBaud for arbitration phase
ISO or nonISO (only with CAN FD)
Example
CAN 1 INIT STD 125
CAN 2 INIT LISTEN 250
CAN 3 INIT STD 500 2000
CAN 4 INIT STD 500 2000 nonISO
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
Function succeeded
See List of Error Codes, p. 25
Remark
When the controller is initialized, configure a filter with CAN FILTER ADD and start the controller.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 16
Message Types
14 (26)
CAN INIT CUSTOM
Initializes the CAN controller with user defined baud rates via register values for brp, sjw, tseg1
and tseg2. For CAN FD values tdo and iso must additionally be set, as well as all register values
for the data phase.
If customized register values are used, check in CAN-Gateway Configurator if the values result in a usable
baud rate.
Classic CAN:
CAN <port> INIT CUSTOM <mode> <brp>/<sjw>/<tseg1>/<tseg2>
CAN FD:
CAN <port> INIT CUSTOM <mode> <brp>/<sjw>/<tseg1>/<tseg2>�
<brp>/<sjw>/<tseg1>/<tseg2>/<tdo> <iso>
Parameter
Parameter
port
mode Operational Mode
brp Baud rate prescaler
sjw
tseg1 Time segment 1
tseg2 Time segment 2
tdo Transceiver delay offset (or secondary sample point, SSP) (only with CAN FD)
iso
Description
CAN port number (NT 100: 1, NT 200: 1...2, NT 420: 1...4)
STD = Standard
LISTEN = Listen only
Synchronization jump width
ISO or nonISO (only with CAN FD)
Example
Classic CAN:
CAN 1 INIT CUSTOM STD 16/1/12/2
CAN 2 INIT CUSTOM LISTEN 16/1/12/2
CAN FD:
CAN 3 INIT CUSTOM STD 16/1/12/2 4/1/12/2/8
CAN 4 INIT CUSTOM STD 16/1/12/2 4/1/12/2/8 nonISO
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
Function succeeded
See List of Error Codes, p. 25
Remark
When the controller is initialized, configure a filter with CAN FILTER ADD and start the controller.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 17
Message Types
15 (26)
CAN INIT AUTO
Automatic baud rate detection is only possible with Classic CAN. CAN FD does not
support automatic baud rate detection.
Starts the automatic baud rate detection. The CAN controller tries to auto detect a baud rate on
the bus, based on the following possible baud rates in kBd: 5, 10, 20, 50, 100, 125, 250, 500, 800,
1 000. If a baud rate is detected the controller is initialized.
CAN <port> INIT AUTO <mode> <timeout>
Parameter
Parameter
port
mode Operational Mode
timeout
Description
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
STD = Standard
LISTEN = Listen only
Maximum waiting time in msec for the receiving of a CAN data message or a CAN error
message, valid values: 1 to 1 million
Example
CAN 1 INIT AUTO STD 100
CAN 2 INIT AUTO LISTEN 100
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
Function succeeded
See List of Error Codes, p. 25
Remark
CAN INIT AUTO checks up to 12 baud rates. In case of low bus activity and a high timeout the
baud rate detection may take several seconds. Check the status of the baud rate detection with
CAN STATUS AUTO. When the baud rate is detected, configure a filter with CAN FILTER ADD and
start the controller.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 18
Message Types
4.3.2 Configuring the Filter
Make sure, that the CAN controller is in stopped state before configuring the filter.
CAN FILTER CLEAR
Deletes all filter entries for 11 and 29 bit identifiers.
CAN <port> FILTER CLEAR
Parameter
Parameter
port
Example
CAN 1 FILTER CLEAR
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
Description
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
16 (26)
Function succeeded
See List of Error Codes, p. 25
CAN FILTER ADD
If a message passes several filters, the message is received several times.
Adds one pair of identifier/mask values to the message filter list. The filter works as a positive
filter list. Received messages that match the registered identifier/mask values are passed through.
All other messages are discarded.
The mask value specifies the bit-position of the identifier, which must be checked (1 means “to
be checked”).
Binary representation of mask:
• binary positions with value 1 are relevant for the filter
• binary positions with value 0 are not relevant for the filter
Binary representation of identifier:
• Defines the values for the positions that are marked as relevant (1) in mask.
• Values in positions that are marked as not relevant (0) in mask are ignored.
CAN <port> FILTER ADD <type> <identifier> <mask>
Parameter
Parameter
port
type
CAN@net NT 100/200/420 Software Design Guide
Description
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
Message format type: STD or EXT
4.02.0332.20000 1.7 en-US
Page 19
Message Types
17 (26)
Parameter
identifier Value for the identifier to match (in HEX)
mask Value for the mask (in HEX)
Description
Example
CAN 1 FILTER ADD STD 100 700
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
Example for 11 bit Identifiers
hex bin
Identifier
Mask
Result 0x1XX (0x100–0x1FF)
0x100 0001:0000:0000
0x700 0111:0000:0000
Any identifier between 0x100 and 0x1FF passes the filter, as only the first 3 bits of the mask are
marked as relevant.
Example for 29 bit Identifiers
hex bin
Identifier
Mask
Result
0x10003344 0001:0000:0000:0000:0011:0011:0100:0100
0x1F00FFFF 0001:1111:0000:0000:1111:1111:1111:1111
0x1FXXFFFF 0001:0000:XXXX:XXXX:0011:0011:0100:0100
All identifiers with 0x10xx3344 (positions xx can be any number) pass the filter.
Function succeeded
See List of Error Codes, p. 25
0001:XXXX:XXXX
Further Examples
Identifier Mask Valid message identifiers which pass the filter
0x100 0x7FF 0x100
0x700 0x700 0x700–0x7FF
0x000 0x000 0x000–0x7FF
Remark
To allow all messages to pass the filter, add CAN <port> FILTER ADD STD 0 0 and CAN
<port> FILTER ADD EXT 0 0 to the message filter list.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 20
Message Types
4.3.3 Starting the CAN Controller
Sets the CAN controller in running state.
CAN <port> START
Parameter
Parameter
port
Description
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
Example
CAN 1 START
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
4.3.4 Stopping the CAN Controller
Sets the CAN controller in stopped state for (re-)configuration.
18 (26)
Function succeeded
See List of Error Codes, p. 25
With the command STOP the locally buffered transmit messages of the CAN controller are
discarded.
CAN <port> STOP
Parameter
Parameter
port
Description
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
Example
CAN 1 STOP
Return Value
Return value Description
R ok
R ERR <error-number> <error-description>
Function succeeded
See List of Error Codes, p. 25
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 21
Message Types
4.3.5 Requesting the Status
CAN status responses always include the CAN channel number.
CAN STATUS
Reads the CAN status value. Can only be used in stopped and in running state.
CAN <port> STATUS
Parameter
Parameter
port
Example
CAN 1 STATUS
Return Value
The command CAN Status returns CAN status information.
Description
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
19 (26)
R CAN <port> <BEOTI> <num>
port
BEOTI
num
Example return values Description
R CAN 1 ----- 100
R CAN 2 –E-T- 24
R ERR <error-number> <error-description>
CAN port number 1 (with NT 100), 1...2 (with NT 200), 1...4 (with NT 420)
Five character string:
B — bus off status
E — error warning level
O — data overrun detected
T — transmit pending
I — Init (stopped) state, otherwise running state
Number of free message buffers for transmission (maximum size depends on
operational mode and expert mode settings)
CAN port 1, 100 free message buffers for transmission
CAN port 2, error warning level, transmit pending, 24 free
message buffers for transmission
See List of Error Codes, p. 25
Remark
The FIFO size depends on the operational mode and the expert mode settings. If the buffer is
full, new messages are discarded. In the example R CAN 1 ----- 100 the buffer (organized as
FIFO) can store maximally 100 messages.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 22
Message Types
CAN STATUS AUTO
Reads the CAN baud rate detection status.
CAN <port> STATUS AUTO
Parameter
Parameter
port
Description
CAN port number 1 (with NT 100),1...2 (with NT 200), 1...4 (with NT 420)
Example
CAN 1 STATUS AUTO
R busy
CAN 1 STATUS AUTO
R 125
Return Value
Return value Description
R stopped
R busy
R <baud-rate>
R failed
R timeout
R ERR <error-number> <error-description>
Not yet started
Baud rate detection running
Detected baud rate in kBd
Not detected or unknown baud rate
No bus traffic
See List of Error Codes, p. 25
20 (26)
Remark
Make sure that a baud rate is detected before configuring a filter and starting the controller.
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 23
Message Types
4.4 Device Commands
The ASCII protocol supports the following DEV (device) commands:
• DEV OPMODE
• DEV IDENTIFY
• DEV VERSION
• DEV PROTOCOL
• DEV INTERFACES
4.4.1 DEV OPMODE
Returns the device operation mode that is configured via the CAN-Gateway Configurator. Only
available with ASCII protocol version 2.1.
DEV OPMODE
Return Value
Return value Description
R SHARED
R EXCLUSIVE
21 (26)
Local Bridge and ASCII interface are sharing the CAN
interface (remote access enabled in operational mode
Bridge)
Exclusive use of the CAN interface (operational mode ASCII
interface)
4.4.2 DEV IDENTIFY
Identifies the device.
DEV IDENTIFY
Return Value
Return value Description
R CAN@net NT 420
R ERR <error-number> <error-description>
4.4.3 DEV VERSION
Reads the firmware version number of the device.
DEV VERSION
Return Value
Return value Description
R V1.00.00
R ERR <error-number> <error-description>
4.4.4 DEV PROTOCOL
Reads the ASCII protocol version number of the device.
Identity of the device
See List of Error Codes, p. 25
Firmware version number of the device
See List of Error Codes, p. 25
DEV PROTOCOL
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 24
Message Types
Return Value
Return value Description
R V2.0
R ERR <error-number> <error-description>
4.4.5 DEV INTERFACES
Reads the types of all available fieldbus interfaces.
DEV INTERFACES
Return Value
Return value
R CAN CAN
R CAN
R CAN CAN CANFD CANFD
R ERR <error-number> <error-description>
4.5 Events
The following events are transmitted to the host if the CAN controller changes the status.
22 (26)
ASCII protocol version number of the device
See List of Error Codes, p. 25
Description
Type and number of CAN interfaces: 2 classic CAN ports
Type and number of CAN interfaces: 1 classic CAN port
Type and number of CAN interfaces: 2 classic CAN ports, 2
CAN FD ports
See List of Error Codes, p. 25
E <port> ERRORWARNING SET
E <port> ERRORWARNING RESET
E <port> BUSOFF
The error status of the CAN controller and the error counter are defined according to ISO 118981:2015.
4.6 Responses
4.6.1 Positive Response
A positive response is always R ok.
4.6.2 Negative Response
R ERR <error-number> <error-description>
For a list of error codes see List of Error Codes, p. 25.
Example
R ERR 1 invalid baudrate
4.6.3 Device Response
CAN controller reached Error Warning level.
CAN controller under-run Error Warning level.
CAN controller reached Bus Off state.
Device responses depend on the request command.
Examples
R V1.00.00
R CAN CAN
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 25
Message Types
4.7 PING REQUEST
Monitors the connection between host and CAN@net NT (heartbeat mechanism).
The CAN@net NT answers to a PING REQUEST with a PING RESPONSE. The first PING REQUEST
activates the connection monitoring. If no further PING REQUEST is received in the defined time
(set in parameter timeout in seconds, default value are 3 seconds), the CAN@net NT is
disconnected and the configuration is reset (CAN reset and TCP server restart).
If the PING REQUEST is used in ASCII remote mode, the remote connection also restarts
the configuration of the CAN-ETH-CAN Bridge or Local CAN Bridge if a timeout occurs. Do
not use the monitoring function PING REQUEST if the remote connection should not
restart the Bridge configuration.
PING REQUEST <timeout>
Parameter
Timeout in seconds (1...255), default value: 3 s
Example
PING REQUEST 10
23 (26)
Return Values
R PING RESPONSE
R ERR <error-number> <error-description>
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 26
Example 24 (26)
5 Example
The following example shows an initialization of both CAN channels. The direction is shown by tx.
(transmitted by user) and rx. (received by user).
tx: DEV VERSION
rx: R V0.10.04
tx: DEV INTERFACES
rx: R CAN CAN
tx: CAN 1 STOP
rx: R ok
tx: CAN 1 INIT STD 250
rx: R ok
tx: CAN 1 FILTER ADD STD 345 7F0
rx: R ok
tx: CAN 1 START
rx: R ok
tx: CAN 2 STOP
rx: R ok
tx: CAN 2 INIT STD 250
rx: R ok
tx: CAN 2 FILTER ADD STD 123 7F0
rx: R ok
tx: CAN 2 START
rx: R ok
tx: CAN 1 STATUS
rx: R CAN 1 ----- 100
tx: CAN 2 STATUS
rx: R CAN 2 ----- 100
tx: M 1 CSD 123 01 22
tx: M 2 CSD 345 01 55
rx: M 1 CSD 345 01 55
rx: M 2 CSD 123 01 22
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 27
List of Error Codes 25 (26)
6 List of Error Codes
Error number Error description
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 CAN <port_num> parameter is missing
17 DEV parameter is missing
18
19
20
21
22
23
24
25
- -
27 CYC parameter is missing
28
29
30
31
32
33
34
Unknown error ‘<error_code>’
Syntax error at ‘<erroneous string>’
CAN <port_num> baud rate not found
CAN <port_num> stop failed
CAN <port_num> start failed
CAN <port_num> extended filter is full
CAN <port_num> standard open filter set twice
CAN <port_num> standard filter is full
CAN <port_num> invalid identifier or mask for filter add
CAN <port_num> baud rate detection is busy
CAN <port_num> invalid parameter type
CAN <port_num> invalid CAN state
CAN <port_num> invalid parameter mode
CAN <port_num> invalid port number
CAN <port_num> init auto baud failed
CAN <port_num> filter parameter is missing
CAN <port_num> bus off parameter is missing
CAN <port_num> invalid parameter brp
CAN <port_num> invalid parameter sjw
CAN <port_num> invalid parameter tSeg1
CAN <port_num> invalid parameter tSeg2
CAN <port_num> init custom failed
CAN <port_num> init failed
CAN <port_num> reset failed
CAN <port_num> filter parameter is missing
CYC message <msg_num> stop failed
CYC message <msg_num> init failed
CYC message <msg_num> invalid parameter port
CYC message <msg_num> invalid parameter msg_num
CYC message <msg_num> invalid parameter time
CYC message <msg_num> invalid parameter data
Not supported in remote mode
CAN@net NT 100/200/420 Software Design Guide
4.02.0332.20000 1.7 en-US
Page 28
last page
© 2020 HMS Industrial Networks
Box 4126
300 04 Halmstad, Sweden
info@hms.se 4.02.0332.20000 1.7 en-US / 2020-11-26 / 20854
Loading...