Hey, i tried to get a part of my old system started again.- This means my printserver octoprint.
I have a nice remote interface, notifications, spaghettidetective and a camera.
Unfortunately the printer makes no “runout-routine” if it is printing from octorpint.
Even no message through the terminal.- if i point out the status manually it is detected right (M119 or M412)
Maybe someone of the crowd knows:
Is there a way to let the pi listen to the runout sensor of the sm2 controller?
I want to use “TheSpaghettiDetective” again, to prevent spaghetti-prints.- I have a early premium by beta testing.- Alternatively it would be nice to have a spaghetti detective plugin+camera on the sm2.
Is there a way to execute the filament change routine also by running a other printserver than the touchscreen? @Edwin@JKC20@Alan
Hi xchrisd,
Sorry for the reply late, this is Alan from Snapmaker.
We haven’t implement the “filament runout recovery” function with G-code, it’s interact with touchscreen for now. Although the “M119” command will return the “filament status”, I think it’s not a final solution for Octopi to listen the filament sensor status.
The firmware only notify touchscreen when detecting filament runout. As mentioned above, we haven’t implement this feature via G-code, so it’s not available for other printserver for now. Sorry for the inconvenience.
I agree it’s nice to have such a plugin/solution for the printserver like Octoprint. Maybe we will consider for it in the future. Thanks for the suggests.
If your savy with adding functions to your RaspberryPi and to octoprint (dont know if it can interact with GPIO or other messages) the SN is reporting the filament runout on the CANbus. If Octorpint can read GPIOs, use python to listen on the CAN and then set a GPIO (High) which is bridged over to the GPIO octoprint is listening for? Didnt use Octoprint yet, was planing on using it though at some point.
That would be an easy change - just add a serial echo when the runout switch changes, and then add a watch for that in octoprint. I can add that to my bugfix fork, but someone would still have to write the octoprint plugin. If someone wants to work on that, let me know.
It’s really going to be dependent on the firmware that the printer is using. If the filament runout sends an action command back to connected clients (like octoprint) that a pause has been done, then yes, OctoPrint will actually pause as long as the bundled Action Command Prompt Support plugin is not disabled.
Basically the printer has to send a command back to octoprint that tells it to pause streaming, but it probably needs to pause by itself.
As of the latest Marlin bugfix-1.1.x version, the command M118 can be used to echo output to serial, meaning that M118 //action:dostuff would cause this plugin to try to handle the dostuff command when //action:dostuff was echoed back on the serial console.
A future application of the plugin would be to add actions in the RepRap machine’s firmware so that hosts could respond. For example, when Marlin is killed because something is wrong it would echo //action:poweroff and the attached OctoPrint instance could use this action command to trigger the printer’s power outlet to switch off.
From the octoprint action commands plugin:
OctoPrint will, by default, respond to three action commands: action:disconnect (disconnects the printer), action:pause (pauses streaming the print job), and action:resume (resumes streaming the print job).
so you would want something like M118 //action:pause, but that would only stop streaming. The printer would remain in place. I don’t know if it’s possible to add additional steps to octoprint so it, say, raises the print head after pausing.
There’s discussion on Github about remapping M600 filament change to the filament runout sensor function, which would trigger the resume button on the touchscreen too. That would be a good solution, hope that gets implemented soon.
An option is to connect the sensor directly to the gpios of the raspi, and let him do the work!
There are addons for octoprint to do the job.
But anyway i will will get thumbs up for adding those features to the firmware.
Could the Snapmaker 2.0 output the following when it detects the filament has run out “echo:busy: paused for user” then the plugin called “OctoPrint-PauseForUserEvent” could be used to detect that user intervention is required.
If you connect directly from Luban using the cable and press play to run a print when you run out of filament it does not detect it and keeps printing in mid air, same as the Pi.
It appears this feature is in the touch screen software and therefore does not work when the file is not being sent by the touch screen, this feature needs to be moved from the touch screen software to the main controller software.
these features are done via the controller itself.
im not sure how power recovery works exactly, but the filament runout could probably be done if you can find where the value of the filament sensor is and ping it continually to see whether or not it is an open or closed contact.
i think power recovery might be a bit more complex involving using the remaining juice in some capacitors to send out some command back to the controller to hold it up, it would be better if they would implement the pause/unpause gcode and applied both scenarios to take advantage of that instead
whether or not the continual pinging of the sensor’s status is a good idea i am not sure, it could cause performance issues.
