Communication standardisation for lift truck control can seem like wishful thinking, but savvy engineers can achieve one common control language for all on board devices from a wide range of devices available from different manufacturers, often from different sources.
Although each individual choice may be a smart solution, the resulting mix of devices potentially install conflicting CAN “languages” and entirely different 29-bit CAN protocols such as SAE J1939.
To complicate issues further, some CAN device manufacturers have implemented slightly different versions of these 11-bit or 29-bit profiles to create their own semi proprietary CAN standards.
Engineers are often frustrated that, having selected their ‘ideal’ set of CAN devices, some of them may not communicate with other CAN devices due to these different CAN implementations. This means the designer has to approach each device manufacturer and ask for some modification to be performed.
But customisation can be expensive – not only are extra fees charged for the modification, but the non-standard part created often commands a higher purchase price, which negatively impacts the new vehicle’s profitability. What’s more, customisation can lead to delays in the development process and being late to market, allowing competing manufacturers to get there first, can be disastrous for any new vehicle launch.
With this in mind, some of the more thoughtful engineers might well complain that having many standards, instead of just one, is not useful at all, and that some disciplined standardisation is seriously lacking. Vehicle designers with a more easy-going nature may recall the old joke: the great thing about standards is that everyone can have their own.
Happily, there is a simple technical solution to the problem of converting different protocols into one common language: just select a VCL-equipped Curtis AC motor controller as the electric traction or hydraulic pump motor controller.
These controllers can be configured to enable a network of CAN devices from different manufacturers - ‘speaking’ different versions of the language – to successfully communicate with each other. Therefore, the Curtis controller acts as an interpreter for devices on the bus, so there is no need for the vehicle developer to request costly modifications from all the other CAN device vendors.
A common language brings all the vehicle designer’s ‘first choice’ devices together on the CANbus, made even more simple by using standard inbuilt (VCL) software to configure the CAN data, all of which can be done without assistance from Curtis – although the company’s customer support engineers are on call for advice and assistance with customisation if preferred.
The vehicle designer can make use of this Curtis VCL in two ways: either rely on the proven VCL functions Curtis has predefined, or quickly and easily write proprietary functions and algorithms. Choosing the latter will differentiate the control system from the competition (and in consequence, the functions of the vehicle), with the goal of creating a marketplace advantage.
A brief application example illustrates the advantages that VCL can offer. One vehicle developer was in the process of designing a special electric fork lift truck for handling long loads. The design required a remote seating position within a rotating cab that would provide the operator with a clear view of un/loading operations, and also face the direction of travel to offer a safe, clear field of vision. Mechanical linkages or hydraulic hoses would be very problematic in such a configuration, hence the need for electronic fly-bywire CAN control of all vehicle functions.
The vehicle developer was very specific that the steering had to simulate the feel of a hydrostatic steering system. This limited the devices for the man-machine interface meaning the developer had to choose a device that only ran a custom version of 29-bit CAN. Hydraulic control and vehicle direction inputs were handled by a dual-axis joystick running a ‘proper’ SAE J1939 CAN protocol.
A Curtis enGage VII colour LCD instrument was chosen to provide battery status and steered wheel position indication, together with comprehensive on-vehicle diagnostics and real-time monitoring of all critical vehicle information and vehicle speed. This product, together with the Curtis Model 1222 EPS AC steering motor controller and two Curtis Model 1236 AC motor controllers (one driving the truck’s electric traction motor, the other the hydraulic pump) ran 11-bit CANopen.
The final selection of control devices meant that three different protocol types had to be matched. The vehicle developer thought that a separate (and expensive) CAN system master module would be required to pull the three protocols into line, and asked for Curtis UK’s customer support engineers for help.
Within an hour of arriving on-site, the Curtis engineer had set the Model 1236 AC traction motor controller as the system CAN Master. The individual ‘mailboxes’ in the Model 1236’s software were configured to handle the 11-bit CANopen, 29-bit J1939 and 29-bit OEM-specific protocols. This configuration, easily implemented in the standard AC motor controller, allowed multiprotocol data to flow seamlessly across the network while maintaining the minimal two-wire twisted-pair CAN cabling.
The mailbox data format that adjusts the system to individual needs is fully flexible and may be configured for the transmission of 8-, 16- or 32-bit data by adding the +UseHB (Use High Byte) function. In this way, 16- bit data words sent across the CANbus as two 8-bit bytes are automatically combined back into a 16-bit word by the mailbox. Importantly, the use of the Curtis Model 1236 AC traction controller as the CAN Master completely eliminated the need to add an additional ‘vehicle manager’ device.
This functionality was effectively embedded in the traction motor controller’s VCL software, an approach that ultimately provided the vehicle developer with a considerable reduction in system cost and complexity.
Flexible and reliable VCL is just one of several interesting functions that characterise the Curtis AC motor controllers. They utilise an advanced indirect field orientation (IFO) vector control algorithm that provides the maximum possible torque and efficiency across all loads and all speeds and the comprehensive logic I/O allocation is enough to handle the requirements of almost any application or operator command/control MMI devices, regardless of the communication standards they use.
Controllers such as the Curtis 1236 can be employed as master or slave modules; models such as the Curtis 1222 may be included in the control system as slave. In this way the designer is able to build a complete control system that includes all necessary functions like driving, steering and lifting.
As SAE J1939, the spoken “language” of combustion engines and transmission components, they and both electric and hydraulic drives can be included in the vehicle control system as well, making adaptation for vehicles with hybrid drives easy too. This highly flexible methodology allows lower-cost, standard components to be used, and eliminates the considerable risk and expense of a project being delayed by different CAN device vendors all modifying their products at the same time in an attempt to make them talk to each other!
In summary, Curtis Low voltage AC Induction and PMAC motor controllers give vehicle designers an easy opportunity to use new vehicle configurations, or fully optimise the energy efficiency of their vehicle, at the same time as reducing the overall complexity of their control systems. VCL presents endless options to create a virtual system controller by integrating all control devices for hydraulic and electric drives and man-machine interfaces into one system that accommodates differing CAN protocols, even IC engines or transmissions can be included.
Engineers can explore the benefits of easily implemented custom functionality, safe in the knowledge that expert Curtis customer support engineers are ready and waiting to help out if required.