CANopen Analyzer - Easily Log PDO/SDO Data From Machines
Need a CANopen analyzer for your machine data logging?
The CANopen protocol is used extensively: Industrial robots, production machinery, speciality vehicles, medical equipment and more.
With the rise of Industry 4.0, utilizing your CANopen data is key to staying competitive.
Below we list the top 4 benefits of collecting CANopen data, why the CANedge is an ideal logger - as well as practical use case examples.
Top 4 benefits of collecting CANopen data
Collecting your CANopen data can yield major benefits - below are top 4 benefits based on end user feedback.
Predict & avoid breakdowns
By comparing near real-time data vs. historical patterns you can setup predictive maintenance to identify issues before they result in costly breakdowns
Diagnose rare issues & errors
Adding a blackbox CAN logger to your CANopen assets lets you review historical PDO/SDO data to quickly troubleshoot rare issues. With WiFi, this can also be done remotely
Improve operational performance
Collecting operational CANopen data in your server/cloud enables easy automated reporting, KPI dashboards and performance optimization of assets
Reduce time to market
Machinery OEMs can deploy their assets with a CAN logger to collect valuable field data for R&D. The data can also aid in e.g. warranty disputes and remote support
Want to get input on your CANopen data logging use case? Reach out for free sparring!Contact us
Why is the CANedge a great CANopen logger?
The CANedge2 is a WiFi CAN bus data logger with key benefits for CANopen data logging:
Log data out-the-box. Standalone. Link your vehicle to your server in <2 minutes
Extractable 8-32 GB SD. 2xCAN/LIN. Zero data loss. 50 µs RTC resolution. Edge processing
Only 8 x 5 x 2 CM. 100G. Robust aluminium enclosure. 5 LEDs. Bracket options
Example: Logging the Rakka 3000
In this section we provide a practical use case example for logging CANopen data.
Specifically we look at Rakkatec in Finland, who manufacture autonomous unarmed ground vehicles (UGVs) - incl. the CANopen based Rakka 3000.
To diagnose and resolve a number of development challenges, Rakkatec have used the CL2000 in standalone mode to log data during operation.
Below is a sample of the raw CANopen data recorded. The data log contains both PDOs, SDOs and other CANopen communication protocol objects. For example, PDO 26A contains data for the frontal excavator module.
As evident, the raw data is unreadable - i.e. you won't be able to analyze or plot this data without first "scaling" it.
Here, the DBC file is the ideal format for storing the scaling/conversion rules. This CANopen DBC sample contains the basic PDO mapping (bit positions & length) of various parameters contained in message 26A - see also the picture.
With the simple-to-use CSV format, it's easy to create graphical plots - see e.g. the movement of the frontal excavator boom & scoop in the chart. This type of plot can e.g. be used to identify the cause of sudden movement stops and other unexpected behaviour.
For other application examples, see our use case section.
Further, for CANopen telematics use cases, you can also consider the CANedge2 WiFi CAN logger, which lets you auto-upload your CANopen log files to your own server (self-hosted/cloud) for processing - including visualization via open source telematics dashboards.
See below for additional customer case studies - incl. other CANopen use cases:case studies
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 suppplementary 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 CANvas 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 router - or alternatively, you can power your own 3G/4G cellular router via the 2nd port of the CANedge2. 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.
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.
- Industrial Automation
- Production Machinery
- Packaging Machinery
- Conveyor Belts
- Mobile Cranes
- Garbage Trucks
- Mining Trucks
- Military Vehicles
- Building Automation
- Medical Equipment
- Coffee Machines
Ready to collect your CANopen data?
Get your CANedge today!