2

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.

enter image description here

Improve this question
7
  • How do you propose to get the "data" out of the ECU? It may or may not have that capability to begin with. Unless you are planning to build a data acquisition system, and then tie that to a bus - and then tie that to a "server" that transmits to a cloud. If that's your route, the "bus" question is rather moot. It could be RS-422 or serial USB or any number of protocols that would be plenty fast enough.
    – SteveRacer
    Feb 13, 2018 at 4:36
  • The ECU has 2 free CAN Bus interfaces ( 2 x CAN, 125 kbit/s up to 1 Mbit/s ). I do have some say on how the other side can or should program ( uses CodeSys 2.3 ) the ecu. I tend to lean a bit towards OBD-II cos it is also meant for reporting, telematics(telemetry?) I was thinking of Fault Tolerant CAN (ISO 11898-3) at a speed of about max. 125 KBit/s or something. But then again this is pretty new to me. So every piece of information I gather could prove valuable.
    – R.W
    Feb 13, 2018 at 5:07
  • Btw the device that I am programming ( to push the data on to the cloud ) has a CAN interface (V2.0 A/B) and the necessary GSM/GPRS setup. I have even programmed the system to push some (mock) data to the server. I used a simple simulator to mimic the overall system behavior.
    – R.W
    Feb 13, 2018 at 5:31
  • I'm still not sure how you get the data stream (if there even is one) "out" of the ECU. You'd certainly need to know more about that architecture. Perhaps it's some ready-to-go Bosch item that has such an interface, somewhere. Or maybe it's a proprietary rudimentary bare-bones industrial control that has no such capability, as there was never an anticipation that it would need such a thing. Keep in mind emissions are not relevant.I would speculate that if the compressor has some sort of diagnostic interface, you might get lucky. If not, you're back to your own data acquisition hardware.
    – SteveRacer
    Feb 13, 2018 at 5:45
  • I am adding some information that I received about the ECU. They have been currently programming the ECU using CodeSys 2.3,C/C++. I came across some code samples for doing a CAN Bus comm on those ECUs. So it definitely is 'programmable' for custom purposes, especially so cos it has 2 unused CAN Bus ports waiting to be used. Btw emissions are not an issue at all because this ECU is connected to a sub system that monitors other parameters and not the engine exhaust etc. It is purely an in-house requirement for them and doesn't need to comply with any emission standards. Thanks
    – R.W
    Feb 13, 2018 at 6:51

1 Answer 1

Reset to default
1

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:

Yo send T<CR><LF> to request temperature, and the ecu responds with T<temperatureHighbyte><temperatureLowbyte><CRC-checksum><CR><LF>. 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.

Improve this answer
2
  • Thanks a lot sweber. My initial preference was RS232 ( or RS485 - just in case multiple devices need to be added at some point ) both of which I love! But I've heard that going forward they may want this data acquisition thingy to work with other devices all of which have CAN interfaces. That was the main reason I started looking towards CAN. I was initially thinking of doing RS232 the NMEA style ... talker sentence with the prefix, checksum etc.
    – R.W
    Feb 14, 2018 at 4:19
  • And thanks for the idea on own implementation. Initially I thought about it but thoughts about interoperability, future expansion of the system, the fault tolerance of the CAN Bus etc made me move away from it. But on a second thought it seems to be a good idea to rethink RS232.
    – R.W
    Feb 14, 2018 at 4:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .