Machine builders searching for CANopen joystick integration are usually past the brochure stage. The stick is selected — often a Trunsin ZS40 with CANopen output — and the real work is object dictionary alignment: EDS handoff, PDO mapping, deadband at commissioning, and node IDs that do not collide with the display or I/O gateway.
This guide explains those integration steps in plain language for OEM controls engineers and retrofit integrators. It complements our CANbus industrial joystick ECU integration overview and CAN bus joystick wiring termination checklist — here the focus is CANopen-specific commissioning, not physical-layer basics.
CANopen joystick integration: what the ECU team needs first
“Plug-and-play” CANopen joysticks still require your PLC or mobile ECU to import the device description and map process data. Before first power-on, request these deliverables from the joystick supplier:
| Deliverable | Why it matters |
|---|---|
| EDS / electronic data sheet | Defines object index, sub-index, data type, and default PDO layout |
| Default node ID and baud rate | Must match network configuration tool |
| PDO map (TPDO/RPDO) | Which bytes carry axis position, buttons, and status |
| SDO commissioning parameters | Deadband, scaling, inversion, safety switch polarity |
| Configurator PDF | Locked build code for replacement sticks with identical mapping |
Trunsin ships ZS40 CANopen builds with documented object entries and a configurator PDF that travels with the harness drawing — not a generic catalog node ID that changes between firmware revisions without notice.
EDS file handoff and object dictionary alignment
The EDS file is the contract between joystick firmware and your master stack. Import it into CODESYS, EPEC, or your in-house CANopen configurator before wiring the cab.
Common integration mistakes:
- Importing an EDS revision that does not match shipped firmware — PDO lengths differ silently.
- Assuming axis 1 in the EDS equals “boom up” on your machine — function mapping is application software, not the stick alone.
- Skipping NMT state checks — joystick TPDOs may not transmit until the master leaves pre-operational.
[Source: CiA 301] defines the CANopen application layer conventions your master and slave must share. Trunsin documents CiA-compliant profiles on released ZS40 builds; custom PDO layouts are quoted as engineering change orders with updated EDS.
PDO mapping vs your ECU object dictionary
Process Data Objects carry real-time joystick position and digital inputs. Your ECU either consumes the joystick’s default TPDO map or re-maps via SDO before operational state.
| Integration path | Best for | Trade-off |
|---|---|---|
| Default PDO (supplier map) | Fast bench bring-up | May not match legacy ECU byte layout |
| SDO remap at commissioning | Retrofit onto existing object dictionary | Requires documented tool and backup |
| Gateway / I/O module | Mixed-vendor networks | Extra latency and another failure point |
If you are comparing bus output with analog sticks, read Hall effect vs potentiometer joystick drift — CANopen does not remove calibration; it moves it into SDO parameters.
Deadband and calibration at commissioning
Field forums on Cat and Deere replacements often blame “centering error” when the real issue is deadband not applied after stick swap. CANopen joysticks expose neutral zone and scaling through SDO writes or supplier configuration tools.
Commissioning sequence Trunsin recommends:
- Verify termination and node ID — see CAN bus joystick wiring.
- Import EDS; confirm heartbeat and EMCY objects respond.
- Set deadband so neutral TPDO values sit inside ECU null zone — [Source: EPEC S_Joystick function block documentation] treats deadband as mandatory for hand-operated inputs.
- Functional sweep with data log — compare commanded vs actual hydraulic motion.
- Archive configurator PDF + SDO export with machine serial.
Node ID conflicts and replacement discipline
Replacing a failed stick with a factory-default node ID while the network already hosts a display or second joystick at the same address produces symptoms that look like random “joystick fault” messages. Always match the released configuration of the failed unit, not the catalog default.
For construction fleet context, see CANbus joystick applications on construction equipment — integration discipline is the same whether the machine is greenfield or retrofit.
How we validate CANopen joystick integration builds
- EDS revision lock — firmware tag matches EDS filename on traveler
- PDO loopback bench test — master reads expected TPDO length and endianness
- Deadband sign-off — neutral values documented on first-article report
- Replacement parity — identical node ID and map for spare sticks from same configurator build
- Field log template — heartbeat, EMCY, and TPDO snapshot checklist for service teams
Frequently asked questions
Does Trunsin ZS40 support both CANopen and J1939?
ZS40 is offered with CANopen and J1939 output options — specify bus type in the configurator. Do not assume frames are interchangeable without gateway translation.
Can we change PDO mapping after shipment?
Yes via SDO if the firmware profile allows it — document changes and update the EDS archive for spare parts. Major map changes may require factory re-flash.
What baud rate should we use?
250 kbit/s is common on mobile J1939 segments; 500 kbit/s appears on shorter CANopen machine buses. Every node on the segment must match [Source: CiA 301].
Is an EDS enough without the configurator PDF?
No — the EDS describes objects; the PDF locks grip, axis count, connector, and build code for identical replacements. Store both in your asset management system.
Related resources
- CANbus industrial joystick ECU integration
- CAN bus joystick wiring: termination and J1939
- ZS40 product page
- Online configurator — ZS40
Start a CANopen integration review
- Export your ECU object dictionary or master tool project
- Configure ZS40 with axis, grip, and CANopen options
- Email PDF + EDS request to sales@trunsin.com