Webinar : CAN Bus Diagnostics – Practical CAN troubleshooting

May 27, 2022 9:48:00 AM / by Grid Connect Team posted in CAN, CAN networks, CANbus, Events, Webinar


Diagnosing CAN bus problems can be challenging. Even so, with a little practice and the right tools you don’t have to be highly technical to perform basic diagnostics on a CAN bus network.



Date : Monday, June 27, 2022

Time : 10:30 AM CT  (8:30 AM PT)

Register Now


This webinar will provide practical examples of troubleshooting a CAN network. It will cover the following topics:


Why You Should Attend

  • Troubleshooting common CAN bus failures
  • Troubleshooting the CAN Protocol using PCAN-USB and PCAN-VIEW
  • Advanced Troubleshooting with a Handheld CAN Bus Diagnostics Unit
  • Question & Answer


Meet the host



Gary Marrs

Solutions Architect
Grid Connect 


Register Now


Read More

Webinar : CAN Bus Data Logging – Your Data, Your Way

May 20, 2022 10:15:00 AM / by Grid Connect Team posted in CAN, CAN networks, CANbus, Events, Webinar


CSS Electronics and Grid Connect invite you to join us for our free webinar where you will learn how CAN Bus data logging can be made easy. 


Gridconnect_RGB-1 css-electronics-logo (1)


View Recording

Logging CAN data and processing the data has never been easier, more flexible and interoperable than it is with the CANedge series of CAN Bus data loggers from CSS Electronics.   Process your data using 100% free and open source software with no monthly fees!   Join CSS Electronics and Grid Connect for this free webinar which will introduce the power and flexibility of CAN data logging your way! This webinar will cover the following topics:


Why You Should Attend

  • The CANedge series - key features & use cases
  • Configuring your CANedge & managing log files - locally and remotely
  • Processing and visualizing your CAN bus data
  • Get your questions answered by experts


Meet the experts

Rick_R_photo Martin_Falch

Rick Rockershousen

Vice President at Grid Connect

Martin Falch

Co-Owner at CSS Electronics


Register Now


Read More

How to Diagnose a Controller Area Network (CAN)

Apr 29, 2022 9:00:00 AM / by Gary Marrs posted in CAN networks, CAN protocol, CANbus, PCAN


In 1991, the Mercedes-Benz W140 was the first production vehicle to feature a CAN (Controller Area Network) based wiring system. By 2008 almost all passenger cars and light trucks sold in the U.S. used CAN bus networks.



 courtesy of CSS Electronics



Before CAN bus gained popularity, vehicle wiring harnesses could contain miles of copper wire which significantly added to the cost and weight of the vehicle. CAN bus was originally designed to minimize copper wiring in automobiles by multiplexing electrical signals over a simple two wire network. By using a high-speed twisted pair cable, the amount of wire necessary to allow sensors, actuators and controllers to communicate was greatly reduced.

When people talk about CAN, there are really 2 main but distinct areas that make up a CAN bus network.

  • The lower-level CAN bus network
  • The CAN Protocol used to pass messages

The lower-level CAN bus

The lower-level CAN bus is a two-wire, half duplex, high-speed network system. The CAN standard defines the lower-level details (the physical layer) of the CAN bus. The physical layer is responsible for bit timing and synchronization, message framing, arbitration, acknowledgement, error detection and signaling, and fault confinement. 1

There are basically 2 versions of the CAN standard that cover the lower layers, CAN 2.0 and CAN FD.

CAN 2.0 was published in 1991. This specification has two parts (Referred to CAN 2.0A and 2.0B);

  • part A is for the standard format with an 11-bit identifier
  • part B is for the extended format with a 29-bit identifier

The CAN FD protocol was released in 2012 and increases the effective data-rate by allowing longer data fields (up to 64 bytes per frame compared to the 8 bytes of CAN 2.0).

Think of the lower layer of CAN bus as bits transmitted at defined speeds on the wire itself.


The CAN Protocols

While the CAN standard defines the physical layer a higher layer protocol is required to manage the communication messages on the CAN bus. The higher layer protocol handles details such as node addresses, flow control, fragmentation of data messages larger than 8-bytes, and establishment of communication among other things. Think of the higher layer protocol as the way the messages (data) are formatted, transmitted and received.

Currently, there are many higher layer protocols for the CAN bus. The most common ones are listed below:

CANopen - Industrial automation
  • IEC 61375-3-3 (use of CANopen in rail vehicles)
  • DeviceNet Industrial automation
  • EnergyBus - battery–charger communication
  • ISOBUS - Agriculture
  • NMEA 2000 - Marine industry
  • SAE J1939 - In-vehicle network for buses and trucks

All of these CAN protocols communicate over the CAN bus.


CAN Bus Diagnostics

Diagnosing CAN bus problems can be challenging. Even so, with a little practice you don’t have to be highly technical to perform basic diagnostics on a CAN bus network. Grid Connect sells a wide variety of tools from Peak Systems to help analyze and troubleshoot CAN networks.


Troubleshooting a CAN Bus network

Here are some of the most common CAN bus failures: 2

  • Device configuration settings
  • Missing termination resistors
  • CAN Hi and CAN Low wired backwards
  • Damaged CAN port due to lightning or welding

It is possible to manually troubleshoot the lower-level CAN bus. This can be done using a little vigilance and a multimeter to test and verify. All modules on a CAN bus network need four things to function properly: power, ground, a CAN data connection, and a proper device configuration.

Here are some simple things to investigate:

  • Check the CAN Device configuration. Make sure the baud rate of the CAN communications is the same as all other devices on the CAN bus.
  • Check the CAN bus termination resistance. A CAN bus has to be terminated on both ends with a 120-ohm resistor to prevent reflections from interfering with the data transmissions. In some cases, the termination resistor may be located inside the CAN device.
    • Turn Power off
    • Measure resistance between CAN Hi and CAN Low. Should be around 60 ohms.

  • Check the CAN bus voltages and ground connection.
    • Disconnect all CAN devices from the CAN bus except for the device being tested.
    • Power on the CAN device to be tested.
    • Measure voltage between CAN HI and Ground. The voltage should be between 2.5 and 3.0Vdc.
    • Measure voltage between CAN LOW and Ground. The voltage should be between 2.5 and 2.0Vdc

  • Check / Verify ground connection
    • Turn Power off
    • With the meter on the lowest resistance scale, measure the ground wire to earth ground. The meter should read less than the minimum 0.1 ohm that most meters can read.

  • CAN Transceiver Resistance Test – you can test the CAN port on a device to see if it is damaged by measuring resistance to ground. Damage from lightning or transients typically causes a short to ground on one or both CAN lines.
    • To test, disconnect the device (under test) from the CAN bus.
    • Make sure power is off to the CAN device under test.
    • Measure resistance from CAN HI to Ground and from CAN LOW to Ground. The result should be Mega ohms or open. If it is lower than this range, the CAN transceiver is probably faulty.

Troubleshooting the CAN Protocol

For troubleshooting the CAN protocol and communication message issues it gets more complicated. There are software and diagnostic tools that range from free software with basic functionality to expensive tools that provide very detailed data and analysis.

To start out, a simple solution is to use a USB to CAN bus adapter to connect to the bus and Windows based software tool to monitor CAN traffic. In this example, we use the Peak System PCAN-USB adapter with their free Windows software for displaying CAN and CAN FD messages (called PCAN-View). 3

pcan usb diag 2


pcan view1


pcan view2


For this example, we use the following equipment and devices.

  • Laptop running PCAN View (free download)
  • PCAN-USB adapter to connect to and monitor a CAN bus network
  • At least one CAN device talking on a CAN bus Network, in this example we used an Arduino board with a CAN-BUS Shield V2 from Seeed Studios. (Recommended that CAN bus be terminated with 120-ohm resistors on each end).

The PCAN-USB plugs into a USB port on the laptop. You need to download and install the USB driver from Peak. 

One minor limitation of this method is that the data rate of the CAN network must be known and the PCAN-USB has to be configured with this information. The Peak PCAN-Diag 2 can be used to determine the data rate on the CAN bus. (see below for an overview of the PCAN-Diag 2)

To start the connection to the CAN bus, click on the link icon in the top left of the window. 

PCAN view 7

This will bring up the configuration page.


PCAN view 4



To set the CAN bus data rate, click on the dropdown box and select the correct bit rate. In this case, we selected 125 kbps.


PCAN view 5

Then select the OK button. You should start to see packets arriving.


PCAN view 6

Here, we are seeing some packets from CAN ID 0x01. With PCAN-View there is quite a lot of functionality that can assist with monitoring and troubleshooting a CAN Bus. Here are some of its monitoring and diagnostic capabilities:

  • Displays all received CAN messages with ID, Data Length, and data bytes in a list.
  • Data messages or Remote Request frames can be transmitted on the CAN bus. These messages can either be transmitted manually, automatically in fixed time intervals, or as answers to received Remote Request frames.
  • Error Frames on the CAN bus are detected and shown.
  • Contains a Tracer (data logger) that can be used to record and store the data communications on a CAN bus.



download full CAN Diagnostics Guide


Handheld CAN Bus Diagnostics Unit

For more powerful trouble shooting there are hand held units that provide a lot more information that is very helpful when diagnosing a problem on the CAN bus. 


PCAN-Diag2_Catalog2011-1 PCAN-MiniDiag FD_Banner PCAN-Diag-FD_Manual-Title
PCAN DIAG 2 - Handheld Diagnostic Tool

MPN :  IPEH-002069-V2

PCAN MiniDIAG FD - Handheld Diagnostic Tool 

MPN : IPEH-003070

PCAN DIAG FD - Handheld Diagnostic Tool for CAN FD Networks

MPN : IPEH-003069


An integrated handheld CAN diagnostics unit can provide a wide range of functions to allow investigation of a CAN bus, such as:

  • Auto detection of the CAN bit rate
  • Bus load measurements displayed by a time diagram, including a switchable display of error frames

Diag screen 1

  • The termination resistance measurement even while the system is running. Also measures Voltage for all pins on the CAN Bus (connected to handheld unit)
  • Receives and displays the CAN messages on the network

Diag screen 2

  • Send / transmit either individual messages or entire sequences of them to the network. In addition, the internal memory card allows tracing and playback of the CAN traffic.
  • The integrated two-channel oscilloscope enables visualization of CAN signals.

Diag screen 3


  • The CAN frames can be decoded from the recorded packets to help detect errors in the frame.

One of the biggest benefits of a handheld tool is that it can analyze the CAN bus network at both the lower-level physical layer as well as the protocol level. This saves time and helps to get to the source of the error quickly.



Download PDF version



Download CAN Diagnostics Guide


  1.   Wikipedia, https://en.wikipedia.org/wiki/CAN_bus#Data_transmission
  2.   CAN BUS Troubleshooting Guide (with Video), Enovation Controls. https://support.enovationcontrols.com/hc/en-us/articles/360038856494-CAN-BUS-Troubleshooting-Guide-with-Video-
  3.   Peak System PCAN-View softwarehttps://www.peak-system.com/PCAN-View.242.0.html?&L=1
  4.   Peak System PCAN-USB module, https://www.gridconnect.com/products/can-usb-adapter-pcan-usb
Read More

PEAK System CEO on future of CAN bus

Oct 25, 2021 9:43:52 PM / by Grid Connect Team posted in CAN FD, CANbus, Classic CAN, Interviews


As a company that specializes in the CAN (Controller Area Network) fieldbus, PEAK-System has a clear view of the CAN horizon. Since the company’s launch in 1999, PEAK has been a leading provider of hardware, software, and services for mobile and industrial communications.

Peak Founder and CEO Uwe Wilhelm shared his thoughts with us on the future of the CAN networking protocol, including his view of classic CAN and CAN-FD.

Spoiler alert: The reports of classic CAN’s death are greatly exaggerated!


Q: What are your thoughts on this industry sampling of CAN market share projections into 2027?


Source: Cognitive Market Research. Request sample or purchase report.


CAN FD is the current choice in the automotive sector. The new CAN-XL will certainly be added as a second, new CAN bus standard, with a different usage approach, and classic CAN is still the standard in automation technology and mechanical engineering, though it's gradually being replaced by CAN-FD.

Whether and when there will also be a change to CAN FD cannot really be foreseen.

With its CANopen FD, the CiA (CAN in Automation) group of international users and manufacturers created a standard years ago that is unfortunately not properly accepted in practice. We hope that this will change in the next 1-2 years. There are currently few certified CANopen FD products to buy and customers mostly use the proven CANopen based on the CAN2.0 protocol for new systems. The classic CAN is hard to think of in electronics development. 

Regardless of the area, the proportion is constantly increasing. Whether in medical technology or in consumer devices such as washing machines or air conditioning systems, simple sensor / actuator connections can be implemented quickly and inexpensively. A huge selection of components can be used, and operating systems such as Linux have included the CAN protocol as an integral part of their distributions for years.


Q. When do you think FD shipments will overtake classic CAN, and are there any advance preparations or considerations?


Classic CAN (2.0a / b) will probably always be justified and will remain with us for many years to come. In some applications, the CAN-FD simply doesn't make sense. If you don't really need the increased transmission rate and the larger user data, the standard CAN remains the right choice. It's robust, easy to implement, and inexpensive. 

Likewise, the classic CAN networks, through the CAN transceivers you use, can also cover very low speeds and also support longer CAN networks where it is not about speed but about robustness and network length.


Q. What are some industrial examples of CAN usage?


Today, CAN is actually used in all technical devices, regardless of the industry. 

  • Agricultural technology
  • Construction machines
  • Robotics of all kinds
  • Medical technology
  • Wind turbines
  • Military vehicles and systems (also known as MilCAN)
  • Planes (CANaerospace)
  • Submarines
  • Satellite systems

You will also find CAN in many niche applications, like the latest planetarium projection systems. We have been working for 15 years with a leading company in this market. 

Of course, the automotive sector is a major user of CAN networking and the most well-known CAN applications are in vehicles—trucks, cars, buses, and trains. The simple network topology and the EMC (ElectroMagnetic Compatibility) safe transmission method are certainly the decisive factors here. 

Likewise, almost every microcontroller family today has derivatives that have integrated one or more CAN buses. There are sensors and actuators from all areas that use CAN, as well as dozens of hardware and software tools for the PC to develop these applications quickly and inexpensively.


Q. Let’s shift to PEAK-System—Can you share any new product development plans or product launches?


PEAK-System is currently finishing the last work on a new product range to offer service tools for marine applications following the National Marine Electronics Association (NMEA) standard. Based on CAN, this standard sets the requirements for a serial data communications network to interconnect marine electronic equipment on vessels, creating the ability to share data, including commands and status, with other compatible equipment over a single channel.

We are also developing solutions under the J1939 open standard for networking and communication in the commercial vehicle sector, focused on the networking of the powertrain. The J1939 protocol, from the Society of Automotive Engineers (SAE), is a set of standards that define how electronic control units (ECUs) communicate via the CAN bus in heavy-duty vehicles.

We hopefully can begin selling the new Diagnostic Tools in the first quarter of 2022.

Q. How would you describe the relationship between PEAK-System and Grid Connect?

Grid Connect Founder Mike Justice and PEAK Founder Uwe Wilhelm

Grid Connect President Mike Justice (left) with PEAK-System CEO Uwe Wilhelm (right)


PEAK-System and Grid Connect have been working very closely together for many years. We still know each other from the days when Grid Connect was still Synergetic.

Mike Justice and I met for the first time in March 1998 at the International Manufacturing Technology Show in Chicago, and from then on we always had contact and worked on joint projects together.

Products such as the DeviceNet Detective (first and second generation), which are based on our diagnostic devices, are, for example, only available exclusively from Grid Connect.

Adam (CEO Adam Justice) and Mike (President and Founder Mike Justice) are two reliable business partners, especially in the current situation with the shortage of materials, where we have experienced the importance of our cooperation.

Q. Any final comments about the changes in the automotive industry and development of self-driving vehicles? Will CAN continue to play a role?


The number of sensors and the resulting amount of data in current vehicles is increasing from year to year. The security-relevant systems require more and more bandwidth to transmit the information required for this system. CAN and especially CAN-FD are certain to play a not insignificant role. Likewise, the new CAN XL standard will certainly be an enrichment to self-driving cars and will continue to support the whole thing with its new features.

IP-based networks are also used, but simply cannot replace the classic CAN here. The simple connection of sensors and actuators is too great an advantage with CAN that an IP network cannot replace. The main reason is the network topology and costs per node.

For more about PEAK-System

Get a fascinating look at PEAK-System in one of the great videos on the company’s YouTube channel, which starts with footage of Mr. Wilhelm driving his vintage Volkswagen in the scenic German countryside. We highly recommend viewing it for a better understanding of PEAK-System products and capabilities.


For more about CAN

The Controller Area Network (CAN) was created in 1983 by Robert Bosch GmbH to provide synchronous communication between processors in automobile systems. While the automotive industry has been a key sector for CAN networking, as the market research above shows, its use has expanded to a variety of industrial and consumer products and processes.

CAN products available from Grid Connect

PEAK-System company website

Development of the CAN bus

About CAN FD

Read More

CAN FD – The Next Big (Fast) Thing

Oct 26, 2015 8:52:30 AM / by Brittney Borowicz posted in arbitration process, automotive, automotive industry, CAN, CAN 2.0, CAN FD, CAN protocol, CANbus, CANopen, Classic CAN, DeviceNet, engines, factory automation, Fast Data, Flexible Data, General, Germany, hardware, in-vehicle communication, internal machine communication, ISO 11898, J1939, PEAK, Peak-System, Products, protocol, software, Technical Support, vehicle, White Papers



The CAN protocol (ISO 11898) has remained relatively unchanged since it was introduced in 1993 as CAN 2.0 A/B. In the last few years, CAN FD (for Flexible Data rate or “Fast Data” as we like to call it) was introduced and is now defined as ISO 11898-1. The CAN FD protocol is backward compatible. Any CAN FD device can understand CAN 2.0 frames (now known as “Classic CAN”). However, the opposite is not true. If a Classic CAN node encounters a CAN FD frame, it will destroy the packet with an error frame.

Classic CAN has been the de facto standard for in-vehicle communication for the automotive industry since the 90s. CAN has also been used as the lower-layer protocol for a number of other “higher-layer” protocols such as CANopen, J1939, DeviceNet and more. This has resulted in the CAN protocol being widely deployed in factory automation, heavy-duty vehicles and engines, and internal machine communication – such as elevators and medical equipment.

The automotive industry is the main driver behind the adaptation of CAN FD. The complexity of software in automobiles has increased over time, and the number of systems that communicate with each other via CAN bus has also increased. Between 1990 and 2000, the number of in-vehicle bus nodes went from about 10 nodes to more than 40 systems. This trend has continued into the 21st century, as in-vehicle communication demands have put further and further strain on vehicle design, causing an ever increasing number of CAN bus networks in the vehicle. Through the adaption of CAN FD, in-vehicle communication architectures will be able to accomplish more with less!

The basic idea of CAN FD is to speed up the bit rate during the “payload” part of a CAN frame. In this way up to 8 times more payload (64 bytes vs. 8 bytes) can be delivered in the same amount of time. So the beginning and end of the frame are transmitted at “Classic CAN” speeds, and the CAN transceivers just flip a switch and speed up for the payload part of the message. When you consider that the rest of the frame is at slower speeds, the overall increase in speed is about 6 times faster. Not all messages need 64 bytes of data of course, so the diagram below shows how a CAN FD message of 8 bits and 64 bytes compare to a Classic CAN frame of 8 bytes.


The question is why didn’t CAN FD just speed up the whole message? Why just the payload? The answer requires a slightly deeper understanding of the CAN protocol. A basic element of the CAN protocol is its arbitration process. When two nodes transmit at the same instant, their messages “collide” and they must both “back-off” and retransmit at different intervals according to priority. Another basic element of the protocol is that nodes on a bus must be reached within a “bit time” during this arbitration. The notion of a “bit time” has implications on the length of the bus – the actual cable, since electrical signals have a finite propagation speed. Therefore, a CAN bus running with 1 Mbit/s has a maximum length of 40 meters by rule of thumb. If CAN FD sped up the whole bus, the higher bit rates would shorten the bus cable to unsuitable lengths.

The automotive industry is readying itself to start initial implementation of CAN FD in its designs for 2016, with vehicles hitting the market with CAN FD hardware the following year. As this industry ramps up and more and more ECU’s (in-vehicle “Electronic Control Units) and sensors and actuators also adapt CAN FD, more companies with ties to automotive (suppliers, service companies, dealers, OEMs, etc.) will need CAN FD-capable interfaces. Luckily, Peak-System from Germany is one of the first companies to introduce a CAN-FD interface, (PCAN-USB-FD), and it has been fully tested to the standard. Additional hardware and software supporting CAN FD are on the way. Grid Connect has Peak’s CAN FD products in stock now – we are ready for the next big (fast) thing!

> Click here to download the complete CAN FD White Paper

Read More

Grid Connect is a World Class Manufacturer

Aug 17, 2015 8:59:54 AM / by Brittney Borowicz posted in 900MHz, BLE, Bluetooth, CANbus, chips, connection, Custom, development, DeviceNet, Ethernet, firmware, General, Grid Connect, hardware, I2C, Illinois, manufacturer, manufacturing, modbus, modbus tcp, modules, Naperville, network, NRE, packaging, private-labeled, PROFIBUS, PROFINET, RS-232, RS-422, RS-485, software, SPI, Wi-Fi, ZigBee, wifi

1 Comment


Grid Connect Inc. is an ISO 9001-certified, world-class quality manufacturer. Our chips, modules and products are used by thousands of companies around the world to provide a network connection to their devices. All of our products are designed, assembled, programmed and tested in Illinois, USA. All final tests, firmware loading and packaging is done at Grid Connect in Naperville, Illinois.

All Grid Connect products can be customized and private-labeled to a specific customer’s requirements. It can be as simple as a software change to increase buffer sizes or as complex as a new hardware and software design. In all cases, Grid Connect will provide your company with a fixed price quotation for the NRE/development work and the production cost for the final product. We are happy to private label your product and ship it to you with the correct labeling and documentation.

Some networking and protocol technologies that Grid Connect specializes in, include:

  • Ethernet
  • Ethernet/IP
  • Wi-Fi
  • Bluetooth
  • ZigBee
  • 900MHz
  • CANbus
  • DeviceNet
  • Modbus
  • Modbus TCP

Grid Connect also specialized in all serial standards, including:

  • RS-232
  • RS-485
  • RS-422
  • SPI
  • I2C

For more specific detailing of the various hardware and software options we provide, call the Grid Connect office at +1 (800) 975-GRID or fill out the form here.

Read More

Candid about our CANbus Solutions

May 4, 2015 3:08:29 PM / by Brittney Borowicz posted in CAN, CAN Adapter, CAN Interface Adapter, CANbus, DeviceNet, DeviceNet Detective, General, Grid Connect, I/O modules, PCAN, PCAN Diag 2, PCAN Hardware, PCAN Software, PCAN USB, Products, troubleshoot



Grid Connect provides deep technical expertise in CANbus solutions. We offer the industry leading PCAN USB Adapter as well as a wide selection of other PCAN products.

CAN Adapters
Whether you are need a CAN interface for USB, RS232, PCI, PC/104, PCI-Express and many more. Grid Connect has the CAN Adapter to meet your needs.

PCAN Software
Own a Peak-System CAN USB or other CAN Interface Adapter (PCI, PC/104, Dongle, etc)? We provide a complete offering of PCAN Software to compliment your PCAN Hardware.

PCAN Explorer 5 is the industry-leading solution for monitoring CANBUS traffic.

Looking to develop software for PCAN Hardware? We have both free and premium PCAN developer software packages.

Interested in a 30 day trial of PCAN Explorer 5? Request a Trial Here!

Diagnostic Tools
Check out our newest diagnostic tool, DeviceNet Detective 2. A must have for any DeviceNet network.

Grid Connect has the CAN Diagnostic Tools to help you troubleshoot your CANBUS issues. We offer the PCAN Diag 2, an invaluable handheld diagnostic tool as well as other hardware and software solutions for investigating your CANbus.

PCAN Cables & Terminators
Need a CAN cable, converter or terminator? Grid Connect keeps all your CAN accessory needs in stock and ready to ship!

PCAN I/O Modules
Grid Connect provides a complete line of CAN I/O Modules to meet your application requirements. These fully programmable I/O modules allow for a wide variety of configuration options for a powerful and cost effective solution.

For more information and to view all CAN products designed to fit your needs, click here or call the Grid Connect office at +1 (630) 245-1445.

Read More

Subscribe to Email Updates

Lists by Topic

see all