This post is part of my onlone book Linear Actuator Motion Control per CAN Bus.
As part of a customer project, I was asked to develop a hardware system to control a linear actuator, specifically the Thomson Electracâ HD model with SAE J1939 interface. The Electracâ series of actuators supports two higher-layer protocols (HLP) based on Controller Area Network (CAN): CANopen, and SAE J1939. CANopen is suited for industrial automation, while SAE J1939 was designed for diesel engines (trucks, trains, ships, tanks, tractors, and more). You can control the actuators merely with hardware switches (Start, Stop, Forward Motion, Backward Motion), but, in addition, both CAN protocols allow to regulate the linear speed.
At first glance, CANopen appears to be more suitable for controlling a linear actuator in industrial applications, but that is only true when you are already involved with CANopen, i.e., you know how to implement a CANopen protocol stack (which is not a small feat).
However, if your application requires mere motion control (Start, Stop, Forward Motion, Backward Motion, Speed Control), you are better off with SAE J1939 because you don’t need to install the protocol stack. The Electracâ actuator supports some SAE J1939 protocol features (e.g., the address claim procedure), but you can ignore the protocol requirements and control the linear motion with mere CAN Bus data frames (using a 29-Bit message identifier). Thus, “CAN Bus communication” describes the operation mode more accurately.
The CAN/J1939 approach will shorten the development cycle tremendously, which is why I focus on SAE J1939 in this application note and not CANopen.
Initially, I had published a brief post on our website to share some general insights. However, since then, I have been asked by various engineers from all over the world to share the hardware design and the Arduino source code.
It appears there is a demand for extended support, especially since the Electrac’s user manual leaves ample room for interpretation and lacks application examples. Consequently, my application turned into a major research project, which also explains the previously mentioned calls for help.
Don’t get me wrong, the Electrac Linear Actuator is a great product, and it is always rewarding to see the application literally move. Yet, working on this application was at times frustrating. After months of working with this product (time frame, not efforts), I still discovered what I call undocumented “oddities” (See chapter Thomson Actuator – Oddities).
Unfortunately, the support from Thomson I received was at best mediocre. I’ll leave it at that. In view of various undocumented eccentricities, you should not start programming the Electrac per CAN/J1939 without reading this document. The Electrac user manual was primarily created for installation, while this application note provides a valuable source for programmers.
The detected, yet undocumented idiosyncrasies caused profound delays during the development process. When you discover an odd behavior, the initial impulse is to blame the software, but after hours of debugging without result, it became clear that the problems were with the actuator and its firmware, requiring a software workaround.
The following application note reflects the experience I gained during the development process, however, without exposing details of the customized solution. But I will share hardware and software aspects for those interested. This application note is not a complete project, but it comes with sufficient information to start your own application development.
That being said, I would like to emphasize another important aspect: Please understand that I cannot provide help for your specific application beyond this application note. Over the years, I dealt with many newcomers to the CAN Bus technology, some of them motivated by great product ideas. Others were thrown into a project because they were embedded system programmers. What they all had in common was that they were grateful to have found me, and they all wanted to pick my brain or that I solve the problems they encountered. The drawback is, while I happily share my knowledge, remote troubleshooting per phone call or multiple emails is cumbersome (to put it diplomatically) and time-consuming.
My answer was always consistent and sometimes frustrating for the engineer eager to get his hands on an embedded application: You are responsible for your application. You need to grasp your development’s full scope, and that includes a solid understanding of the technology involved. Good engineering requires research, time, and patience, and there are no shortcuts.
Nevertheless, I always keep that aspect in mind when I write, and I try to share as much knowledge as possible.However, it doesn’t make sense to repeat information that is already published, so in such case I do provide hyperlinks in this document to enable further research on details not covered here.
Before You Start That Development…
I added this paragraph to support your decision of whether to use an Electrac Linear Actuator and what parameters to consider making that decision. As you will find throughout this application note, I discovered a few undocumented side effects affecting (and delaying) the development process.
This application note is based on my experience with one particular version of the Electrac Linear Actuator. The assumption is that my findings and the resulting code will work on different types of Thomson actuators that support CAN/J1939 communication.
The first probable step during your development process will be the selection of the actuator based on required linear length and speed. However, there are further parameters that are not that obvious to the newcomer to the technology.
For instance, the commonsense assumption is that you can control a linear actuator in a speed range from zero to maximum supported speed. That, however, is not the case.
According to the Thomson Electrak user manual, the “PWM driver will not provide enough voltage for the motor to operate properly under 20% utilization, therefore 20% should be considered a lower limit for speed control.”
In other words, the minimum speed of the linear actuator is at 20% of the maximum speed. Furthermore, the speed control resolution is at 5%, leaving the user with 16 distinctive speed levels.
However, this does not address the full extent of the limitations involved. There is a second, undocumented speed limit, somewhat higher than the minimum speed, at which the motor can run but cannot start when this speed is applied at motion start.
I call this the “threshold speed,” and it depends on the gear’s condition, i.e., older gears require a higher threshold speed due to mechanical wear (There is a workaround explained in chapter Managing the Threshold Speed).
Furthermore, please be aware that the actuator will never reach either the minimum or maximum position as shown in the data sheet. The actuators I used were specified at 4000 mm stroke length. The real-world numbers were ~20 mm for minimum (null) position and ~3980 mm for maximum position. I recommend selecting a stroke length slightly longer than your requirements unless these tolerances are acceptable.
The most serious issue with the Electrac Linear Actuators is the use of multiple actuators in the same network. If you need total control of two or more actuators and your setup runs on battery (such as a truck or train environment), do notuse the same network but rather control them per individual, galvanically isolated CAN/J1939 ports. As I explain in chapter Multiple Actuators in the Same Network, two or more actuators in the same network will create endless CAN/J1939 data traffic, effectively killing the “sleep” feature and draining the battery.
Also, read my comments on Testing Approach. They contain some valuable information about what aspects are important for the development process.
The point is, before working with a linear actuator, you need to decide to what degree these circumstances impact your application.
Consequently, before starting that development, please take your time to study the user manual and work through this application note.
The Scope of this Application Note
This application note focusses on the Thomson Electracâ HD model with SAE J1939 interface. And while the actuator supports the CAN Bus and SAE J1939 communication protocol, we utilize the mere CAN Bus control to keep things simple and reduce coding efforts.
The control hardware is an Arduino Due ECU development board with CAN Bus interface. However, the “C” code to control the actuator can be used in any other embedded system, even a Windows/Linux PC, with the understanding that these systems will require a CAN Bus interface with adapted driver software (API).
The demo code demonstrates the basic motion control features, such as Start, Stop, Forward Motion, Backward Motion, and Speed Control per potentiometer. To be more precise, I will present two versions, which I tagged “basic” and “extended.” The basic version is fully functional but lacks some features for advanced operations. The extended version adds functionality, such as the detection of minimum and maximum position, and it addresses the actuator’s oddities (and, consequently, my grievances).
This application note does not cover the safe operation of multiple linear actuators. The “basic” sample code offers the operation of two linear actuators but only for demonstration purposes. Neither code sample addresses topics such as speed and position synchronization.
The development environment is the Arduino IDE (Integrated Development Environment).
Further Resources
· Electrak HD Linear Actuator | Thomson (thomsonlinear.com)
· Electrak HD Installation and Operation Manual (thomsonlinear.com)
· Arduino-Based ECU Development Board With Dual CAN Bus Interface (copperhilltech.com)