WP_Query Object
(
[query] => Array
(
[paged] => 12
[pagename] => about-us/news
)
[query_vars] => Array
(
[paged] => 12
[pagename] => about-us/news
[error] =>
[m] =>
[p] => 0
[post_parent] =>
[subpost] =>
[subpost_id] =>
[attachment] =>
[attachment_id] => 0
[name] =>
[page_id] => 0
[second] =>
[minute] =>
[hour] =>
[day] => 0
[monthnum] => 0
[year] => 0
[w] => 0
[category_name] =>
[tag] =>
[cat] =>
[tag_id] =>
[author] =>
[author_name] =>
[feed] =>
[tb] =>
[meta_key] =>
[meta_value] =>
[preview] =>
[s] =>
[sentence] =>
[title] =>
[fields] =>
[menu_order] =>
[embed] =>
[category__in] => Array
(
)
[category__not_in] => Array
(
[0] => 1047
)
[category__and] => Array
(
)
[post__in] => Array
(
)
[post__not_in] => Array
(
)
[post_name__in] => Array
(
)
[tag__in] => Array
(
)
[tag__not_in] => Array
(
)
[tag__and] => Array
(
)
[tag_slug__in] => Array
(
)
[tag_slug__and] => Array
(
)
[post_parent__in] => Array
(
)
[post_parent__not_in] => Array
(
)
[author__in] => Array
(
)
[author__not_in] => Array
(
)
[orderby] => date
[post_type] => Array
(
[0] => post
[1] => developer_blog
)
[post_status] => publish
[order] => DESC
[tax_query] => Array
(
[0] => Array
(
[taxonomy] => blog-group
[field] => slug
[terms] => Array
(
[0] => public
)
[operator] => IN
)
[1] => Array
(
[taxonomy] => blog-group
[field] => slug
[terms] => Array
(
[0] => general-user
[1] => technical-asociate
[2] => qualified-sales-representative
[3] => kvaser-internal
)
[operator] => NOT IN
)
)
[ignore_sticky_posts] =>
[suppress_filters] =>
[cache_results] => 1
[update_post_term_cache] => 1
[lazy_load_term_meta] => 1
[update_post_meta_cache] => 1
[posts_per_page] => 10
[nopaging] =>
[comments_per_page] => 50
[no_found_rows] =>
[taxonomy] => blog-group
[term] => public
)
[tax_query] => WP_Tax_Query Object
(
[queries] => Array
(
[0] => Array
(
[taxonomy] => blog-group
[terms] => Array
(
[0] => public
)
[field] => slug
[operator] => IN
[include_children] => 1
)
[1] => Array
(
[taxonomy] => blog-group
[terms] => Array
(
[0] => general-user
[1] => technical-asociate
[2] => qualified-sales-representative
[3] => kvaser-internal
)
[field] => slug
[operator] => NOT IN
[include_children] => 1
)
[2] => Array
(
[taxonomy] => category
[terms] => Array
(
[0] => 1047
)
[field] => term_id
[operator] => NOT IN
[include_children] =>
)
)
[relation] => AND
[table_aliases:protected] => Array
(
[0] => wp_term_relationships
)
[queried_terms] => Array
(
[blog-group] => Array
(
[terms] => Array
(
[0] => public
)
[field] => slug
)
)
[primary_table] => wp_posts
[primary_id_column] => ID
)
[meta_query] => WP_Meta_Query Object
(
[queries] => Array
(
)
[relation] =>
[meta_table] =>
[meta_id_column] =>
[primary_table] =>
[primary_id_column] =>
[table_aliases:protected] => Array
(
)
[clauses:protected] => Array
(
)
[has_or_relation:protected] =>
)
[date_query] =>
[queried_object] => WP_Post Object
(
[ID] => 1277
[post_author] => 38
[post_date] => 2014-11-21 12:03:40
[post_date_gmt] => 2013-12-19 15:28:51
[post_content] =>
[post_title] => News
[post_excerpt] =>
[post_status] => publish
[comment_status] => open
[ping_status] => open
[post_password] =>
[post_name] => news
[to_ping] =>
[pinged] =>
[post_modified] => 2021-08-12 09:14:30
[post_modified_gmt] => 2021-08-12 09:14:30
[post_content_filtered] =>
[post_parent] => 23
[guid] => https://www.kvaser.com/?page_id=1277
[menu_order] => 5
[post_type] => page
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[queried_object_id] => 1277
[request] => SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND (
wp_term_relationships.term_taxonomy_id IN (1026)
AND
wp_posts.ID NOT IN (
SELECT object_id
FROM wp_term_relationships
WHERE term_taxonomy_id IN (1025,1027,1028,1029)
)
AND
wp_posts.ID NOT IN (
SELECT object_id
FROM wp_term_relationships
WHERE term_taxonomy_id IN (1058)
)
) AND wp_posts.post_type IN ('post', 'developer_blog') AND ((wp_posts.post_status = 'publish')) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 110, 10
[posts] => Array
(
[0] => WP_Post Object
(
[ID] => 32281
[post_author] => 35351
[post_date] => 2021-05-19 16:47:53
[post_date_gmt] => 2021-05-19 16:47:53
[post_content] => [vc_row][vc_column][vc_column_text]This Developer Blog is the second of a 3-part series taking a look at SAE J2534. This series introduces SAE J2534 (including it's multiple editions), describes how to use the 2004 API, and then provides instruction on getting started with Kvaser and J2534.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_message]This blog is part of 3-part series on J2534:
SAE J2534 (Part I): An Introduction
SAE J2534 (Part II): Using the 2004 API
SAE J2534 (Part III): Getting Started with Kvaser and SAE J2534[/vc_message][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="2 Using the 2004 API"][vc_column_text]To use the J2534 API productively, you need both an understanding of the protocol you want to use and the API’s sequence of operations for that protocol — this is despite J2534’s efforts to be protocol-agnostic. Let’s start with a brief overview of the CAN-based protocols supported (as of J2534-2 2019), and then quickly go over how you would use each one through the J2534 API.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="2.1 Protocol Basics"][vc_column_text]We’ll be going through the four protocols currently supported by Kvaser’s J2534 DLL: CAN 2.0, CAN FD, ISO-TP, and ISO-TP FD. In J2534 they have separate protocol “ID”s and we will treat them as separate protocols, but of course the truth is slightly more nuanced. The two FD-protocols are really updated versions of the non-FD versions that support the CAN Flexible Data Rate Format, still providing all the functionality of their non-FD versions. It is also worth mentioning that ISO-TP (with or without FD) is a higher-level protocol that exists on top of CAN (correspondingly 2.0 or FD).[/vc_column_text][vc_single_image image="32282"][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.1.1 CAN 2.0"][vc_column_text]The basis of all following protocols, CAN 2.0 (sometimes called Classic CAN) is a fault-tolerant protocol for broadcasting messages, called Frames, for all nodes on the bus to see. Frames consist of CAN Data (up to 8 bytes in length) and a CAN ID that can be either 11 (standard) or 29 (extended) bits long, and is used to prioritize which frames are let onto the bus first — known as “arbitration”. These frames are then sent on the bus at a predefined bitrate.[/vc_column_text][vc_header_raket header_type="h4" header="2.1.2 CAN FD"][vc_column_text]In 2015 the standards document for CAN, ISO11898, was updated to include CAN FD; CAN with a Flexible Data rate. This means that you can now, optionally, use one bitrate for the arbitration of CAN IDs and another (higher one) for sending the actual data. And to make use of the higher transmit speeds we can also send much larger frames, with CAN Data lengths of 12, 16, 20, 24, 32, 48, and 64 bytes – in addition to the up to eight bytes already allowed by CAN 2.0.[/vc_column_text][vc_column_text]On the bus, the decision to use bitrate switching, BRS, is encoded per frame in one of the transmitted bits. The overall decision of whether to use CAN 2.0 or CAN FD is also encoded in one of the transmitted bits (though you can’t use BRS if you don’t also use FD), meaning devices that support CAN FD can read and write messages in three different formats:[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/6"][/vc_column][vc_column width="2/3"][vc_single_image image="32283"][/vc_column][vc_column width="1/6"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]Though note that we can still choose whether we want 11 bit or 29 bit IDs regardless of format. The two bitrates used with BRS are usually called “Arbitration Bitrate” and “Data Bitrate” (maybe throwing a “-Phase” into the middle as well).[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.1.3 ISO-TP"][vc_column_text]ISO 15765 is a family of standards by the International Standards Organization. We’re interested in the second part, ISO 15765-2, which defines a “Transport protocol and network layer services” — specifically we need to know about the transport protocol, ISO-TP.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/2"][vc_column_text]Note that this protocol is given various different names by different people, as it is never named in the standard itself. J2534 calls it ISO 15765 (despite there being four other standards in the ISO 15765 family), others call it ISO 15765-2 (despite that standard standardizing a lot more than just the transport protocol), but I will continue to call it ISO-TP (ISO Transport Protocol) as that is the most unambiguous term I have found, referring to the transport protocol and the transport protocol only.[/vc_column_text][vc_column_text]Now take a deep breath, we haven’t actually started on how ISO-TP works. ISO-TP is a higher-level protocol built on top of CAN 2.0, whose main purpose is to allow messages to be “segmented”, split over multiple CAN frames — which means you can send much longer messages. To do so in an orderly fashion, it uses a back-and-forth between the sender and the receiver to control how quickly frames should be sent and make sure they arrive.
This back-and-forth means that, if you want your message to be segmented, it has to be sent to a sole receiver. This is the final part of ISO-TP; messages can either be sent one-to-one or one-to-many. In ISO-TP parlance, one-to-one communication is called “physical addressing” and one-to-many is called “functional addressing”. Although if you are not used to addressing in vehicles those names are more confusing than helpful.[/vc_column_text][/vc_column][vc_column width="1/2"][vc_single_image image="32284"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Segmentation
So you want to send an ISO-TP message? Well, if it fits in a single CAN frame then all is well and it is transmitted directly as a Single Frame (SF). For one-to-many communication, this is the only allowed method — one-to-many ISO-TP messages must fit into a SF.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="2/3"][vc_column_text]But for one-to-one communication it’s okay to send longer messages. In that case, the transmitter sends a single CAN frame with as much payload as can fit, a First Frame (FF), and then a (single) receiver must be set up to reply with a Flow Control (FC) frame. This can pause, cancel, or continue the transmission, and in the case of continuing it contains two parameters that will be in use until the next FC: called STmin (Separation Time MINimum) and BS (Block Size).
The transmitter will then send one “block” of CAN frames containing payload, called Consecutive Frames (CFs), and the number of such frames sent is controlled by Block Size. The Separation Time Minimum is the amount of time that must pass between CAN frames being sent on the bus. After a block is transmitted, the transmitter waits for another FC and then repeats. When the entire payload has been transmitted, the conversation quietly stops.[/vc_column_text][/vc_column][vc_column width="1/3"][vc_single_image image="32286"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Addressing
Each node in the network has an address, and for each message this is compiled into “Address Information” in one of several different ways, some standardized and some not, each with several different variations and done differently depending on its functional or physical addressing.
Fortunately for me, the J2534 API leaves this all up to the user. As far as the API is concerned, each ISO-TP message has an address. This can either be an “extended” address, in which case it is one byte longer than the CAN ID, or just a normal one in which case it is exactly equivalent to the CAN ID.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text] It is then up to the user to define:
- Which addresses to accept SFs from.
- Which addresses to listen to segmented transmissions on, and which addresses to reply to each with.
- Which addresses can be transmitted on, and which addresses to expect replies from for each.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.1.4 ISO-TP FD"][vc_column_text]The 2016 version of ISO 15765-2 added support for using CAN FD frames underneath ISO-TP. Fortunately for us, this doesn’t change much. You must now specify if you want the frames to be CAN 2.0, CAN FD, or CAN FD with BRS as well as specifying how large you want the individual CAN FD frames to be (you might not want every frame to be 64 byte long).
The other difference is that ISO-TP messages can have a payload of at most 4095 bytes, while ISO-TP FD added new mechanisms that allow for four gigabytes (4294967296 bytes).
…of which the J2534 API can only utilize 28 or 29 extra bytes, for a total of 4124 or 4123 depending on whether we’re using extended addressing. This is because messages are put in a struct with a static size. :/. (Because of this, the Kvaser API doesn’t currently implement that extra machinery.)[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="2.2 Sequence of Operation"][vc_column_text]So now that you’re up to date with your favorite protocol, how do you go about setting up the DLL for communication? Well the basic call sequence is:[/vc_column_text][vc_column_text]
- PassThruOpen(): Open a device (Kvaser DLL only has one device).
- PassThruConnect(): Connect a channel on the device, using a particular protocol ID.
- Use the channel however you want
- PassThruDisconnect(): Disconnect the channel
- PassThruClose(): Close the device.
[/vc_column_text][vc_column_text]The first step is to open a device and the second step is to use that device to connect to a channel. The base J2534-1 2004 only has a single device, but you must still open it in order to connect to a channel. If the DLL implements access to additional channels per J2534-2, you can connect to several channels using the same device, as long as they don’t use the same physical connection.[/vc_column_text][vc_column_text]As disconnecting the channel and closing the device is not very interesting, those steps will be omitted from now on.
Note that all API calls return a status and if everything is fine that status will be STATUS_NOERROR = 0. Otherwise, call PassThruGetLastError() to get a more detailed description of what went wrong e.g. whether the CAN ID you supplied was too small or large, or if it was the CAN data that was wrong instead of just ERR_INVALID_MSG.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.1 CAN 2.0"][vc_column_text]Protocol IDs: CAN, CAN_CH1, CAN_CH2…
CAN uses the channel number supplied in registry, CAN_CH1 is CANlib channel 0, CAN_CH2 is CANlib channel 1, etc.[/vc_column_text][vc_column_text]
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the bitrate. In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both.
- Messages can be sent without any setup.
- PassThruStartFilter(), defining which CAN IDs should be listened to and be reported to the user. Before setting a filter, no traffic from the bus can be seen.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.2 CAN FD"][vc_column_text]Protocol IDs: FD_CAN_CH1, FD_CAN_CH2…
CAN FD cannot use the channel number from registry, the CHx IDs work like with CAN 2.0: FD_CAN_CH1 is CANlib channel 0, FD_CAN_CH2 is CANlib channel 1, etc.
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the arbitration bitrate (only). In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both. Channel is not connected yet.
- PassThruIoctl(), SET_CONFIG: FD_CAN_DATA_PHASE_RATE to desired data bitrate. Channel is now connected to the CAN bus.
- Messages can be sent without any setup.
- PassThruStartFilter(), defining which CAN IDs should be listened to and be reported to the user. Before setting a filter, no traffic from the bus can be seen.
[/vc_column_text][vc_column_text]Even if you never use bitrate switching, you must specify the data bitrate before the channel will connect to the CAN bus and let you send and receive messages.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.3 ISO-TP"][vc_column_text]Protocol IDs: ISO15765, ISO15765_CH1, ISO15765_CH2…
Similarly to CAN 2.0, ISO15765 uses the channel number supplied in registry, ISO15765_CH1 is CANlib channel 0, ISO15765_CH2 is CANlib channel 1, etc.
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the bitrate. In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both.
- Non-segmented messages can be sent without any setup.
- PassThruStartFilter(), defining pairs of message addresses. The channel will respond to messages that have the reception address using the transmission address for the FCs. Segmented messages can also be sent on the transmission address, in which case the channel will expect FCs with the reception address. For receiving one-to-many (physically addressed) messages, supply the same address twice (as one-to-many messages never need FCs).
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.4 ISO-TP FD"][vc_column_text]Protocol IDs: FD_ISO15765_CH1, FD_ISO15765_CH2…
Similarly to CAN FD the channel number from registry cannot be used while FD_ISO15765_CH1 is CANlib channel 0, FD_ISO15765_CH2 is CANlib channel 1, etc.
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the bitrate. In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both. Channel is not connected yet.
- PassThruIoctl(), SET_CONFIG: FD_CAN_DATA_PHASE_RATE to desired data bitrate. Channel is now connected to the CAN bus.
- Non-segmented messages can be sent without any setup.
- PassThruStartFilter(), defining pairs of message addresses. The channel will respond to messages that have the reception address using the transmission address for the FCs. Segmented messages can also be sent on the transmission address, in which case the channel will expect FCs with the reception address. For receiving one-to-many (physically addressed) messages, supply the same address twice (as one-to-many messages never need FCs).
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator_raket][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Definitions
- ISO-TP
The Transport Protocol defined in 15765-2:2011, without the support for CAN FD which was introduced in 15765-2:2016. Sometimes ambiguously called simply ISO 15765-2 or ISO 15765.\
- ISO-TP FD
The Transport Protocol defined in 15765-2:2016 (including the support for CAN FD).
CAN
The Controller Area Network as described in ISO 11898, a blanket term for both CAN 2.0 and CAN FD.
- CAN 2.0
The “classic” CAN with up to eight bytes of data and no support for bit rate switching.
- CAN FD
CAN Flexible Data rate protocol that supports longer data than CAN 2.0 as well as bit rate switching.
- J2534
A family of standards that specify the Pass-Thru device and the Pass-Thru API used to communicate to the device via a J2534 DLL.
- J2534 DLL
The DLL provided by an interface manufacturer, which conforms to the Pass-Thru API.
- Pass-Thru API
The API of all J2534 DLLs, which the vehicle manufacturer can use regardless of which company’s J2534 DLL is actually in use.
- Pass-Thru device
A specific type of device standardized by J2534, which has an accompanying J2534 DLL.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="More Resources"][vc_column_text]
Kvaser's Overview of SAE J2534[/vc_column_text][/vc_column][/vc_row]
[post_title] => SAE J2534 (Part II): Using the 2004 API
[post_excerpt] => A deeper look at how CAN 2.0 and CAN FD are handled in the SAE J2534:2004 specification. We also take a look at the Transport Protocol (ISO-TP).
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => sae-j2534-using-2004-api-part-2
[to_ping] =>
[pinged] =>
[post_modified] => 2021-11-12 14:14:51
[post_modified_gmt] => 2021-11-12 14:14:51
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?post_type=developer_blog&p=32281
[menu_order] => 0
[post_type] => developer_blog
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[1] => WP_Post Object
(
[ID] => 33302
[post_author] => 38
[post_date] => 2021-05-05 07:59:07
[post_date_gmt] => 2021-05-05 07:59:07
[post_content] =>
[post_title] => New CANtrace U100 package April 2021
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => new-cantrace-u100-package-april-2021
[to_ping] =>
[pinged] =>
[post_modified] => 2021-05-05 08:00:46
[post_modified_gmt] => 2021-05-05 08:00:46
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=33302
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[2] => WP_Post Object
(
[ID] => 32251
[post_author] => 35351
[post_date] => 2021-05-04 16:43:09
[post_date_gmt] => 2021-05-04 16:43:09
[post_content] => [vc_row][vc_column][vc_column_text]
This Developer Blog is the first of a 3-part series taking a look at SAE J2534. This series introduces SAE J2534 (including it's multiple editions), describes how to use the 2004 API, and then provides instruction on getting started with Kvaser and J2534.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_message color="info"]
This blog is part of 3-part series on J2534:
SAE J2534 (Part I): An Introduction
SAE J2534 (Part II): Using the 2004 API
SAE J2534 (Part III): Getting Started with Kvaser and SAE J2534[/vc_message][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="1 History and Concept"][vc_header_raket header_type="h3" header="1.1 Everything that’s Happened"][/vc_column][/vc_row][vc_row][vc_column width="1/2"][vc_column_text]First the earth cooled, and then the dinosaurs came.
Then in 2002 people at the Society of Automotive Engineers, SAE, decided it would be a good idea to standardize the way service technicians reprogram vehicles. Rather than every technician buying different devices they want to plug into their cars and the car manufacturer having to support them all, the service technician should buy a standardized device – still from whichever supplier they wanted – with a single standardized API. This would help the vehicle manufacturers and the service technicians protect their technological investments in an ever changing field.[/vc_column_text][/vc_column][vc_column width="1/2"][vc_single_image image="32279"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
That year, 2002, SAE released a standard called SAE J2534-1 for this purpose, standardizing what they called “Pass-Thru Device” along with an API for controlling it. This Pass-Thru Device can then communicate to cars using any of a number of protocols that service technicians may need, while being controlled by a single interface of functions that are all called PassThruXxx() — just in case you forget you’re using a “Pass-Thru Device”.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/2"][vc_single_image image="32253"][/vc_column][vc_column width="1/2"][vc_column_text]
The original 2002 version of the standard seems to have been lost to time, relegated to “superseding” clauses and compliance lists. Two years later an updated version was released, and as updated versions will be a common theme I will refer to this standard as J2534-1 2004.
The J2534-1:2004, and J2534-1:2002, standards set down the basics of the J2534 (or Pass-Thru) API; the sequence of operation as well as support for CAN 2.0, ISO-TP, ISO 9141 & 14230, and a handful more. In 2006 this was extended by J2534-2:2006 which added optional features such as several more protocols, and the ability to connect to more than one device with more than one channel. Later on J2534-2:2010 arrived with additional minor optional features, replacing J2534-2:2006 without much fuss.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Note that all features from the J2534-2 standards are explicitly optional; they do not need to be supported for a device to be J2534 compliant.[/vc_column_text][vc_column_text]
Then in 2015 came a big change. J2534-1:2015 was released, which despite having the same numbers as J2534-1:2004 has an entirely new API: a new sequence of operations, brand new functions, new interfaces for old functions, etc. It still supports the same protocols that J2534-1:2004 supports but there were two new goals: no optional features and no (okay, fewer) ambiguities.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/2"][vc_column_text]
And scrapping optional features was just as well because the optional features, from the J2534-2 standards, relied on the 2004 API which J2534-1:2015 wasn’t compatible with anyway.[/vc_column_text][vc_column_text]
The final event in our J2534 saga is the release of J2534-2:2019, with updated optional features. As the point of J2534-1 2015:was to remove optional features, this is still based on J2534-1:2004. So despite J2534-2:2019 being released after the J2534-1:2015, it is still based on the earlier J2534-1 from 2004.[/vc_column_text][vc_column_text]
And J2534-2:2019 is notable because it is the standard that introduces support for CAN FD, including ISO-TP FD. It also introduced a “discovery mechanism” which allows user applications to ask the DLL things like which protocols it supports and how many channels the device has.[/vc_column_text][/vc_column][vc_column width="1/2"][vc_single_image image="32254"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
So there is now an old version of J2534/Pass-Thru based on J2534-1:2004 with optional features which has been updated more recently than the newer version of Pass-Thru/J2534 defined in J2534-1:2015 but which doesn’t support CAN FD.[/vc_column_text][vc_column_text]
Confused yet? Well here’s a list of all the different J2534 standards, and what each one brought to the metaphorical table:[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
- J2534-1 2002
- J2534-1 2004 (×2)
- CAN 2.0 & K-line based protocols
- J2534-2 2006 (based on J2534-1 2004)
- Multiple devices and channels
- Mixing CAN 2.0 and ISO-TP messages on the same channel
- (J2534-2 2010 (based on J2534-1 2004))
- J2534-1 2015
- New API.
- CAN 2.0 & K-line based protocols
- More explicitly stated behaviour, more verbose interface
- No optional features
- J2534-2 2019 (still based on J2534-1 2004)
- CAN FD
- Discovery mechanism
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="1.2 The “Pass-Thru Concept”"][vc_column_text]
So what is the idea behind J2534 and its Pass-Thru device and API? Well, J2534-1:2004 has this to say about what it calls the “Pass-Thru Concept”:[/vc_column_text][vc_column_text]
[J2534-1] defines the following two interfaces for the SAE J2534 pass-thru device:
- Application program interface (API) between the programming application running on a PC and a software device driver for the pass-thru device
- Hardware interface between the pass-thru device and the vehicle
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
The standard assumes a certain setup. You have a vehicle with a J1962 connector, into which you plug a Pass-Thru Device. That device is then plugged into a computer with a 32-bit Windows OS, where the user application uses a DLL with a standardized interface to control the Pass-Thru Device.[/vc_column_text][vc_single_image image="32513" img_size=""][vc_column_text]
Car in snow: CC-0 via pxhere.com; Pass-Thru Device: © Elsa Carlsson & Kvaser AB; IBM 300PL: CC-0 by Automaton399 @ wikimedia commons.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
However, Kvaser does not sell a Pass-Thru device, but still provides a J2534 DLL. This lets customers use the same standardized API they use for Pass-Thru devices with any of Kvaser’s interfaces. This is done by wrapping Kvaser’s CANlib library, adding and extending functionality to implement the applicable parts of the J2534 standards.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image="32256"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
However, for this to work some parts of the standard have to be reinterpreted, or don’t apply at all. The most obvious such thing is the PassThruSetProgrammingVoltage() function, which is just something current Kvaser devices aren’t made to support. Therefore any attempt to use this function in Kvaser’s J2534 DLL will simply return “not supported”.
Another mismatch is that J2534 specifically mandates a 32-bit dll while Kvaser compiles both a 32-bit and a 64-bit version of the DLL. Most mismatches however are more subtle and may evolve over time, so the best place to learn about them is the official readme file for the version of the DLL you are using.
So technically, Kvaser’s J2534 DLL provides a J2534 API for the CANlib library which is based on and compatible with the API from J2534-1:2004 and has as many optional features from J2534-2:2019 as are applicable. In terms of protocols, this means support for CAN 2.0, CAN FD, ISO-TP, and ISO-TP FD.
In the next part we will look at what these four protocols are, and how to use the Pass-Thru API to communicate using any of them.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="1.3 Overview of the two APIs"][vc_column_text]
Here are all functions in both the 2004 and 2015 version of the J2534 API, with a short description as provided by the relevant standard.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/6"][/vc_column][vc_column width="2/3"][vc_single_image image="32259"][vc_single_image image="32280"][/vc_column][vc_column width="1/6"][/vc_column][/vc_row][vc_row][vc_column][vc_separator_raket][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Definitions
- ISO-TP
The Transport Protocol defined in 15765-2:2011, without the support for CAN FD which was introduced in 15765-2:2016. Sometimes ambiguously called simply ISO 15765-2 or ISO 15765.
- ISO-TP FD
The Transport Protocol defined in 15765-2:2016 (including the support for CAN FD).
- CAN
The Controller Area Network as described in ISO 11898, a blanket term for both CAN 2.0 and CAN FD.
- CAN 2.0
The “classic” CAN with up to eight bytes of data and no support for bit rate switching.
- CAN FD
CAN Flexible Data rate protocol that supports longer data than CAN 2.0 as well as bit rate switching.
- J2534
A family of standards that specify the Pass-Thru device and the Pass-Thru API used to communicate to the device via a J2534 DLL.
- J2534 DLL
The DLL provided by an interface manufacturer, which conforms to the Pass-Thru API.
- Pass-Thru API
The API of all J2534 DLLs, which the vehicle manufacturer can use regardless of which company’s J2534 DLL is actually in use.
- Pass-Thru devic
A specific type of device standardized by J2534, which has an accompanying J2534 DLL.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="More Resources"][vc_column_text]
[/vc_column_text][/vc_column][/vc_row]
[post_title] => SAE J2534 (Part I): An Introduction
[post_excerpt] => The history and development of the SAE J2534 specification, including J2534-1, J2534-2, and the 2004 and 2019 releases.
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => sae-j2534-introduction-part-1
[to_ping] =>
[pinged] =>
[post_modified] => 2021-11-12 13:09:26
[post_modified_gmt] => 2021-11-12 13:09:26
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?post_type=developer_blog&p=32251
[menu_order] => 0
[post_type] => developer_blog
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[3] => WP_Post Object
(
[ID] => 33233
[post_author] => 38
[post_date] => 2021-04-30 10:29:43
[post_date_gmt] => 2021-04-30 10:29:43
[post_content] => [vc_row][vc_column][vc_single_image image="33271"][vc_column_text][/vc_column_text][vc_column_text]Kvaser partner MathWorks latest software release of MATLAB® and Simulink®, R2021a, adds
CAN FD capability to the Vehicle Network Toolbox™, MathWork’s software environment for communicating with in-vehicle networks.
The new version allows users to decode and visualize CAN FD and CAN bus traffic, using the CAN FD Explorer and CAN Explorer apps within MATLAB to acquire CAN FD data.
The update also includes improved support for
J1939 and MDF file updates.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]A replay of Kvaser and MathWorks webinar entitled ‘CAN FD Data Acquisition & Visualisation with MATLAB and Kvaser Hardware’ can be found
here.[/vc_column_text][vc_button_raket title="Watch Webinar Replay" text="" page_id="https://youtu.be/MuV_7FlXxRU"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
[/vc_column_text][vc_column_text]Find out more about R2021a here
https://www.mathworks.com/products/new_products/latest_features.html
The release notes can be found here
https://www.mathworks.com/help/vnt/release-notes.html[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
[/vc_column_text][/vc_column][/vc_row]
[post_title] => MathWorks adds CAN FD capability to MATLAB and Simulink
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => mathworks-adds-can-fd-capability-to-matlab-and-simulink
[to_ping] =>
[pinged] =>
[post_modified] => 2021-05-03 20:42:49
[post_modified_gmt] => 2021-05-03 20:42:49
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=33233
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[4] => WP_Post Object
(
[ID] => 33180
[post_author] => 6
[post_date] => 2021-04-27 16:14:23
[post_date_gmt] => 2021-04-27 16:14:23
[post_content] => [vc_row][vc_column width="1/2"][vc_column_text]This CiA technology day focuses on specific application fields and topics, relevant for the Chinese CAN community. The speakers discuss the status of CAN FD and latest trends. Additionally, they consider the impact of CAN FD on higher-layer protocols, such as CANopen or J1939.[/vc_column_text][vc_column_text]
Intended audience
Decision makers, device and system designers, assessing the status of CAN-based networking in China[/vc_column_text][/vc_column][vc_column width="1/2"][vc_single_image image="33186"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Agenda*
- Welcome & Introduction
- CAN FD status & outlook
- CAN FD light
- Break
- CANopen FD
- CAN FD & J1939
- CiA groups
* Subject to change without notice.
[/vc_column_text][vc_column_text]Date: 2021-05-18
Time: 08:00 Berlin (CET) | 14:00 Beijing (CST) | 01:00 Chicago (CST)[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Price
Participation is free-of-charge.
Language
The presentations language is Chinese or English with Chinese translation.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_button_raket title="Register Now" text="" page_id="https://www.can-cia.org/services/seminars/registration/235/235/?tx_seminars_pi1%5Buid%5D=235&redirect_url=https%3A%2F%2Fwww.can-cia.org%2Fservices%2Fseminars%2Fregistration%2F235%2F235%2Fregister%2F"][/vc_column][/vc_row]
[post_title] => Kvaser Presents CAN FD at Chinese CiA Technology Day
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => kvaser-presents-can-fd-at-chinese-cia-technology-day
[to_ping] =>
[pinged] =>
[post_modified] => 2022-04-04 10:19:13
[post_modified_gmt] => 2022-04-04 10:19:13
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=33180
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[5] => WP_Post Object
(
[ID] => 33158
[post_author] => 6
[post_date] => 2021-04-26 21:29:00
[post_date_gmt] => 2021-04-26 21:29:00
[post_content] => [vc_row][vc_column width="5/6"][vc_single_image image="33161"][/vc_column][vc_column width="1/6"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]Kvaser will be joining Accurate Technologies to host a joint webinar on May 12th, 01:00 PM - 02:00 PM EDT.
This webinar will cover an introductory level overview of the J1939 collection of SAE standards. Below is a list of topics that will be covered along with a variety of application demonstrations in ATI’s
CANLab Network Analysis software.
- Different parts of J1939 – The Communications “Stack”
- The Physical Network; J1939-11
- CAN Frames and Datalink Layer; J1939-21
- The Data Field and DBC File
- PGNs and SPNs
- Diagnostic Messages; J1939-73
[/vc_column_text][vc_button_raket title="Register Now" text="" page_id="https://www.accuratetechnologies.com/News%20and%20Events/Event/ati-kvaser-event"][/vc_column][/vc_row][vc_row][vc_column][vc_separator_raket][vc_header_raket header_type="h2" header="Presenters"][/vc_column][/vc_row][vc_row][vc_column width="1/4"][vc_single_image image="29163" style="vc_box_circle_2"][/vc_column][vc_column width="3/4"][vc_column_text]
Maxwell Church
ATI Business Development and USA Sales Manager
Accurate Technologies
[/vc_column_text][vc_column_text]Max has a long history of technical sales and support experience. His debut in the automotive prototype testing and development industry began in 1991, and he has since worked in a wide variety of roles such as prototype build and instrumentation technician, purchasing, application engineer, and sales manager. Currently Max is a part of the business development team at ATI.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/4"][vc_single_image image="29162"][/vc_column][vc_column width="3/4"][vc_column_text]
Bryan Hennessy
Field Applications Engineer
Kvaser[/vc_column_text][vc_column_text]Bryan has a history in design engineering, applications engineering, project management and small business ownership, which all contribute to his knowledge in the electronics industry. Bryan’s time and training as a field applications engineer gave him the extensive knowledge in supporting electronic products as well as working with large strategic customers.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator_raket][vc_header_raket header_type="h2" header="Related Products"][/vc_column][/vc_row][vc_row][vc_column][vc_raket_software post_id="4642"][/vc_column][/vc_row]
[post_title] => Webinar: J1939 Intro With Accurate Technologies (ATI)
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => webinar-j1939-intro-with-accurate-technologies-ati
[to_ping] =>
[pinged] =>
[post_modified] => 2022-04-04 10:19:13
[post_modified_gmt] => 2022-04-04 10:19:13
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=33158
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[6] => WP_Post Object
(
[ID] => 33001
[post_author] => 192
[post_date] => 2021-04-22 17:00:10
[post_date_gmt] => 2021-04-22 17:00:10
[post_content] => [vc_row][vc_column][vc_column_text]Interface LEDs can be difficult to see at a distance. Kvaser’s engineering team sought to resolve this issue with two high-visibility LED bars on
the Kvaser U100 that can be seen from several metres away.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="2/3"][vc_column_text]One bar shows 'transmit', Tx, the other 'receive', Rx. Different colours and blink patterns show different information. For example, a steady green light (for power) shows that the device is working correctly.[/vc_column_text][vc_column_text]The size of the LED bar indicates bus load. If only half the LED is illuminated in yellow (for traffic), the interface is handling 50% bus load.
Red signals errors and overruns, so the engineer knows immediately when something is wrong and in which traffic direction. White light signals an alert and blue is for system configuration and of course if there’s no light, the power supply should be checked.[/vc_column_text][vc_column_text]See below for a detailed breakdown of what the Kvaser U100 LEDs mean.[/vc_column_text][/vc_column][vc_column width="1/3"][vc_single_image image="36680"][/vc_column][/vc_row][vc_row][vc_column][vc_text_separator title="UNDERSTANDING THE KVASER U100 LEDs"][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="Definitions of LED states and colors"][vc_column_text]The Kvaser U100 has one Tx LED Bar and one Rx LED Bar. Each LED Bar has a status area, the Tx LED Bar has a status area towards the USB end of the bar, and the Rx LED bar has a status area towards the CAN end of the bar. This is shown in Figure 1.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image="37703"][vc_column_text]
Figure 1: The Tx and Rx LED bars on the Kvaser U100 includes status areas.[/vc_column_text][vc_column_text]The Tx LED bar lit area grows from the USB end of the LED bar towards the CAN end of the bar as CAN Tx traffic is increased. Likewise, the Rx LED bar lit area grows from the CAN end of the LED bar towards the USB end of the bar as the message rate of the received traffic is increased, see Figure 2 below.
In this example the unit is transmitting data, which shows a yellow Tx status area. No CAN traffic is received and as such the Rx status area is green.[/vc_column_text][vc_single_image image="37704"][vc_column_text]
Figure 2: The Tx LED bar lights up from the USB side to the CAN side of the unit,while the Rx LED bar lights up from the CAN side to the USB side of the unit.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]The total size of the LED bars are indicating the current bus load, e.g. Figure 2 shows only receiving CAN messages at 50% bus load.
Figure 3 shows two different bus load conditions. The image on the left shows the unit transmitting and receiving data corresponding to 50% bus load in each direction for a total of 100% bus load. The image on the right shows the unit transmitting data corresponding to 100% bus load. Both images indicate a bus load of 100%.[/vc_column_text][vc_single_image image="37705"][vc_column_text]
Figure 3: The total size of the LED Bars is proportional to the bus load. Both images indicate a bus load of 100%.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="Definitions of Information Types and States"][vc_column_text]A Kvaser U100 device has two traffic LED bars where part of each LED bar is also used as a status area. Different colors are used for different types of information and different blink patterns define the current state see table 1 and table 2[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="2/3"][vc_single_image image="37706"][vc_column_text]
Table 1: Different types of information.
[/vc_column_text][/vc_column][vc_column width="1/3"][/vc_column][/vc_row][vc_row][vc_column width="2/3"][vc_single_image image="37707"][vc_column_text]
Table 2: Definitions of the indicator states.
[/vc_column_text][/vc_column][vc_column width="1/3"][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="Interface mode"][vc_column_text]The device is in interface mode when connected to the PC via USB. If the status area is presenting a steady green light, the device is in interface mode and is working correctly.
When connected to the computer for the first time, the status area will Fast Blink with blue light until the Kvaser Driver is installed and the device has automatically received a USB configuration.
Table 3 summarizes the information shown in interface mode.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="2/3"][vc_single_image image="37708"][vc_column_text]
Table 3: LED inidications in interface mode.
[/vc_column_text][/vc_column][vc_column width="1/3"][/vc_column][/vc_row]
[post_title] => Visible at a distance: The Kvaser U100’s smart LEDs
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => visible-at-a-distance-the-kvaser-u100s-smart-leds
[to_ping] =>
[pinged] =>
[post_modified] => 2022-03-10 22:55:11
[post_modified_gmt] => 2022-03-10 22:55:11
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=33001
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[7] => WP_Post Object
(
[ID] => 32521
[post_author] => 23
[post_date] => 2021-04-04 20:45:06
[post_date_gmt] => 2021-04-04 20:45:06
[post_content] => [vc_row css=".vc_custom_1617655490580{margin-bottom: 30px !important;}"][vc_column][vc_column_text]Fast development of intelligent networking technology in China, coupled with the driving forces for vehicle intelligent networking, has led to the vehicle intelligent networking becoming a mainstream development of the automobile industry. The demand by local vehicle manufacturers of a test software customised for the Chinese market, especially for ADAS(Advanced Driving Assistance System) tests, has become increasingly stronger. As such, Softing China has launched the Q-Vision software, which supports ADAS testing and can be customised and developed in line with the local automaker’s requirements.
As a world leading CAN solution provider, Kvaser is focused on advanced CAN hardware development. Widely applied in the developing and testing by major vehicle and auto component manufacturers, its CAN/LIN hardware products are robust, incredibly reliable and very cost efficient.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="Q-Vision"][/vc_column][/vc_row][vc_row][vc_column width="1/2"][vc_column_text]Q-vision is a newly developed tool software, serving for CAN bus analysis, measurement and calibration, and ECU diagnosis, which has been widely adopted by automotive manufacturers.[/vc_column_text][vc_column_text]Q-Vision supports CAN (FD), LIN, Ethernet, LVDS and other automotive systems, as well as CCP/XCP/UDS/OBD and other protocols, and is able to import databases in DBC/LDF/ARXML/A2L/ODX formats.[/vc_column_text][/vc_column][vc_column width="1/2"][vc_single_image image="32525"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
It supports the following ADAS test functions：
- Display the targeted sensor data of the test
- GPS data (navigation information displayed on the map)
- LiDAR lidar
- RADAR millimeter-wave radar
- camera, etc
- Data fusion
- Q-Vision is able to call external data algorithm through Simulink / Python interface, to fuse sensor data and display it in the same window
[/vc_column_text][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_header_raket header_type="h3" header="Kvaser Products"][vc_column_text]Kvaser provides more than 60 CAN-related products (also supporting CAN FD and LIN) for online data logging, simulation, monitoring, diagnosis, calibration, flashing of automotive networks.[/vc_column_text][vc_column_text]
| Product |
Bus Type |
Interface |
Channel |
Connector |
t Script |
| Leaf series |
CAN/CAN FD/LIN/LSC/SWC |
USB |
1 |
DSUB9/M12/J1939/OBD II |
√ |
| USBcan series |
CAN/CAN FD/LSC/SWC |
USB |
multi |
DSUB9 |
√ |
| Memorator series |
CAN/CAN FD/SWC/LSC |
USB |
multi |
DSUB9 |
√ |
| PCI series |
CAN/CAN FD |
PCI board card |
multi |
DSUB9 |
- |
| Ethercan series |
CAN |
Ethernet |
1 |
DSUB9 |
√ |
| Blackbird series |
CAN |
WLAN |
1 |
DSUB9 |
√ |
| Airbridge series |
CAN |
FHSS modulated
2.4 GHz GFSK |
1 |
DSUB9 |
- |
| Hybrid series |
CAN(FD)&LIN |
USB |
2 |
DSUB9 |
√ |
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column width="2/3"][vc_header_raket header_type="h3" header="Product Examples"][vc_column_text]
Kvaser Leaf Pro HS v2
(EAN：73-30130-00843-4)
- Support CAN FD
- Quick and easy Plug-and Play installation
- Support both 11-bit(CAN 2.0A) and 29-bit (CAN 2.0B active) identifiers
- Power is taken from the USB bus
- Galvanic isolation
- High-speed CAN connection (compliant with ISO 11898-2)，up to 1Mbit/s
- Fully compatible with J1939, CANopen, NMEA2000 and DeviceNet
- Timestamp accuracy up to 1µs
[/vc_column_text][/vc_column][vc_column width="1/3"][vc_single_image image="32540"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Kvaser Hybrid 2xCAN/LIN
(EAN：73-30130-00965-3)[/vc_column_text][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column width="2/3"][vc_column_text]
- Support high speed CAN (ISO 11898-2) up to 1Mbit/s and LIN 2.2A（ISO 17987 Part 1-7）up to 20 kbit/s
- Capable of sending up to 20000 messages per second, per CAN channel
- Supports CAN FD up to 5Mbit/s (with proper physical layer implementation)
- Quick and easy plug-and-play installation; USB powered
- Supports CAN 2.0 A and CAN 2.0 B active
- Fully compatible with J1939, CANopen, NMEA2000 and DeviceNet
- Supplied with Kvaser CANlib and Kvaser LINlib, free software APIs that are common to all Kvaser hardware and enable the channels to be configured intuitively and fast
- Support SocketCAN
[/vc_column_text][/vc_column][vc_column width="1/3"][vc_single_image image="32542"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Kvaser Memorator Pro 2xHS v2
(EAN：73-30130-00819-9)[/vc_column_text][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column width="2/3"][vc_column_text]
- Monitor two CAN channels simultaneously using just one device and log data to an expandable SD card slot
- Supports CAN FD up to 8Mbit/s (with proper physical layer implementation)
- Script functionality allows users to develop customised t-script applications written in the Kvaser t programming language
- Plug and play installation; power derived from the USB connection, CAN or an in-built power supply
- Supports silent mode for analysis tools – listens to the bus without interfering
- Detection and generation of error frames and remote frames
- LED lights alert user to device status, including signalling a full SD card or card error
- Built-in Kvaser MagiSync™ technology time synchronises with other Kvaser interfaces connected to the same PC, resulting in simpler and more accurate multichannel data capture
- Compatible with J1939, CANopen, NMEA 2000 and DeviceNet
- Support SocketCAN
[/vc_column_text][/vc_column][vc_column width="1/3"][vc_single_image image="32543"][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="Solution with Q-Vision+Kvaser CAN/CAN FD"][vc_column_text]The teaming up of Q-Vision master computer software and Kvaser hardware can fulfil the monitoring, data collection and analysis, diagnosis and calibration of CAN/CAN FD/LIN bus network. Depending on variating test requirements, you are able to choose different types of connectors such as DSUB9, OBDII, M12, etc., and monitor multiple nodes online simultaneously, which is an essential set of tools in the whole process of V-Mode development.[/vc_column_text][vc_single_image image="32545"][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="CAN(FD) Solution"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
CAN(FD) Data Collection
In the Q-Vision software, hardware devices can be configured in Device Configuration menu on Start page. According your requirements, you can choose CAN or CAN FD mode, configure baud rate and import DBC file.[/vc_column_text][vc_single_image image="32546"][vc_column_text]The collected CAN (FD) signals can be displayed in the Trace window: to display CAN channel, CAN ID, names, DLC, data, time and other information. Q-Vision supports message filtering.[/vc_column_text][vc_single_image image="32547"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
CAN(FD) Transmission
Q-vision supports CAN (FD) message transmission. It can select the desired CAN channel to send CAN messages and supports extended frames, up to 64 bytes DLC. Message data can be customised, or random data can be generated by clicking Randomize data.[/vc_column_text][vc_single_image image="32549"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
CAN(FD) Statistic Window
After the CAN (FD) Chanel selects the corresponding CAN channel, it will measure and display the CAN bus load rate, including the maximum load, the minimum load, and the average load, as well as the data of bytes and messages.[/vc_column_text][vc_single_image image="32550"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
CAN(FD) Replay recorded data
Q-Vision supports adding asc message file for transmission, and can select file address and transmission time interval on the CAN channel to send out all data of the file.[/vc_column_text][vc_single_image image="32551"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
ADAS Test
Q-Vision is connected to data collecting equipment or bus network through a Kvaser communication card. It can analyze the data and generate cloud map online to complete cloud integration of ADAS test.[/vc_column_text][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
GPS Data collection
Q-Vision collects reliable GPS data and is able to achieve high accuracy positioning and image display.[/vc_column_text][vc_single_image image="32552"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
Camera video data collection
Q-Vision is able to collect and display video data, which can be applied to monitor the external environment of vehicles easily. At the same time, the video monitoring can also be configured, according to the corresponding video format selected.[/vc_column_text][vc_single_image image="32553"][/vc_column][/vc_row][vc_row css=".vc_custom_1617655497131{margin-bottom: 30px !important;}"][vc_column][vc_column_text]
Ibeo lidar cellection
Through configuring the lidar IP and port number, displaying the top view with lidar data can be achieved.[/vc_column_text][vc_single_image image="32554"][vc_column_text]With both Q-Vision software and Kvaser hardware products on board, the online recording, simulation, monitoring, diagnosis, calibration, flashing and other functions of various bus networks can be well achieved. And Q-Vision software also supports ADAS tests. For the automotive industrial, this new option in bus networks analysis is more reliable, faster and handier.[/vc_column_text][/vc_column][/vc_row]
[post_title] => Solution with Q-Vision + Kvaser CAN/CAN FD/LIN
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => solution-with-q-vision-kvaser-can-can-fd-lin
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-05 22:28:14
[post_modified_gmt] => 2021-04-05 22:28:14
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=32521
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[8] => WP_Post Object
(
[ID] => 32414
[post_author] => 22709
[post_date] => 2021-04-01 08:04:58
[post_date_gmt] => 2021-04-01 08:04:58
[post_content] => [vc_row][vc_column][vc_column_text][/vc_column_text][vc_column_text]
On March 22, 2021, SAE published the SAE J1939-22 document. This document is the latest addition to the J1939 set of standards for electronic controls within heavy duty vehicles, specifically incorporating the requirements of CAN FD.[/vc_column_text][vc_column_text]Over a span of four years, a team of talented volunteer engineers, led by Task Force Chairman Andy Vlietstra of Woodward, created a ground up specification packaging J1939 data to take advantage of the increased capabilities of CAN FD.[/vc_column_text][vc_column_text]Bryan Hennessy, Kvaser Field Applications Engineer notes: “This is a specification that will improve data communications within heavy duty vehicles throughout the world for decades to come.”[/vc_column_text][vc_column_text]The J1939 standards are available for purchase from SAE directly
at this link.[/vc_column_text][vc_button_raket title="Get SAE J1939-22 Specification" text="" page_id="https://www.sae.org/standards/content/j1939-22_202103/"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text][/vc_column_text][vc_column_text]Kvaser produces a diverse line of interfaces and data loggers that support CAN FD and J1939 over CAN FD. See our complete line of
CAN FD offerings here.[/vc_column_text][vc_button_raket title="CAN FD Interfaces" text="" page_id="https://www.kvaser.com/products-services/our-products/#/?descriptors=can_fd"][/vc_column][/vc_row]
[post_title] => Specification for J1939 over CAN FD published
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => specification-for-j1939-over-can-fd-published
[to_ping] =>
[pinged] =>
[post_modified] => 2022-04-04 10:19:13
[post_modified_gmt] => 2022-04-04 10:19:13
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=32414
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[9] => WP_Post Object
(
[ID] => 33959
[post_author] => 192
[post_date] => 2021-03-30 19:27:21
[post_date_gmt] => 2021-03-30 19:27:21
[post_content] => [vc_row][vc_column][vc_column_text]Kvaser moves products to “Not For New Design” (NFND) status when we receive information that future production will be limited by issues such as End of Life notices on critical components.
NFND products will be available as long as possible, but are subject to increased price and lead times.
Contact Kvaser directly for price and lead time.
When possible, however, we suggest you migrate to newer versions of a Kvaser product line. The most recent generation of Kvaser products benefit from the latest software and firmware updates, fast lead times, and competitive pricing. All NFND and EOL products are updated with suggested migration products on their individual product pages.
If you are a customer of one of the NFND products below, please contact us and we can help you migrate to the replacement product for your next purchase.[/vc_column_text][vc_column_text]
Products beginning their 12-month NFND phase out:
Products completing their 12-month NFND phase-out:
(Increased price and lead time now apply.)
[/vc_column_text][vc_column_text]Download the
full announcement here.[/vc_column_text][/vc_column][/vc_row]
[post_title] => Kvaser 2021 Product 'Not For New Design' (NFND) Announcement
[post_excerpt] => NFND announcement for: Kvaser Leaf SemiPro HS (EAN: 73-30130-00242-5)
Kvaser Leaf SemiPro LS (EAN: 73-30130-00260-9)
Kvaser Leaf Professional LS (EAN: 73-30130-00261-6)
Kvaser Leaf SemiPro SWC (EAN: 73-30130-00263-0)
Kvaser Leaf Professional SWC (EAN: 73-30130-00264-7)
Kvaser Leaf Professional LIN (EAN: 73-30130-00269-2)
Kvaser Memorator Professional HS/LS (EAN: 73-30130-00417-7)
Kvaser Memorator R SemiPro (EAN: 73-30130-00490-0)
Kvaser Leaf SemiPro Rugged HS (EAN: 73-30130-00506-8)
Kvaser Leaf Professional Rugged HS (EAN: 73-30130-00509-9)
Kvaser USBcan Pro 5xHS (EAN: 73-30130-00779-6)
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => kvaser-2021-product-not-for-new-design-nfnd-announcement
[to_ping] =>
[pinged] =>
[post_modified] => 2022-12-22 00:38:27
[post_modified_gmt] => 2022-12-22 00:38:27
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?p=33959
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
)
[post_count] => 10
[current_post] => -1
[in_the_loop] =>
[post] => WP_Post Object
(
[ID] => 32281
[post_author] => 35351
[post_date] => 2021-05-19 16:47:53
[post_date_gmt] => 2021-05-19 16:47:53
[post_content] => [vc_row][vc_column][vc_column_text]
This Developer Blog is the second of a 3-part series taking a look at SAE J2534. This series introduces SAE J2534 (including it's multiple editions), describes how to use the 2004 API, and then provides instruction on getting started with Kvaser and J2534.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_message]
This blog is part of 3-part series on J2534:
SAE J2534 (Part I): An Introduction
SAE J2534 (Part II): Using the 2004 API
SAE J2534 (Part III): Getting Started with Kvaser and SAE J2534[/vc_message][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="2 Using the 2004 API"][vc_column_text]
To use the J2534 API productively, you need both an understanding of the protocol you want to use and the API’s sequence of operations for that protocol — this is despite J2534’s efforts to be protocol-agnostic. Let’s start with a brief overview of the CAN-based protocols supported (as of J2534-2 2019), and then quickly go over how you would use each one through the J2534 API.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="2.1 Protocol Basics"][vc_column_text]
We’ll be going through the four protocols currently supported by Kvaser’s J2534 DLL: CAN 2.0, CAN FD, ISO-TP, and ISO-TP FD. In J2534 they have separate protocol “ID”s and we will treat them as separate protocols, but of course the truth is slightly more nuanced. The two FD-protocols are really updated versions of the non-FD versions that support the CAN Flexible Data Rate Format, still providing all the functionality of their non-FD versions. It is also worth mentioning that ISO-TP (with or without FD) is a higher-level protocol that exists on top of CAN (correspondingly 2.0 or FD).[/vc_column_text][vc_single_image image="32282"][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.1.1 CAN 2.0"][vc_column_text]
The basis of all following protocols, CAN 2.0 (sometimes called Classic CAN) is a fault-tolerant protocol for broadcasting messages, called Frames, for all nodes on the bus to see. Frames consist of CAN Data (up to 8 bytes in length) and a CAN ID that can be either 11 (standard) or 29 (extended) bits long, and is used to prioritize which frames are let onto the bus first — known as “arbitration”. These frames are then sent on the bus at a predefined bitrate.[/vc_column_text][vc_header_raket header_type="h4" header="2.1.2 CAN FD"][vc_column_text]
In 2015 the standards document for CAN, ISO11898, was updated to include CAN FD; CAN with a Flexible Data rate. This means that you can now, optionally, use one bitrate for the arbitration of CAN IDs and another (higher one) for sending the actual data. And to make use of the higher transmit speeds we can also send much larger frames, with CAN Data lengths of 12, 16, 20, 24, 32, 48, and 64 bytes – in addition to the up to eight bytes already allowed by CAN 2.0.[/vc_column_text][vc_column_text]
On the bus, the decision to use bitrate switching, BRS, is encoded per frame in one of the transmitted bits. The overall decision of whether to use CAN 2.0 or CAN FD is also encoded in one of the transmitted bits (though you can’t use BRS if you don’t also use FD), meaning devices that support CAN FD can read and write messages in three different formats:[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/6"][/vc_column][vc_column width="2/3"][vc_single_image image="32283"][/vc_column][vc_column width="1/6"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Though note that we can still choose whether we want 11 bit or 29 bit IDs regardless of format. The two bitrates used with BRS are usually called “Arbitration Bitrate” and “Data Bitrate” (maybe throwing a “-Phase” into the middle as well).[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.1.3 ISO-TP"][vc_column_text]
ISO 15765 is a family of standards by the International Standards Organization. We’re interested in the second part, ISO 15765-2, which defines a “Transport protocol and network layer services” — specifically we need to know about the transport protocol, ISO-TP.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="1/2"][vc_column_text]
Note that this protocol is given various different names by different people, as it is never named in the standard itself. J2534 calls it ISO 15765 (despite there being four other standards in the ISO 15765 family), others call it ISO 15765-2 (despite that standard standardizing a lot more than just the transport protocol), but I will continue to call it ISO-TP (ISO Transport Protocol) as that is the most unambiguous term I have found, referring to the transport protocol and the transport protocol only.[/vc_column_text][vc_column_text]
Now take a deep breath, we haven’t actually started on how ISO-TP works. ISO-TP is a higher-level protocol built on top of CAN 2.0, whose main purpose is to allow messages to be “segmented”, split over multiple CAN frames — which means you can send much longer messages. To do so in an orderly fashion, it uses a back-and-forth between the sender and the receiver to control how quickly frames should be sent and make sure they arrive.
This back-and-forth means that, if you want your message to be segmented, it has to be sent to a sole receiver. This is the final part of ISO-TP; messages can either be sent one-to-one or one-to-many. In ISO-TP parlance, one-to-one communication is called “physical addressing” and one-to-many is called “functional addressing”. Although if you are not used to addressing in vehicles those names are more confusing than helpful.[/vc_column_text][/vc_column][vc_column width="1/2"][vc_single_image image="32284"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Segmentation
So you want to send an ISO-TP message? Well, if it fits in a single CAN frame then all is well and it is transmitted directly as a Single Frame (SF). For one-to-many communication, this is the only allowed method — one-to-many ISO-TP messages must fit into a SF.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column width="2/3"][vc_column_text]
But for one-to-one communication it’s okay to send longer messages. In that case, the transmitter sends a single CAN frame with as much payload as can fit, a First Frame (FF), and then a (single) receiver must be set up to reply with a Flow Control (FC) frame. This can pause, cancel, or continue the transmission, and in the case of continuing it contains two parameters that will be in use until the next FC: called STmin (Separation Time MINimum) and BS (Block Size).
The transmitter will then send one “block” of CAN frames containing payload, called Consecutive Frames (CFs), and the number of such frames sent is controlled by Block Size. The Separation Time Minimum is the amount of time that must pass between CAN frames being sent on the bus. After a block is transmitted, the transmitter waits for another FC and then repeats. When the entire payload has been transmitted, the conversation quietly stops.[/vc_column_text][/vc_column][vc_column width="1/3"][vc_single_image image="32286"][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Addressing
Each node in the network has an address, and for each message this is compiled into “Address Information” in one of several different ways, some standardized and some not, each with several different variations and done differently depending on its functional or physical addressing.
Fortunately for me, the J2534 API leaves this all up to the user. As far as the API is concerned, each ISO-TP message has an address. This can either be an “extended” address, in which case it is one byte longer than the CAN ID, or just a normal one in which case it is exactly equivalent to the CAN ID.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
It is then up to the user to define:
- Which addresses to accept SFs from.
- Which addresses to listen to segmented transmissions on, and which addresses to reply to each with.
- Which addresses can be transmitted on, and which addresses to expect replies from for each.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.1.4 ISO-TP FD"][vc_column_text]
The 2016 version of ISO 15765-2 added support for using CAN FD frames underneath ISO-TP. Fortunately for us, this doesn’t change much. You must now specify if you want the frames to be CAN 2.0, CAN FD, or CAN FD with BRS as well as specifying how large you want the individual CAN FD frames to be (you might not want every frame to be 64 byte long).
The other difference is that ISO-TP messages can have a payload of at most 4095 bytes, while ISO-TP FD added new mechanisms that allow for four gigabytes (4294967296 bytes).
…of which the J2534 API can only utilize 28 or 29 extra bytes, for a total of 4124 or 4123 depending on whether we’re using extended addressing. This is because messages are put in a struct with a static size. :/. (Because of this, the Kvaser API doesn’t currently implement that extra machinery.)[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h3" header="2.2 Sequence of Operation"][vc_column_text]
So now that you’re up to date with your favorite protocol, how do you go about setting up the DLL for communication? Well the basic call sequence is:[/vc_column_text][vc_column_text]
- PassThruOpen(): Open a device (Kvaser DLL only has one device).
- PassThruConnect(): Connect a channel on the device, using a particular protocol ID.
- Use the channel however you want
- PassThruDisconnect(): Disconnect the channel
- PassThruClose(): Close the device.
[/vc_column_text][vc_column_text]
The first step is to open a device and the second step is to use that device to connect to a channel. The base J2534-1 2004 only has a single device, but you must still open it in order to connect to a channel. If the DLL implements access to additional channels per J2534-2, you can connect to several channels using the same device, as long as they don’t use the same physical connection.[/vc_column_text][vc_column_text]
As disconnecting the channel and closing the device is not very interesting, those steps will be omitted from now on.
Note that all API calls return a status and if everything is fine that status will be STATUS_NOERROR = 0. Otherwise, call PassThruGetLastError() to get a more detailed description of what went wrong e.g. whether the CAN ID you supplied was too small or large, or if it was the CAN data that was wrong instead of just ERR_INVALID_MSG.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.1 CAN 2.0"][vc_column_text]
Protocol IDs: CAN, CAN_CH1, CAN_CH2…
CAN uses the channel number supplied in registry, CAN_CH1 is CANlib channel 0, CAN_CH2 is CANlib channel 1, etc.[/vc_column_text][vc_column_text]
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the bitrate. In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both.
- Messages can be sent without any setup.
- PassThruStartFilter(), defining which CAN IDs should be listened to and be reported to the user. Before setting a filter, no traffic from the bus can be seen.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.2 CAN FD"][vc_column_text]
Protocol IDs: FD_CAN_CH1, FD_CAN_CH2…
CAN FD cannot use the channel number from registry, the CHx IDs work like with CAN 2.0: FD_CAN_CH1 is CANlib channel 0, FD_CAN_CH2 is CANlib channel 1, etc.
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the arbitration bitrate (only). In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both. Channel is not connected yet.
- PassThruIoctl(), SET_CONFIG: FD_CAN_DATA_PHASE_RATE to desired data bitrate. Channel is now connected to the CAN bus.
- Messages can be sent without any setup.
- PassThruStartFilter(), defining which CAN IDs should be listened to and be reported to the user. Before setting a filter, no traffic from the bus can be seen.
[/vc_column_text][vc_column_text]
Even if you never use bitrate switching, you must specify the data bitrate before the channel will connect to the CAN bus and let you send and receive messages.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.3 ISO-TP"][vc_column_text]
Protocol IDs: ISO15765, ISO15765_CH1, ISO15765_CH2…
Similarly to CAN 2.0, ISO15765 uses the channel number supplied in registry, ISO15765_CH1 is CANlib channel 0, ISO15765_CH2 is CANlib channel 1, etc.
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the bitrate. In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both.
- Non-segmented messages can be sent without any setup.
- PassThruStartFilter(), defining pairs of message addresses. The channel will respond to messages that have the reception address using the transmission address for the FCs. Segmented messages can also be sent on the transmission address, in which case the channel will expect FCs with the reception address. For receiving one-to-many (physically addressed) messages, supply the same address twice (as one-to-many messages never need FCs).
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h4" header="2.2.4 ISO-TP FD"][vc_column_text]
Protocol IDs: FD_ISO15765_CH1, FD_ISO15765_CH2…
Similarly to CAN FD the channel number from registry cannot be used while FD_ISO15765_CH1 is CANlib channel 0, FD_ISO15765_CH2 is CANlib channel 1, etc.
- PassThruOpen()
- PassThruConnect(), selecting CANlib-channel using the protocol ID and giving the bitrate. In the connect flags you must specify whether you want the channel to be able to send frames with 11 or 29 bit CAN IDs, or both. Channel is not connected yet.
- PassThruIoctl(), SET_CONFIG: FD_CAN_DATA_PHASE_RATE to desired data bitrate. Channel is now connected to the CAN bus.
- Non-segmented messages can be sent without any setup.
- PassThruStartFilter(), defining pairs of message addresses. The channel will respond to messages that have the reception address using the transmission address for the FCs. Segmented messages can also be sent on the transmission address, in which case the channel will expect FCs with the reception address. For receiving one-to-many (physically addressed) messages, supply the same address twice (as one-to-many messages never need FCs).
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_separator_raket][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
Definitions
- ISO-TP
The Transport Protocol defined in 15765-2:2011, without the support for CAN FD which was introduced in 15765-2:2016. Sometimes ambiguously called simply ISO 15765-2 or ISO 15765.\
- ISO-TP FD
The Transport Protocol defined in 15765-2:2016 (including the support for CAN FD).
CAN
The Controller Area Network as described in ISO 11898, a blanket term for both CAN 2.0 and CAN FD.
- CAN 2.0
The “classic” CAN with up to eight bytes of data and no support for bit rate switching.
- CAN FD
CAN Flexible Data rate protocol that supports longer data than CAN 2.0 as well as bit rate switching.
- J2534
A family of standards that specify the Pass-Thru device and the Pass-Thru API used to communicate to the device via a J2534 DLL.
- J2534 DLL
The DLL provided by an interface manufacturer, which conforms to the Pass-Thru API.
- Pass-Thru API
The API of all J2534 DLLs, which the vehicle manufacturer can use regardless of which company’s J2534 DLL is actually in use.
- Pass-Thru device
A specific type of device standardized by J2534, which has an accompanying J2534 DLL.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_header_raket header_type="h2" header="More Resources"][vc_column_text]
Kvaser's Overview of SAE J2534[/vc_column_text][/vc_column][/vc_row]
[post_title] => SAE J2534 (Part II): Using the 2004 API
[post_excerpt] => A deeper look at how CAN 2.0 and CAN FD are handled in the SAE J2534:2004 specification. We also take a look at the Transport Protocol (ISO-TP).
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => sae-j2534-using-2004-api-part-2
[to_ping] =>
[pinged] =>
[post_modified] => 2021-11-12 14:14:51
[post_modified_gmt] => 2021-11-12 14:14:51
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.kvaser.com/?post_type=developer_blog&p=32281
[menu_order] => 0
[post_type] => developer_blog
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[comment_count] => 0
[current_comment] => -1
[found_posts] => 469
[max_num_pages] => 47
[max_num_comment_pages] => 0
[is_single] =>
[is_preview] =>
[is_page] =>
[is_archive] =>
[is_date] =>
[is_year] =>
[is_month] =>
[is_day] =>
[is_time] =>
[is_author] =>
[is_category] =>
[is_tag] =>
[is_tax] =>
[is_search] =>
[is_feed] =>
[is_comment_feed] =>
[is_trackback] =>
[is_home] => 1
[is_privacy_policy] =>
[is_404] =>
[is_embed] =>
[is_paged] => 1
[is_admin] =>
[is_attachment] =>
[is_singular] =>
[is_robots] =>
[is_favicon] =>
[is_posts_page] => 1
[is_post_type_archive] =>
[query_vars_hash:WP_Query:private] => abe42653d294437e5cc23b616f931b0d
[query_vars_changed:WP_Query:private] => 1
[thumbnails_cached] =>
[stopwords:WP_Query:private] =>
[compat_fields:WP_Query:private] => Array
(
[0] => query_vars_hash
[1] => query_vars_changed
)
[compat_methods:WP_Query:private] => Array
(
[0] => init_query_flags
[1] => parse_tax_query
)
)
SAE J2534 (Part II): Using the 2004 API
19/05/2021
This Developer Blog is the second of a 3-part series taking a look at SAE J2534. This series introduces SAE… Read More
Read More
SAE J2534 (Part I): An Introduction
04/05/2021
This Developer Blog is the first of a 3-part series taking a look at SAE J2534. This series introduces SAE… Read More
Read More
MathWorks adds CAN FD capability to MATLAB and Simulink
30/04/2021
Kvaser partner MathWorks latest software release of MATLAB® and Simulink®, R2021a, adds CAN FD capability to the Vehicle Network Toolbox™,… Read More
Read More
Kvaser Presents CAN FD at Chinese CiA Technology Day
27/04/2021
This CiA technology day focuses on specific application fields and topics, relevant for the Chinese CAN community. The speakers discuss… Read More
Read More
Webinar: J1939 Intro With Accurate Technologies (ATI)
26/04/2021
Kvaser will be joining Accurate Technologies to host a joint webinar on May 12th, 01:00 PM – 02:00 PM EDT.… Read More
Read More
Visible at a distance: The Kvaser U100’s smart LEDs
22/04/2021
Interface LEDs can be difficult to see at a distance. Kvaser’s engineering team sought to resolve this issue with two… Read More
Read More
Solution with Q-Vision + Kvaser CAN/CAN FD/LIN
04/04/2021
Fast development of intelligent networking technology in China, coupled with the driving forces for vehicle intelligent networking, has led to… Read More
Read More
Specification for J1939 over CAN FD published
01/04/2021
On March 22, 2021, SAE published the SAE J1939-22 document. This document is the latest addition to the J1939 set… Read More
Read More
Kvaser 2021 Product ‘Not For New Design’ (NFND) Announcement
30/03/2021
Kvaser moves products to “Not For New Design” (NFND) status when we receive information that future production will be limited… Read More
Read More
youku