Common mistakes

This chapter covers what goes wrong on any BLOC 8 v2. Problems with one particular circuit, one equation or one output setting are in the application manual.

Read the LED first

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

The LED	The box is	What to do
blinking once a second	running, supply in range	the fault is elsewhere — bus, settings, wiring or the load
blinking about five times a second	running, supply out of range — every output is held off	measure the supply at the box; check VBatMin and VBatMax
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

Then read the panel. It carries the same information in words: which outputs are on, which have tripped, whether the supply is out of range, whether the CAN bus is working, and which instance number the bloc thinks it has.

Nothing comes on. Every output is off

Three causes, in the order they are worth checking:

Likely cause	How to tell	Fix
The box has never been given an instance number	every panel cell reads "no address"; the box publishes nothing on the bus	muxen-uds -i can0 uid --scan, then write an instance number — or set it from the panel
The supply is outside the configured window	LED blinking about five times a second; the panel shows supply too high or too low	measure at the box under load; a long thin supply run that sags when the loads come on does this
The Brain has put the boat in a degraded power mode	the outputs the installation marked as sheddable are the ones that went off	that is the energy strategy doing its job — see the application manual

A box with no instance number is not broken and does not need reprogramming. It is waiting to be told who it is, and it deliberately holds every output off until then: several unaddressed blocs on one bus would otherwise all answer to the same commands.

One output does not come on

Symptom	Cause	Fix
the cell shows an output fault straight away	overcurrent: the circuit is shorted, or its trip level is set below what the load actually draws	clear the fault, then fix the circuit or raise MaxCurrentOut<n> to suit the real load
the cell shows an output fault, the load is fine	open load: the box sees less current than MinCurrentOut<n> — a blown bulb, a disconnected wire, or a minimum set for a bigger load	check the circuit; open-load detection is off when the minimum is 0
it comes on and cuts a moment later	the load's inrush lasts longer than the trip delay	raise AlertDelayOut<n>
the cell shows a configuration error	this output's logic could not be read	fix the equation — see the application manual
nothing at all, no fault	it is not being commanded	check the button, the equation, and that the box has an instance number

A tripped output stays tripped. It clears when the output is commanded off and then on again — from the panel button, from the screens, or by the logic. Power-cycling the box does not clear a fault whose cause is still there: it trips again on the next switch-on.

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 not wired	LED off	check supply and the CAN connector

The panel tells you which of these it is: a bloc with no address says so on every cell, while a bloc that is addressed but cut off from the bus raises the CAN bus fault instead — and keeps switching its outputs from its own buttons meanwhile.

Two boxes fight over the same identity

Two devices with the same function and the same instance number on one bus produce circuits that switch on their own, commands that reach the wrong box, and states that jump between two sources. It happens whenever a second bloc 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.

Unaddressed blocs do not collide: they stay parked and silent. Number them one at a time as you fit them.

The panel is blank, or stuck on an old image

Likely cause	Fix
The bloc is not running	check the system LED first; the panel is fed by the bloc and shows nothing new when the bloc is stopped
The link to the panel is broken or unplugged	a bloc that gets no answer from the panel keeps the last values it had and says nothing about it — check the connector
It is just e-paper	the panel redraws slowly; a cell a second or two behind reality is normal
The names were never uploaded	names are pushed once at commissioning — see the application manual

The panel's buttons do nothing

The buttons only reach the outputs once the bloc has an instance number — an unaddressed bloc reads them and ignores them. If the cells read "no address", that is the answer. Otherwise check the same things as for one output that does not come on.

I asked the panel for an instance number and the box restarted

That is how it works. The bloc stores the number and restarts once so the new address takes effect everywhere. It does not restart again: the panel goes on asking, the bloc compares the request with what it already is, and ignores it once they match.

A setting I changed has no effect

The output settings and the equations are read once, when the box starts. Writing one stores it; the box goes on running from the copy it took at startup. 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. Remember that restarting a BLOC 8 drops everything it feeds for a few seconds.

After a factory reset, the box has disappeared again

The factory-reset routine restores every parameter to its default. All the output configuration, all the trip levels, all the equations, all the names 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 "not addressed", holds every output off and stops publishing.

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

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

I cannot tell which box in the locker is which

Ask it to identify itself:

muxen-uds -i can0 -d <address> routine --action 1 --routine 2

The panel of that bloc flashes all eight cells on and off three times. The outputs are not touched.

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 that is not signed for this board, 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.