CANopen Analyzer - Easily Log PDO/SDO Data From Machines

Most CANopen nodes do not come with built-in logging or telematics functionality. Rather, the network simply produces/consumes data instantaneously with no "memory" - hence data from CANopen assets is not collected by default.

Yet, with the rise of Industry 4.0, smart factories and Industrial IoT (IIoT), it's not an option to leave the data unharvested - even if you do not yet know how to use it. By starting your data collection today, you establish valuable benchmark data - e.g. for future predictive maintenance use cases.

Fortunately, recording CANopen data is simple. CANopen is a CAN-based protocol, meaning that you can log the data easily using a CAN bus data logger.

Many CANopen assets use the standard D-sub9 (DB9) connector used in our CAN loggers - meaning that you can simply connect a CANedge/CLX000 to start logging data. If a DB9 connector is not available, you can review our list of compatible adapter cables.

Once the device is connected, it'll power on and auto-detect the bit rate to start logging raw CANopen data to the SD card.

As explained in our intro to CANopen, the majority of your CANopen data will be PDOs (Process Data Objects) - i.e. data like torque, position, temperature, pressure etc.

However, you'll also get data on e.g. NMT state changes (initializations, resets, ...), EMCY error messages and SDOs (Service Data Objects) used for configuration changes.

The raw data can be extracted via the CAN logger SD card or auto-pushed via WiFi to your own server.

Once your data is extracted to your PC or server, you'll need to convert it to human-readable form. To do so, you'll need a *.DBC file with the conversion rules (DBC is the standardized conversion rule format for CAN bus data).

In the CANopen context, you'll typically have some of the relevant information in the form of an EDS (Electronic Data Sheet) *.INI file for your devices. This may tell you e.g. how the parameter values are "mapped" into each PDO.

With outset in the EDS (and potentially supplementary technical documentation), you can create a DBC file for your application - see our articles on the CAN DBC format and the J1939 DBC file. Once you have a DBC file with your conversion rules, the log file data can be converted with most CAN bus tools - incl. the open source asammdf GUI/API for use with the CANedge, or the SavvyCAN software for the CLX000.

In most CANopen devices, there will be a standardized DB9 connector matching the CANedge/CLX000 connector as per the CiA standards. However, if this is not the case, you will typically be able to design your own custom adapter as per your needs. You can do this from scratch - or you can take outset in our 'generic adapter' to get started quickly.

Alternatively, you can use a CANcrocodile adapter to read your CAN data directly from the CAN L/H wiring harness - without cutting any wires. This method uses induction and is "listen-only" (i.e. you can't transmit data to the CAN bus with the CLX000 when using a CANcrocodile).

If in doubt whether your application is based on CANopen, we recommend checking with your supplier/technical staff.

Yes - CANopen has a lot of parameters/functionalities that are only available on-request. Here, the transmit feature of our CAN loggers is useful as you can send up to custom periodic/single-shot CAN messages - e.g. polling specific parameter values on regular intervals.

Yes. DeviceNet is another higher-layer protocol based on CAN bus - similar to CANopen. DeviceNet is used within many of the same applications as CANopen (e.g. industrial automation), though it's a closed standard managed by the ODVA.

Basically, like CANopen, you can just connect a CAN logger and record the raw data from any CAN based DeviceNet application - essentially using the CANedge/CLX000 as a DeviceNet data logger.

A frequent scenario is that a CANopen device OEM (original equipment manufacturer) wants to log data from nodes installed at a client site. This is e.g. useful for capturing field data or setting up predictive maintenance services. However, often the challenge will be to collect this data in a non-intrusive manner. Here, the CANedge2 is an ideal solution as it is small, easy to install and low cost. As an OEM, you can install this at a client site and connect the CANedge2 to your client's WLAN WiFi network.

Alternatively, you can use the CANedge3 to upload your data via 3G/4G via your own SIM card. The latter has the advantage that you won't have to bother with potential client firewalls, password changes etc. Setup can be done in a few minutes and you'll then be able to push your CANopen data to your own local/private/cloud server. Data can be sent at a configurable frequency.

This of course scales, allowing you to effectively monitor entire fleets of CANopen devices in the field across multiple clients - providing unique insight into actual operational data.

For more on this, check out our products page or our predictive maintenance article.

CANopen is used across a vast number of applications - below we list some of the typical examples we encounter. Note that these applications may use CANopen, though many other protocols exist.