Can the light be automatically turned off?

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?

1 Like

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
2 Likes

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 :worried:, 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.

2 Likes

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?

2 Likes

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.

1 Like

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. :slightly_smiling_face:

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.

1 Like

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:

  1. Accept the limitation;
  2. Reject as unsuitable;
  3. Provide feedback and hope for an update;
  4. 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.

1 Like

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.

3 Likes

This method is a very straightforward solution

I tested it, it works!! This way, there’s no need to modify the Gcode every time; the slicing software can add it automatically after slicing.

3 Likes

Indeed that is what I meant by adding it to the machine end g-code and saving the profile.

1 Like