Appearance
Common mistakes — Bell Marine gateway
General CanCan problems (LED codes, box invisible on the bus, firmware update) are in Common mistakes. This chapter is what goes wrong with the propulsion side specifically.
Two motors, and both show the same values
The classic one. Every controller the gateway discovers starts at motor instance 0, unlike most MUXEN devices, which start unaddressed and stay silent. Bring up two controllers without numbering the first, and both publish on device/7/0/life; the screens show one motor whose values jump between two machines.
| How to tell | Fix |
|---|---|
values on device/7/0/life alternate between two plausible readings | power one controller, number it (writeconfig --name InstanceNum … --reboot), then power the next — see Commissioning |
The same collision happens with any other motor device already on the boat sitting at instance 0. Check with muxen-uds -i can0 scan before choosing numbers.
A motor appeared that is not a motor
The gateway listens to the whole second bus with no filter and recognises controllers by the shape of their frame identifiers, not by any handshake. Another CANopen device on CAN 2 can be read as a propulsion controller and published as a phantom motor.
Put nothing but the Bell Marine controllers on CAN 2. If a device you cannot account for keeps appearing, that is what is happening.
Nothing at all from the propulsion bus
| Likely cause | How to tell | Fix |
|---|---|---|
| Bitrate mismatch | total silence rather than errors — no motor ever appears | CAN 2 runs at 250 kbit/s, fixed in the firmware. It cannot be changed by a parameter or an overlay. The propulsion bus must be at 250 kbit/s |
| CAN 1 and CAN 2 swapped | the box is also invisible on the MUXEN bus | CAN 1 is the MUXEN bus, CAN 2 the propulsion bus |
| Termination | 60 Ω across a powered-down, correctly terminated CAN 2 | one 120 Ω at each physical end, nowhere else |
| The controller is asleep or in standby | nothing on the bus at all | wake the propulsion system on its own controls first |
The motor shows up, then goes to off with everything at zero
That is the watchdog. The gateway declares a controller off, and zeroes its voltage, current, temperature and speed, after 1.5 seconds without a sign of life from it. A motor that flickers in and out of the screens is a controller whose frames are not arriving reliably — suspect the bus and the termination, not the gateway.
Relay 2 (power limitation) is closed and will not open
Relay 2 is closed by design whenever the gateway has no healthy battery bank to look at, including at power-up before it has seen one. It is a safe-state output, not a fault.
| Likely cause | How to tell | Fix |
|---|---|---|
| the bank is not reporting on the MUXEN bus | nothing on device/5/# | get the batteries publishing first — the gateway is a consumer of that data, not a source |
| the motor is still waiting to be bound | BindToParc reads 254 | the automatic binding needs one valid bus-voltage reading; if the controller never reports one, set the bank by hand |
| the bank genuinely reports overload, low battery or off | the battery device says so | that is the relay doing its job |
Relay 2 never closes, whatever the batteries do
BindToParc has ended up at 255 — standalone, which means "do not watch any bank". That happens automatically when the DC bus voltage the gateway measured matched none of the known bank windows the first time the controller reported. Once written, it stays written.
sh
muxen-uds -i can0 -F 7 -I <n> writeconfig --name BindToParc --value 1 --rebootThe relays do not respond to commands from the boat
They are not supposed to. On this firmware the two relays are driven by the propulsion logic — regeneration request and power limitation — and relay commands sent to the box's generic I/O device are ignored. The relay states published with the I/O are feedback only.
If you need switchable outputs on this box, this is not the firmware for it.
The regeneration request does not stay on
It is held for five seconds after the last request and then released. That is deliberate: if the screens or the Brain stop asking, the contact opens by itself. A screen that wants regeneration held has to repeat the request.
CmdRemoteTimeOut looks like the setting that controls this. It does not: on this firmware the five seconds are fixed and the parameter has no effect.
Drive, throttle and stop commands do nothing
Correct, and it is not a fault. The gateway never transmits on the propulsion bus. Of everything a MUXEN motor device accepts, only the regeneration request is acted on, and it leaves the box as a relay contact. Off, drive, speed-regulator and power-regulator requests are accepted by the bus and discarded — they release relay 1 and nothing more.
The temperature or the current looks wrong
Both come straight from the controller, converted and passed on. The current is published with the sign reversed relative to the controller's own convention, so a discharging motor reads negative. The value published for the shaft speed is always positive, whichever way the shaft turns.
After a factory reset the motors are unnumbered again
Expected. The numbering and the bank binding live only in the gateway, one set per controller, and a reset erases them. Restore from the CSVs saved at commissioning, or renumber controller by controller.