The light turns on when I start the print, but it never turns off, I have to do that manually.
Is it supposed to stay on? Could there be an automatic shutoff of the light after a period of time?
I havenât been able to determine the timer so far. Not even after pressing âconfirmâ after printing. This is probably just a firmware error that hopefully will be fixed soon.
Hereâs the solution, but youâll need to modify a config.
Saves the LED state at print start and restores it at print end, so the printer always returns to the lighting state it had before printingâregardless of timelapse, AI detection, or manual control.
Like says: if you have your LED off when you start a print, it will turn on automatically and then turn off again when done. If your LED is always on, it will remain on afterwards.
Add this as an overlay file (if using Paxx firmware) or into your printer.cfg:
[gcode_macro _CAVITY_LED_STATE]
variable_was_on: 0
gcode:
; holds pre-print LED state
[gcode_macro CAVITY_LED_LATCH]
gcode:
; Capture current LED on/off state (binary)
{% set was_on = 0 %}
{% if printer.leds is defined and printer.leds.cavity_led is defined %}
{% if printer.leds.cavity_led.color_data[0] > 0 %}
{% set was_on = 1 %}
{% endif %}
{% endif %}
SET_GCODE_VARIABLE MACRO=_CAVITY_LED_STATE VARIABLE=was_on VALUE={was_on}
[gcode_macro CAVITY_LED_RESTORE]
gcode:
; Restore LED to pre-print state
{% if printer["gcode_macro _CAVITY_LED_STATE"].was_on|int == 1 %}
SET_LED LED=cavity_led WHITE=1
{% else %}
SET_LED LED=cavity_led WHITE=0
{% endif %}
Add this before PRINT_START in your machine profile start G-code:
CAVITY_LED_LATCH
; uncomment below if you always want the light on for prints, otherwise it will be toggled automatically if timelapse and/or AI detection is enabled, or left off if not.
;SET_LED LED=cavity_led WHITE=1
And this to the end G-code after PRINT_END:
CAVITY_LED_RESTORE
Sorry, I do not use Discord.
What is Paxx firmware?
If you searched in the forum you would have found this:
Thank you, I did that after I asked. Which was silly of me. All the github links returns 404, though. So seems to either have been deleted or made private.
paxx12âs GitHub account got suspended 
, heâs working with GitHub to get this resolved.
Until then, he has put up a mirror on GitLab: paxx12-snapmaker-u1 / Snapmaker U1 Extended Firmware · GitLab ⊠but right now, youâd have to build it yourself.
The instructions above can be applied without installing extended custom firmware.
I donât think thatâs stupid of you! Youâre allowed to ask once in a while.
And anyway: Itâs not the buyerâs job to fiddle around with the firmware. Snapmaker should provide a solution for this in the future.
You also donât really know what happens after printingâdoes the U1 go into sleep mode? Should you always turn it off, or how much power does it consume unnecessarily if you donât?
Why would you want the light off? How would you check on the print using the camera?
Because after printing is complete, the light remains on pointlessly until you manually turn it off. This is also inconvenient to use.
When using the camera in the app or slicer, itâs easy to turn the light on and off because the buttons are located in the same place and are easily accessible.
I remember the H2D was the same way when I first got it and BL fixed it with a firmware update, hopefully Snapmaker does the same thing, which Iâm sure they will. 
Me personally, I donât like using 3rd party firmware. Iâm all for open source and modders doing their thing, but its not my thing.
You can connect with home assistance using moonraker and use automation
âShouldâ? I would say âmightâ. Why do you think it is ânot the buyerâs jobâ? If something doesnât do what you want it to out-of-the-box, you have choices:
- Accept the limitation;
- Reject as unsuitable;
- Provide feedback and hope for an update;
- Take control yourself.
Which of these gets you to where you want to be the soonest, or possibly even at all? Bear in mind the manufacturer is not obliged to do anything about it post-sale, unless the item isnât doing something it was specified/advertised as doing.
Granted most of us donât have the skills or the time to delve into firmware, but some do and are willing to share, and often willing to take requests on board. This does not just apply to the U1 â devices which incorporate some kind of processing have been amenable to modification ever since the microcontroller was invented. Sometimes thereâs a safety issue (you really wouldnât want to hack your Tesla), sometimes the manufacturers make it hard to impossible to get in, but when there is no safety issue enlightened manufacturers allow for the community to take it on and run with it. Sometimes the community finds its way in despite the manufacturerâs best efforts to keep them out.
I find that appealing with the U1, and one reason I decided to buy one knowing it is not limited to what Snapmaker get around to doing. Their T&Cs allow for this, just covering themselves by saying they are not liable in the event of a custom hack resulting in damage, which has to be fair enough. My advice is just be a little cautious and let other people take the risk first (they will!), and only adopt customised features once theyâve been proven.
However, the risk is low. The U1 runs on well-known firmware modules, which have their own development communities, and it can be returned to stock firmware if necessary. The chances of something going irreversibly wrong are minimal.
Frankly, 3D printers are nothing if not eminently customisable. They originated on a hackerâs work bench, and are all built on common principles from a common kit of parts. Itâs like Meccano, each individual maker just puts their own slant on it. They mostly all rely on community control firmware (Marlin or Klipper) and community slicers (all forks of Slic3r), and those originated in hobbyist and academic labs.
For âwouldnât it be nice ifâŠâ wishes there is only one way to go. Manufacturers have limited resources, especially if implementing a wish wonât result in more sales (or even if it will). Paxx is doing a great job, and deserves support from the community.
Double edged sword⊠Not saying it will happen butâŠ
âOh you are having a catastrophic problem with your printer?â
âOh you have 3rd party firmware running it?â
âSorry we cannot honor your manufacturer warranty, good day.â
Well dangâŠ
Iâll just wait for a simple fix to a simple problem.
Just sharing here, there is a reddit thread as well on this and that solved the problem for me without relying on 3rd party firmware. You do not need the custom firmware just update the end gcode and add the following and save the profile:
SET_LED LED=cavity_led WHITE=0
However, this will always turn off the led after print finishes, regardless what was the setting at the beginning.
Indeed that is what I meant by adding it to the machine end g-code and saving the profile.
There is a stock preference for exactly this, no custom firmware needed: print_task_config.end_led_turn_off.
The printerâs own PRINT_END macro checks it and turns the cavity light off. From lava/fluidd.cfg on the printer:
{% if printer.print_task_config['end_led_turn_off'] == True %}
SET_LED LED=cavity_led WHITE=0
{% endif %}
Set it once, from Fluiddâs console or from any Moonraker client:
SET_PRINT_PREFERENCES END_LED_TURN_OFF=1
That goes into the printerâs own config file, so it survives a reboot. GET_PRINT_TASK_CONFIG reads the whole block back. The firmware only blocks preference writes mid print for bed levelling, flow calibration, shaper calibration, the timelapse camera and end unload, so this one lands whenever you send it.
Two catches worth knowing before you rely on it. The same LED block exists in CANCEL_PRINT but it is commented out, so a print you cancel leaves the light on: only a normal finish turns it off. And it fires at the end of the job rather than on a timer, so it does not cover âoff after N minutesâ if that is what you were after.
I ran into this while writing a Home Assistant integration for the U1, which surfaces the same preference as a switch: GitHub - zkasuran/u1-companion: Home Assistant integration for the Snapmaker U1, plus a Klippy simulator that runs Snapmaker's own Moonraker fork with no printer attached. · GitHub . Everything above is the printerâs own firmware though, so nothing needs installing to use it.