CAN Bus
Hints
- Can speed is 500 kHz by default
- Termination
- There must be exactly 2 terminations on the bus
- The termination on the BMS controller can be turned on or off
- The termination on the HVFE can be turned on or off
- The terminations must be on the 2 devices that are at the 2 farthest ends of the bus
No CAN bus communications
Ohmmeter testing
- Power off all the devices on the CAN bus
- Check that there is no short between the 2 CAN bus lines, nor between each line and ground
- If there's a short, disconnect devices until you isolate it
- Measure the resistance across the two CAN lines; it should be 60 Ohm
- If 0 Ohm, the two CAN lines are shorted to each other
- If 40 Ohms, you have 3 termination resistors (you must have exactly 2 resistors)
- If 120 Ohms, you either only have 1 terminator resistor (you must have exactly 2 resistors), or a wire is broken
- If no resistance, either you don't have termination resistors (you must have exactly 2 resistors), or a wire is broken
Voltmeter testing
- Power up all the devices on the CAN bus
- Measure the voltage of the 2 CAN bus lines.
- The voltage should be about 2.5 V to ground, on both lines
- If a line is sitting at 0 V, it is shorted to ground, or there is no connection to it
- If a line is at 4 V or so, a CAN driver on the bus is broken, or various devices on the CAN bus are set for different data rates
- The voltage of the CANH line should be more positive than the voltage on the CANL line (on the order of 100 mV, depending on how much data is on the bus)
- If the other way around, the CAN bus lines are reversed
- If no difference in the voltages, there is no CAN communication, or the 2 lines are shorted to each other
GUI testing
- In the GUI, go to the Test / Terminal tab
- Click on the large text area on the left, and type H 6 5
- This screen shows the number of messages transmitted and the number of transmit errors
- If the number of messages transmitted does not change, the problem is that the BMS is not configured to transmit any messages
It the number of errors is > 0, then there is a mistake on the CAN bus, either in hardware or in configuration (e.g., different CAN speeds)
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:
- By default, both the BMS controller and the HVFE are at 500 kHz.
- Through the CAN bus, running at 500 kHz, change the speed of the HVFE
- Through the RS232 port, change the speed of the BMS controller
- 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:
Restore the BMS controller to the original speed (i.e.: 500 kHz) (instructions)
- Now the CAN bust should operate normally, because both devices are at the same speed
Program the HVFE to the new speed: (instructions)
- Use your computer to place on the CAN bus this message:
- For 125 kHz: ID: 7FFh, 8 data bytes, Data: 12h 34h 56h 78h 9Ah BCh 04h 03h
- For 250 kHz: ID: 7FFh, 8 data bytes, Data: 12h 34h 56h 78h 9Ah BCh 04h 01h
- For 500 kHz: ID: 7FFh, 8 data bytes, Data: 12h 34h 56h 78h 9Ah BCh 04h 00h
Change the BMS controller's CAN speed to the new speed (instructions)
- Cycle the power to the BMS off and on, to restart both the HVFE and the BMS controller
Real world experiences
- We have seen a case in which the BMS controller CAN Buffer was damaged, and driving the CAN Bus with 5 V on one line, and 0 V on the other; we do not know what caused it, but we have 2 theories
- It is possible that is was due to someone shorting one of the bus lines to the 12 V supply
- This is a unit that was flooded and covered in mud for a long period; after it was rescued and cleaned, the BMS controller was sealed in conformal coating, which, rather than protecting it from further damage, may have sealed in the corroding agents, which eventually ate up the chip
CAN data on the bus, but not from the BMS controller
- Check that the CAN messages are not turned off through programming of the controller (by default they are on)
No Standard Messages
The BMS is placing messages on the CAN bus, but not the Standard Messages (by default at address 620h).
- For revs 1.16 to 1.32, this is due to the fact that the BMS is not connected to a battery. The BMS sends message each time it reads data from the battery. But, if there is no battery, it doesn't have data to send, so it never sends any Standard Messages.
- For older and newer revs, standard messages are sent anyway, even though there's no real information in them
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:
- In the GUI do Control-T to open the test tab in the classic menu-driven interface
- Type 6, 5 for the CAN screen.
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.
Troubleshooting
There are two sides to this process:
- Minimize the EMI emissions themselves
- Minimize sensitivity to EMI emissions
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
- Specify if you need a BMS controller only (2CN0000E), a BMS with integral HVFE (2CN0000H), or a set of controller plus remote HVFE (2CN0000E + 2HR0xxxE)
- Specify whether you need a 120 Ohm termination (is separate controller plus remote HVFE, specify which one needs a 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:
- Save the settings to a file in your hard drive, to recover if you make a mistake
- Go to the menu driven interface (use a terminal emulator, or, in the GUI, press Control-T)
- Press H / 6 / 6 to go to the EEPROM utility
- Press 8D to see the CAN Rx timing code (by default it's EF)
- Press Tab
- Enter the new code: FF
- Press Enter
- Reset the unit for changes to take effect (press H / 6/ 7, or cycle the power off and on)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.