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 
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? 
It turned out to implement this idea using [gcode_button]. Thank you very much!
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
press_gcode:
M117 "lights on"
SYNC_EXTRUDER_MOTION EXTRUDER=transporter MOTION_QUEUE=extruder
release_gcode:
M117 "lights off"
SYNC_EXTRUDER_MOTION EXTRUDER=transporter MOTION_QUEUE=
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? 
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!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.