0
\$\begingroup\$

Please correct me if i'm wrong. The way I understand it, J1939 is based on CAN2.0b and uses 29 bit identifiers. CANOpen is based on CAN2.0a and uses 11 bit identifiers.

If for example, you have a controller that is communicating with various sensors using J1939 but you'd like to add another module on the bus using CANOpen, would they compatible?

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Maybe if you don't ever want the CANOpen and J1939 nodes to talk. \$\endgroup\$
    – Matt Young
    Nov 19, 2019 at 2:30

1 Answer 1

3
\$\begingroup\$

From a general point of view, then no, don't do this. For the following reasons:

  • It will be a real-time nightmare.
  • J1939 and CANopen aren't really compatible. At best, they can be made to tolerate each other at the same bus.
  • CANopen supports both 11 and 29 bit identifiers and you can't rule out identifier collisions.
  • Certain CAN nodes don't distinguish between 11 or 29 bit internally. So if you send 0x1 with 11 bit identifer, it might be treated equivalent to 0x1 with 29 bit identifier.
  • All 29 bit identifiers will have lower bus arbitration priority than their 11 bit equivalents, regardless of how critical they are.

If you are a CAN bus system design veteran (and only then), it is theoretically possible to combine them. It is a really bad idea but it can be done. You will need to create a full list of every CAN identifier that can exist on the bus and you need to have the timing requirements of every single package in mind. You need to perform bus load calculations and consider which messages that are critical.

Also, at least CANopen is flexible enough to accept 8 byte data packages with a custom identifier as PDOs, even though they aren't actually coming from a CANopen node. That's usually how you integrate non-standard/OEM nodes into a CANopen network.

\$\endgroup\$
3
  • \$\begingroup\$ In general, I agree with this answer. I would add exceptions for certain situations. For instance, I once saw an application that used CANOpen for bootloader-oriented tasks that were only to be performed at the factory and not on the live bus. The live bus was J1939. This was a clever method that allowed easy separation of the bootloader communications from the application commmunications. \$\endgroup\$ Nov 19, 2019 at 15:15
  • \$\begingroup\$ @slightlynybbled Interesting, I guess that's one way to get more functionality out of J1939. \$\endgroup\$
    – Lundin
    Nov 19, 2019 at 15:18
  • \$\begingroup\$ Shared media really does suck, all hail to industrial ethernet. \$\endgroup\$
    – crasic
    Nov 19, 2019 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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