1. CAN Bus
    1. Hints
    2. No CAN bus communications
      1. Ohmmeter testing
      2. Voltmeter testing
      3. GUI testing
      4. Controller with HVFE
      5. Real world experiences
    3. CAN data on the bus, but not from the BMS controller
      1. No Standard Messages
    4. CAN bus fails in the presence of noise
      1. CAN bus error counters
      2. Troubleshooting
        1. Minimize EMI emissions
        2. Minimize EMI sensitivity
          1. Modify hardware
          2. Modify CAN bus receive timing
    5. Overlapped messages when using multiple masters on the same bus
    6. Errors with HD masters


No CAN bus communications

Ohmmeter testing

Voltmeter testing

GUI testing

Controller with HVFE

The 2CNxxxxH ( Controller with HVFE) includes two CAN devices in one box, each of which is programmed to 500 kHz at the factory.

Should you need to operate at a different CAN bus speed, you must change the speed of both CAN devices.

Please note that, to change the CAN speed for the BMS controller and for the HVFE, the order is important:

  1. By default, both the BMS controller and the HVFE are at 500 kHz.
  2. Through the CAN bus, running at 500 kHz, change the speed of the HVFE
  3. Through the RS232 port, change the speed of the BMS controller
  4. Cycle the power off and on

If you change the CAN speed of the BMS controller, but not of the HVFE, the CAN bus will be locked (CANL will measure 2 V with respect to ground, and CANH will measure 3 V).

To correct the problem:

Real world experiences

CAN data on the bus, but not from the BMS controller

No Standard Messages

The BMS is placing messages on the CAN bus, but not the Standard Messages (by default at address 620h).

CAN bus fails in the presence of noise

The CAN bus is excellent for noisy environments, because it is balanced, and therefor has a high rejection of common mode noise.

However, this common mode rejection is effective only if the noise remains within the range of 0 to 5 V (the power supply rails of the BMS transmitter and receiver). Beyond it, messages are lost ("Error frames") and, in the worst case, the CAN bus quits ("Bus heavy").

Such situations are rare, as they only occur in cases when inexperienced users install components haphazardly with little regard to EMI considerations, or inexperienced manufacturers sell devices that are strong sources of EMI, with little regard to how that will affect nearby devices and even their own CAN port.

It is far easier to design products with a keen respect to the design guidelines that result in minimal EMI emissions, than it is to go back after the fact and try to fix such problems. In a well designed system, using well designed devices, the CAN bus will operate reliably, and there is no need for any extra measures to improve CAN communications.

CAN bus error counters

A helpful tool is the CAN screen on the classic interface of the Pro:

There you can see the CAN error counters (receive and transmit). By looking at the error counters, you can detect which device is is forcing noise onto the CAN bus: turn on devices one at a time and see which one starts the errors. Likely candidates are a motor driver (controller or inverter), a charger a grid-tied inverter and a DC-DC converter.

That screen also helps you measure quantitatively the effect of your noise mitigation measures.


There are two sides to this process:

Minimize EMI emissions

Discussion of ways to design and build systems with reduced EMI emissions is the subject of various publications, and is beyond the scope of this troubleshooting guide.

Minimize EMI sensitivity

Use of twisted wires is mandatory, regardless.

Additional ways to reduce the sensitivity of EMI on a CAN bus include:

Modify hardware

You can request form us a BMS controller that is specially modified for you, with an integral CAN filter and a split termination

Modify CAN bus receive timing

You can try to modify the CAN receive timing parameters (available only with BMS controller software 2.xx and HVFE software 1.08).

See the CAN Rx Timing page.

Overlapped messages when using multiple masters on the same bus

When using multiple BMS masters on the same CAN bus, each must be configured to transmit on a different set of IDs.

E.g.: instead of all transmitting standard messages at 0x620 and up, one can be set for 0x630, one for 0x640, etc.

That way, the messages do not interfere with each other.

Still, because all the units are exactly identical, if all are powered up simultaneously, they all will transmit simultaneously (albeit at different IDs). That will result in the messages from the BMS master with the highest IDs being trampled by the BMS master with the lowest ID. The BMS masters whose message was trampled will wait a bit and try again; soon, all BMS masters will be able to send their messages. This is perfectly normal, and the CAN bus protocol is designed to handle that gracefully.

If you monitor the CAN bus with a high quality CAN bus analyzer, it will report this effect as errors, yet they are not faults, because they are a perfectly normal event that the inventors of the CAN bus protocol envisioned and accounted for.

Errors with HD masters

It is possible that HD masters, under specific conditions (500 kbps, presence of simultaneous other messages, particular lengths of the CAN bus, and colder temperatures) may not hear their own messages and repeat them a few times until they hear them.

This is not unusual in a CAN bus, and in it by itself is not a significant concern.

Yet, if you monitor the CAN bus with a high quality CAN bus analyzer, or with the BMS's own "Test" screen ("H", "6", "5"), you will see these errors. If that is a concern, you can change the receive timing of the affected HD master as follows: