Troubleshooting

Symptoms first, in rough order of how often they come up.

Firmware updates

I copied the firmware to the SD card and nothing happened.

The mainboard file must be named exactly monitor.bin, all lowercase, with no version number. The card is read using short (8.3) filenames, so anything longer cannot even be opened. Check for a hidden .bin.txt extension too. See MainBoard Updates.

I get the failure page.

The image was rejected before anything was erased, so your enclosure is fine. Copy the file to the card again. An incomplete copy is the usual cause.

It shows the failure page on every boot.

A failed update leaves monitor.bin on the card on purpose, so a one-off bad read retries by itself. The downside is that a genuinely corrupt file then fails forever. Remove or replace the file.

The failure page appears with no card in at all.

There is no valid application in flash. Update from a card with a good monitor.bin on it.

The card is not detected.

FAT32 only. exFAT is not supported, which catches out cards larger than 32 GB.

I updated the screen and nothing changed.

The screen and the mainboard take different files into different slots. firmware.tft goes into the screen’s slot and monitor.bin into the mainboard’s. Putting the right file in the wrong slot does nothing.

Note that the screen takes a .tft file, not a .bin. If you have a firmware.bin for the screen it is from an older download and is the wrong format.

Settings

I edited data.clu and nothing changed.

You did not raise configRevision. This is by far the most common cause. Raise it, power cycle, and it applies. See Configuration.

I inserted the card while it was running and nothing happened.

Both .clu files are read once, at boot. Power cycle with the card already in.

My value did not take and it shows something else.

Values are clamped to their allowed range rather than rejected, so maxTemp = 200 gives you 80. Check the range in the file’s comments.

Some lines applied and some did not.

Bad lines are skipped individually. Check the spelling of the ones that did not, since names are case sensitive.

Nothing in the file applied at all.

Either there is no configRevision line, or the revision is not higher than the last one applied.

My settings reset after a firmware update.

Settings live in the mainboard’s memory and normally survive updates, but a firmware update can reset the tuning values to their defaults. Leaving data.clu on the card means it re-applies itself on the next boot, which is why keeping the card in permanently is the recommended setup.

Filament and load cells

A spool appears in the list but I cannot select it.

An old firmware bug where the imported count was not saved. Update the mainboard firmware.

My filament.clu edit did nothing.

Either filamentRevision was not raised above the number the enclosure had already applied, or there is no filamentRevision line, in which case the file is ignored completely. Both .clu files are read only at boot, so power cycle after editing.

The spool name is cut off.

15 characters maximum.

The weight is wrong or zero.

Check for a comma in the name. The comma is what separates the name from the weight.

The weight reads negative.

Expected with nothing on the holder. It is the negative of the selected spool’s tare weight. See Calibration.

Everything reads -404.

That is the sentinel value for “not measured”. The load cells are disabled in the configuration, or not detected.

Calibration froze.

Wait out the five second countdown first. If it stays frozen much longer, a load cell is probably disconnected.

Servos and the flap

The flap does not fully close, or strains against its stop.

Adjust servoCloseAngle and servoOpenAngle in data.clu, a degree or two at a time.

The servos went quiet after moving.

That is correct. They are powered down after each move, which is why they do not buzz or draw current while sitting still.

The flap sags after a while.

Raise servoHoldMs, though the real fix is usually mechanical. If the flap needs continuous holding torque, something is binding or unbalanced.

Only one servo moves.

Both run from a single control signal in parallel, so a signal problem stops both. One moving alone points to a power or wiring fault on the other, not a firmware issue.

The flap opens on its own.

Overheating. Above maxTemp the flap forces open and every fan runs at 100%. See Safety Systems.

Alarms

It alarms every time I switch it on.

You set opticalAlarmEnable = 1 in data.clu without having an optical sensor fitted. None is supplied with any kit, and the input floats high and reads as permanent smoke when nothing is connected. Set it back to 0.

Note that no preset in the setup wizard can cause this. The alarm ignores the optical input unless opticalAlarmEnable is 1, and you have to set that yourself.

The Sensors page says “Smoke” but nothing happens.

You turned the optical sensor on in Custom without one fitted, so the readout shows the floating input. The alarm is unaffected, because it is gated separately by opticalAlarmEnable, which is 0 by default. Re-run the setup wizard and leave the optical sensor off.

Temperature readings look frozen.

Older firmware only read the BME680 while the Home or Sensors page was open, so the reading stuck when you navigated away, and the overheat protection could miss a rising temperature. Update the mainboard firmware.

It alarms during normal printing.

Raise the thresholds, but pick them from evidence. Watch the raw readings on the Sensors page during a normal print, or log a print and read the LPG and Smoke columns, then leave clear headroom above what you actually see.

I muted the alarm but the fans stayed off.

That is by design. Mute silences the buzzer only, and the alarm LED toggle turns off the red lighting only. Neither re-enables the fans or reopens the flap. See Safety Systems.

No alarm for the first few minutes.

There is a 10 minute warm-up, because gas sensors read wildly while their heaters come up. You can adjust it with smokeBeginTime, up to a 15 minute maximum.

Fans and air quality

Auto mode never reaches full speed.

Lower autoFilterImpMax and autoFilterP03Max.

Auto mode is too twitchy.

Raise autoFilterImpMin and autoFilterP03Min.

The filter fan jumps straight from off to 20%.

Expected. The automatic ramp starts at 20%, so there is a step at the threshold rather than a creep up from zero.

PM10 is high but the fan does not react.

Only PM2.5 and PM0.3 drive the automatic ramp. PM1 and PM10 are measured and logged but do not affect fan speed.

Fans suddenly went to 100%.

Overheating. See Safety Systems.

The extra fan runs at the wrong speed.

It is on and off from the screen, and the speed comes from extraFanSpeed in data.clu.

Display and logging

The screen never goes fully dark.

minBrightness is a floor, not an offset. The slider still reads 0 to 100, but anything below this value is treated as this value. The default is 15.

The replace-filter icon will not go away.

Reset the usage counter on the Settings page. Nothing clears it automatically. See Filter Replacement.

No log.csv on the card.

Logging is off, or there was no card at the time. There is no buffer, so nothing is written retroactively.

The minute counter jumps backwards in the log.

That is normal. The log appends across power cycles and MinSinceBoot resets each time. Use BootID to tell sessions apart.

Usage hours look low.

The counter measures filter fan runtime, not powered-on time. It is also saved every 15 minutes, so pulling the plug can lose up to 15 minutes.

Still stuck

Open an issue on the Clura Enclosure repository . Include your firmware version, your data.clu, and if the problem is intermittent, a chunk of log.csv covering when it happened. That last one saves a lot of guessing.