Photoresistor and motor

Basic Information:

Printer Model: Custom
MCU / Printerboard: Bigtreetech Manta M8P

Hi all! I have a photoresistor and I want to make sure that the motor does not move in the dark, but moves in the light. Is it possible to implement such an endless check? Is there a demon like in RepRap?

Hello @TheDoshs !

What motor?

I have quietly spinning motors that are attached to the board (axles and extruders) And I want to implement this function with a photoresistor on any of these motors :yum:

So you don’t want any movement on the printer during darkness but keep the heaters on?

The sensor will react to the light from the LED, if it is not there, then the motor movement must be suspended. If the sensor catches the light, then it is necessary to resume the movement of the motor. I don’t use heaters

Could you take some time to explain exactly what you are doing?

People here look at printers with the expectation that they are FDM which means they do have heaters and are expected to work at all times.

Not knowing more of the project like has already been asked.
If I wanted this type of condition, this may be oversimplifying it, but I would simply use a gpio pin, add it as a filament sensor that triggers a special pause macro that saves your current state, and will resume when cleared. If your not using heaters so much the better, not sure why… but If you want to explain further maybe we can be more assistance. have a great day

I need to make the supply of dry cement according to the above-mentioned algorithm, in other words, the printer will print cement

Could you tell me how you would do it through GPIO? :blush:

It turned out to implement this idea using [gcode_button]. Thank you very much!

1 Like

Hello again! Unfortunately, when using [gcode_button], the printer does not stop/resume the extruder during printing, which is responsible for feeding the dry mixture.

[gcode_button my_gcode_button]
pin: PC5
analog_range: 1, 10000
  M117 "lights on"
  M117 "lights off"

A photoresistor is connected to the PC5, when light appears, the extruder “transporter” is synchronized with the main extruder, otherwise it is desynchronized.

By itself, the “Button” works fine, but as soon as printing begins (or the usual sending of G1 commands), it behaves very strangely. The button seems to be unable to execute its code between successive commands G1 … E5, but as soon as the G1 commands are finished, the console is completely clogged with information about the synchronization change.

Sometimes the error “Exception in flush_handler” appeared

Partially your issue might be due to design, partially it might be some currently unknown issue. Refer to Bug found with gcode_button for some background discussion

It’s bad, but is it possible to get around this somehow via GPIO, for example? Write code in Python/C that will listen to what is on its input? :fearful:

Something like Daemon

Unfortunately, I cannot provide more guidance here.
In general, you will always have the challenge that Klipper is always first working down his gcode queue, before reacting to any other input. The only exception is an Emergency Shutdown.
This is what I was referring to with “due to design” in my above post.

Got it, thank you very much!