0
\$\begingroup\$

My project requires me to make use of a CAN bus, and an electronic dial as a node on the CAN bus. One version of the program I wrote for it worked perfectly, no problems here. I then went back to tweak and add functionality, but then I always seemed to encounter the same problem. Whenever I tried sending data, or commands, the bus would just immediately switch off. I thought it was due to my program changes, but looking through a CAN interface device showed me that it's something to do with the bus chain itself. I know for a fact that it's not due to the dial, since I changed it for another, brand new out of the box, and still shows the same error. It's not the CAN interface device, since it is also used for another aspect of the project. Would anyone have any idea why the bus keeps switching off ?

\$\endgroup\$
3
  • 2
    \$\begingroup\$ Based on what you wrote, you made software changes and now it does not work. That is easy to prove, revert to the previously working software and try if it makes a difference, or if it is something else. \$\endgroup\$
    – Justme
    May 24, 2022 at 20:31
  • \$\begingroup\$ You haven’t mentioned what device you’re using, and if it has any peers on the bus who will acknowledge its messages. Some devices will go bus off when their messages are not acknowledged for a number of messages. \$\endgroup\$
    – Bryan
    May 24, 2022 at 23:02
  • \$\begingroup\$ I thought it was the code as well, but even though I looked back on what I changed (I did the rookie mistake of saving over the working version, so I can't find that back anymore), I know it's not something related to the code, because I sent a single CAN instruction with the CAN interface device to the dial and it still gives me the bus-off status. So it's notthe code, at least not all of it. As for the dial itself, it's a Curtis Instruments 3100R model, and currently it's the only device on the bus being used, since I'm testing it out before it is integrated in the full project. \$\endgroup\$
    – DexTr
    May 25, 2022 at 6:32

2 Answers 2

2
\$\begingroup\$

The CAN node will enter the Bus-Off state when the Transmit Error Counter (TEC) raises above 255. The most common cause of this error condition is when nodes on the same bus are configured with different CAN baud rates.

If the baud rates match, make sure that you have exactly two bus terminators (~124 Ω) installed, one on each end of the bus. Also, check that the bus doesn't have long stubs that would result in a star topology.


When you say "long stubs", what do you mean by that ? Like long wires left open-ended, or just long wires in general ?

I'm quoting the CAN Physical Layer Draft Standard from CAN in Automation: DS 102 Version 2.0

6.3 Physical Medium Specification (Bus line)

The physical medium is a two-wire bus line with common return being terminated at both ends by resistors representing the characteristic impedance of the line. [...] The wiring topology should be as close as possible to a single line structure, in order to minimize reflections. The cable stubs for connection of the bus nodes should be as short as possible, especially at high bit rates. At 1Mbit/s, the length of the cable stubs should not exceed 0.3 m (see ISO 11898). The ground inputs of all transceivers are interconnected. The parameters

  • Specific resistance per length unit
  • Length
  • Current
  • Location of the power supply input

should be chosen in a way, that the difference between the ground potentials of the transceivers does not exceed 2V. If necessary, galvanic isolation has to be applied, to reduce the current through the ground line. In general, it is advantageous to locate the power supply input in the center of the bus line.

\$\endgroup\$
4
  • \$\begingroup\$ When you say "long stubs", what do you mean by that ? Like long wires left open-ended, or just long wires in general ? \$\endgroup\$
    – DexTr
    May 25, 2022 at 6:33
  • \$\begingroup\$ I updated my answer. \$\endgroup\$
    – Velvet
    May 25, 2022 at 8:11
  • \$\begingroup\$ Thing is, it had worked before with the configuration I have right now, so I'm "sure" the cabling and circuit itself isn't at fault. But of course, I'm gradually starting to doubt and question everything. Right now, I'm looking at the signals being sent through an oscilloscope, to see if there's anything suspicious going on. \$\endgroup\$
    – DexTr
    May 25, 2022 at 9:43
  • \$\begingroup\$ An oscilloscope is probably your best bet atm. If you'll keep using CAN, any kind of USB-CAN-Gateway would be a good investment \$\endgroup\$
    – Velvet
    May 25, 2022 at 12:25
1
\$\begingroup\$

So, I looked at signals coming through an oscilloscope, and I found out what my problem was. Somehow, the cables connecting CAN-H and CAN-L had gotten inverted, meaning the CAN interface's CAN-H was connected to the dial's CAN-L, and vice-versa. How this happened, I have no idea, but it works now.

\$\endgroup\$
2
  • \$\begingroup\$ It's a well known effect of not using version control when developing software. If you don't use version control, wires will swap themselves round. Also powersupplies will reset to their highest voltage range, and scope probes will disconnect themselves when you're not looking. If you do use version control this will all still happen, but at least you'll have version control, so you can chase that instead of looking at the scopes :D \$\endgroup\$
    – 2e0byo
    May 27, 2022 at 9:48
  • \$\begingroup\$ @DexTr Thanks for sharing. I don't agree with 2e0byo's attempt at humor, but they got one point right. Using a version control system will help you being confident in your firmware, so you can more quickly focus on the hardware issue. \$\endgroup\$
    – Velvet
    May 27, 2022 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.