I am relatively new to CAN Bus and been doing some research on a new system we have to develop that monitors a mobile compressor. This compressor is towed behind a truck, or sometimes left at the project site. Being new to CAN Bus, I am trying to figure out which of the CAN standard would best fit the requirement - OBD-II or CANopen? The data from the (mobile) compressor needs to be logged and posted on to the cloud. The mobile compressor has an ECU on board. From my study on the CAN Bus for the last couple of days, I have some understanding of SAE J1939, OBD-II and CANopen. The first specifically for heavy machinery, buses, trucks etc. The OBD-II for mainly automotive applications. And the CANopen for industrial applications. I am still trying to make a choice between OBD-II and CANopen. The data that is collected from the compressor/ecu isn't a lot - it is mainly the temperature, pressure and oil level readings - and probably sent once every few seconds - except for any compressor faults that need to get across faster. Any pointers would be greatly helpful. CAN v2.0 A/B at 125 Kbps or something? I am researching from every possible angle before making a decision and a few words from someone experienced can help a lot. Thanks once again. Pls let me know if there's any more info needed.
To me, you are overthinking this. In general, RS232, CAN and LIN are just the interfaces allowing to transfer bytes between devices, but they do not define how to interpret those bytes. That's where OBD-II, CANopen etc. come into play. Those are standards with quite many specifications, and require lots of knowledge and programming time on both sides. So, implementing them is also a matter of costs. (And I'm not sure if you need licenses to develop CANopen/ODB-II software)
As you wrote, the ECU does not yet have any CAN capabilities, it just has the hardware, and needs to be programmed. And your device also has not yet implemented any CAN functionality.
It is also questionable if you really need CAN, and can't switch to RS232. Yes, it lacks the reliability of differential signal lines, but if your device is placed near the ECU, this does not matter. And it lacks the high data quality due to the built-in checksum, but you can implement your own checksum, and transmit it like regular data. Oh, and RS232 is for just two devices, it's not a bus. But you don't need that feature, do you? One big benefit is that a RS232 interface for a PC costs a few bucks compared do a CAN interface, and you can easily write some software to emulate either your device or the ECU, without dealing with any special libraries.
So, I would implement my own, simple protocol, something like that:
T<CR><LF> to request temperature, and the ecu responds with
You read until the
<CR><LF>, calculate the checksum your self and compare it with the sent one. If they are equal, you received the message correctly, and can thrust the temperature value received.
You will have a working solution this way, before you would even have a first deeper understanding of CANopen and alike.