Posted on July 31, 2017 at 12:02No 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
