Skip to main content
connect
connect
Associate II
July 31, 2017
Question

Any reason not to use CAN identifier as node ID?

  • July 31, 2017
  • 2 replies
  • 1835 views
Posted on July 31, 2017 at 02:17

Preamble for the uninitiated:

CAN identifiers are usually associated/related with/to the content of the message rather than as an identification mechanism for a specific participant on the bus.

The question therefore:

In an automation environment with approximately 30 CAN bus nodes, would there be any reason NOT to use the 11-bit identifier as a node ID and set up filter masks on the F0 bxCAN peripheral to pass to FIFO only that node ID with RTR set?

The design features a CAN/ethernet gateway that relays requests from a monitoring system to CAN nodes. The gateway always requests data from a specific node with RTR set and the node always responds without.

If the CAN id is used as a node id, the higher order bytes of the payload can be used for an instruction/request and the lower order bytes for parameters/data.

The parameter/data is always less than 2 bytes all the permutations of varying requests can be done in 2 bytes, so payload length is not an issue.

Any thoughts from the more experienced?

#ethernet #stm32f0 #can
This topic has been closed for replies.

2 replies

Tesla DeLorean
Tesla DeLorean
Guru
July 31, 2017
Posted on July 31, 2017 at 02:55

Seems reasonable enough, is it not working?

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
connect
connectAuthor
Associate II
July 31, 2017
Posted on July 31, 2017 at 02:59

Thanks for your reply Clive.

It currently works absolutely perfectly but thought I'd put it out there for peer review as I'd loathe protocol rework post final implementation.

Jack Peacock
Jack Peacock
Visitor II
July 31, 2017
Posted on July 31, 2017 at 12:02

No reason why you can't make up your own protocol, as long as it doesn't have to be compatible with anything else.  CAN network protocols exist to ensure interoperability with other equipment.  You do lose the ability to work with any diagnostic tools based on a defined network protocol, like a good bus analyzer.

Did you consider how your ID scheme will affect message priority?  CAN uses that 11-bit ID to resolve bus conflicts, which means lower numbered IDs will always have priority over higher numbered node IDs.  How do you ensure a high priority message, for instance an emergency safety notification to shut down a group of nodes, isn't blocked by routine traffic for a lower node?  This is a critical part of the CAN bus, and the reason why there are two receive FIFOs in STM32s, low and high priority messages.

If there is a problem it's most likely to be with the next person who has to maintain your application code.  Any new device added to your CAN network will have to be custom built, and anyone working with your existing code will need some good documentation on your APIs.

As a commercial programmer I'd never take this approach, because in the long run it's too expensive.  For CAN applications I stick to an established protocol (DeviceNet, CANopen, etc.) to ensure the product has a long life and can be maintained by 'the next guy'.

  Jack Peacock

Terms & ConditionsAccessibility statement