Appearance
Common mistakes — Bloc 8 power module
Problems that belong to the box rather than to this firmware — it does not appear on the bus at all, a firmware update, a factory reset — are in Common mistakes. What follows is what goes wrong with the outputs, the inputs and the front panel.
Nothing switches at all
| Likely cause | How to tell | Fix |
|---|---|---|
| No instance number yet | every output cell on the panel shows the fault symbol and the header reads #64 | address it — Commissioning §3. The outputs are held off on purpose until then |
| The supply is outside the accepted window | the system LED blinks fast; the panel shows a warning triangle and every cell in fault | measure the supply. The window is VBatMin…VBatMax, in millivolts |
| The module was addressed but not restarted | it publishes nothing on device/1/<n>/life | the address only takes effect at the next start. muxen-uds uid --instance restarts it by itself; a hand-written InstanceNum needs --reboot |
One output does not answer its pad
| Likely cause | Fix |
|---|---|
| You are not on the output page | only the first page maps the pads to the outputs. The arrows walk the pages; come back to the first one |
| A label transfer is in progress | the module hands the whole image to the panel before answering anything else. Wait a second and try again |
| That output tripped | look at it on device/1/<n>/life: short-circuit or not-connected rather than power-off. See below |
| Its equation holds it | an equation that is true keeps a non-latching output on, and a latching output re-triggers on every rising edge. Check EqnOut<n> |
An output comes on and drops straight back off
The module checks each output the moment it switches on. On a short it pulses the output off and on again, many times, and then declares the overcurrent: the symptom is a brief chatter followed by an output that stays off and reports short-circuit.
| Likely cause | Fix |
|---|---|
| A real short, or a load whose inrush the output cannot take | fix the circuit. Nothing on the module's side will make it hold |
MaxCurrentOut<n> set below what the circuit really draws | raise it — within the output's rating — or lengthen AlertDelayOut<n> so a normal inrush is not counted |
A tripped output is re-armed by switching it off: send an off command, or press its pad, and it can be switched on again.
An output reports "not connected"
Open-load detection: the output is on and the current stayed below MinCurrentOut<n> for AlertDelayOut<n>. A blown lamp, a disconnected load — or a minimum set higher than the circuit really draws. It is off by default (MinCurrentOut<n> = 0); set it only where the circuit's normal current is known.
An output commanded from the Brain switches off after 5 seconds
Only on a non-latching output (LatchOut<n> = 0). A command from the bus holds such an output for five seconds and then lets the normal rule take over — it is a hold, not a switch. Either repeat the command, or make the output latching (LatchOut<n> = 1) so one command toggles it for good.
An output stayed on and will not switch off
On a non-latching output, holding its pad for five seconds locks it on deliberately — that is how a pump is run without keeping a finger on the panel. A new press releases it.
Every output went off at once, then came back by itself
That is the low-voltage and high-voltage safety. The supply left the VBatMin…VBatMax window for about a second, every output was forced off, and the module went back to what it was doing when the voltage recovered.
A latching output that was on before the cut comes back on by itself. The safety suspends the outputs, it does not switch them off: nothing on the boat is left in an unexpected state, but nothing waits for a human either. Plan for it on anything that moves.
Everything went off when the boat went into degraded mode
Load shedding. The Brain broadcasts a degraded level, and an output whose DegradedMode<n> is below that level is switched off. When the level drops back, an output is switched back on only if its DefaultSteOut<n> is 1 — otherwise it stays off and waits for a press.
DegradedMode<n> = 0, the default, means the output is never shed.
If the Brain stops publishing altogether the level returns to 0 after five seconds, which brings the shed outputs back under the same rule.
Outputs came back on after a restart
Expected: at every start each output takes its DefaultSteOut<n>, and an output configured to come up on comes up on. StartupDly delays the whole thing if several modules should not all switch on together.
A setting I changed has no effect
The modes, the delays, the trip currents, the dimming range and the equations are read once, at startup. Write with --reboot, or reset the module afterwards. Values that do take effect immediately are few — see Reference — Bloc 8 power module.
One output stopped working, and so did every output after it
Check the dimming range of the last output you configured: an output with Dimmable<n> = 1 and DimmingMiniLvl<n> aboveDimmingDfltLvl<n> is refused at startup, and the outputs declared after it shift down one place — output 5 answers the pad of output 4, output 8 does not answer at all. Put the minimum below the maximum and restart.
Dimming does nothing
| Likely cause | Fix |
|---|---|
Dimmable<n> is 0 | dimming is off by default on every output |
| The output is not latching | dimming only exists on LatchOut<n> = 1 |
| The level sent is outside 1…100 | a level of 0, or above 100, is ignored |
The level is below DimmingMiniLvl<n> | it is clamped there — that is what the minimum is for |
From the panel, a long press on a dimmable output's pad ramps the level up and down between its minimum and its maximum, and releasing freezes it. A short press toggles the output.
The display is blank, or frozen on an old picture
E-paper keeps its last image with no power at all, so a display that never changes is a display that is not being driven:
| Likely cause | How to tell | Fix |
|---|---|---|
| The module is off | the system LED is dark | supply problem — the panel is powered by the module |
| The module is running but the panel is not being talked to | the module publishes normally on the bus, the panel is stuck | the internal link between the two. Check the assembly of the box |
| The module restarted | the panel shows its waiting screen | normal for a few seconds after a start |
A panel that has lost the module shows a POWER OFF page with the output names and no states — it noticed the silence, which means the panel itself is alive.
The names on the panel are wrong or out of date
The images are stored in the panel and are only replaced when they are pushed again. Renaming an output in Raken does not, by itself, repaint the panel: generate the legends and write them (Commissioning §8). A name changed anywhere other than Raken never reaches the panel at all.
A cell reading OUT 3, or a header reading UNCONFIGURED, is a zone that has never been written.
The panel shows one number more than I set
By design: it displays instance numbers counting from 1. MUXEN instance 3 shows #4; an unaddressed module shows #64.
A warning triangle in the header
Any of: the supply outside its window, an equation that would not parse, or the MUXEN bus not working. Which one it is: the fault-code page of the panel, and the module's diagnostic codes on the boat — the list is in Reference — Bloc 8 power module.
No current is published
The per-output current frames are off by default. Turn them on for a session with a command to channel 8, or for good with EnCurrentPeriodic. The total current is in the life frame either way.
The fault-code page is empty
The page exists in the panel's page ring but has no content in the firmware that ships today. The faults are shown by the warning triangle and published on the bus.