Common mistakes

This chapter covers what goes wrong on any CanCan, whatever its application. Problems specific to one kind of equipment are in that application's own FAQ.

Read the LED first

The box has one LED and it is worth ten minutes of bus tracing.

The LED	The box is	What to do
blinking once a second	running normally	the fault is elsewhere — bus, settings, or the equipment
flashing very fast (≈25 Hz)	refusing to confirm its own firmware	power-cycle it: the previous firmware comes back. Then check the image — see Loading and updating a firmware
steady on, never blinking	stuck during startup, before it began running	power-cycle it once. If it comes back the same way, note the product ID and software version and report it — it does not fix itself
off, with the box powered	not starting	hardware fault or no firmware — factory programming needed
blinking at some other rate	in an application-specific error	see that application's manual

The box does not appear on the bus at all

Likely cause	How to tell	Fix
It has never been given an instance number	a factory box ships with InstanceNum = 255, which means "not addressed" — it answers a UID scan but publishes nothing	muxen-uds -i can0 uid --scan, then write an instance number
The MUXEN bus is not terminated correctly	60 Ω across a powered-down bus; anything near 120 Ω or 40 Ω is wrong	one 120 Ω at each physical end, nowhere else
No power, or CAN 1 not wired	LED off	check supply and the CAN 1 connector
Wrong side	CAN 1 is the MUXEN bus, CAN 2 the equipment	swap the connectors

A box with no instance number is not broken and does not need reprogramming. It is waiting to be told who it is.

Two boxes fight over the same identity

Two devices with the same function and the same instance number on one bus produce values that jump between two sources, alarms that clear themselves, commands that reach the wrong box. It happens whenever a second gateway is added with the settings of the first, or a spare box is installed without being reconfigured.

muxen-uds -i can0 scan lists what is on the bus. Each function + instance pair must appear once.

Two unconfigured boxes can collide on their own: the watermaker, propulsion-motor and Magic Trim device types default to instance 0 rather than 255, so they publish from the first power-up. Fit and number them one at a time.

Nothing arrives from the equipment (CAN 2)

Likely cause	Fix
Bitrate mismatch	each application fixes the speed its equipment uses; if the equipment is configurable, it must match — see the application manual
Equipment bus not terminated	120 Ω at each end of that segment too
The equipment is off, asleep, or in a mode where it says nothing	power it up and make it do something
Wrong firmware for that equipment	check ProductId against the catalogue in CanCan gateways — Overview

The relays or the inputs do nothing

Symptom	Cause	Fix
the box's own I/O never appears on the bus	EnGenIo is 0 by default — the generic I/O device is off until enabled	set EnGenIo to 1 and give the I/O device an instance number
the analog inputs read 0 mV	the sensor supply is off (EnAnalogPwr = 0) or the sensor is not wired	set EnAnalogPwr to 1, check the sensor
a dry-contact input never activates	it is closed to ground, not to +12 V	rewire; no external pull-up is needed

A setting I changed has no effect

Every parameter on every CanCan takes effect only after a restart. Writing a setting stores it; the box reads its settings once, when it starts, and works from that copy until it is restarted. Nothing rejects the write, nothing warns you, and reading the parameter back shows the new value — the box is simply still running on the old one.

Always write with --reboot:

muxen-uds -i can0 -d <address> writeconfig --name <name> --value <value> --reboot

If you changed several settings without it, one restart at the end applies them all.

After a factory reset, the box has disappeared again

The factory-reset routine restores every parameter to its default. All the pairing, all the calibration, all the application settings are gone. The instance number can be kept or reset depending on how the routine is called — and if it was reset, the box goes back to 255 and stops publishing.

There is no undo. Read the configuration out and keep it before resetting anything:

muxen-uds -i can0 -d <address> readconfig

The firmware update failed

Nothing is damaged. The box is still running the firmware it had before — that is by design, see Loading and updating a firmware. The usual causes, in order: an image for the other hardware generation (5.x versus 6.x), a bus interrupted during the transfer, or the wrong product ID. Check the version and hardware ID of the box, pick the matching image, retry.