Octolapse
Octolapse copied to clipboard
FormerLurker
Idea to get octolaps working while SD printing
It would be a rather brute forced way but would work..
On every layer change we ad some e gcode to move the print head away and ither presses a switch or the gcode activates a pin(easy in Klipper fw). Then the octolaps plugin also triggers on gpio pins on the pi(I know that it is different logic voltages so if the pin alternative would need optocoupler or some other isolation)
Do? Or not do?
I've actually seen this done before! You don't really even need Octolapse to pull this off. However, I can see how Octolapse could make the process easier (one less thing to do), and will consider how that might be accomplished. Let me know if you have ideas in the meanwhile.
I know that octolaps isn't needed but a fully functional/easy to setup would be great. As I always print via SD( or virtualSD thru Klipper due to performance issues of octoprint) an easy to set up solution.
On a cartesian printer it is rather simple to add a switch but on deltas there need to be some gcode controlled thingy...
for the pin part you could look at https://plugins.octoprint.org/plugins/filament_sensor/ https://plugins.octoprint.org/plugins/enclosure/
What things could Octolapse respond to when printing from SD?
Octoprint seems to know what the target temperature is for example. If I edited my GCODE to briefly dip the temp on each layer could Octolapse respond to that?
Temp may be a bad example for all sorts of reasons but you get the idea hopefully.
I believe Octoprint knows about the temps when printing from SD because it polls for the information via M115, but I'd have to double check. It's also possible that the printer just streams it back from the printer. The problem in using this method for Octolapse is that it requires to know every gcode that has executed in order to track the printer's position, to move to and from the snapshot location, and to decide exactly when and where to take the snapshot.
However, all of the above only applies if you're reading the gcode in real time. I've been thinking about ways of doing this with pre-processing. I'm finally getting around to writing code to handle gcode pre-processing, which will enable all kinds of neat things. It should be possible to inject gcode into the file that will perform the stabilization action and alert Octoprint to take a picture, and to pause long enough to get a stabilized image. However, the gcode wouldn't be useful when NOT running with Octolapse in this case.
Injecting M25 to pause SD print and using M26 to continue may be possible if I can figure out a way to communicate this to OctoPrint.
I'll leave this issue open so that we can continue brainstorming.
I had assumed it would have to involve editing the GCODE on the SD card somehow. Without having given it much thought I had assumed I could do some regular expression search/replace in a text editor to identify the layer changes and add code for the snapshots.
The challenge then is to cue Octolapse to take the shot which is why I was spitballing about what info is available via Octoprint. If Octoprint is having to poll for that info it becomes a lot less reliable timing wise though.
For me printing directly from the SD card gets me much more reliable prints than printing from Octoprint so I am still physically moving the card between my printer and the PC.
Was looking around how to possibly add Octoprint timelapse to SD prints as I recently realised the quality (or speed) compromise for serial prints on high quality and vase mode prints especially. Came across this discussion and thought to share my 2 cents!
Here's a thought: Cura's post G-code processing allows for a "timelapse" function with a customized G-code trigger, moving extruder and even a pausing time. How about using a M118 for a message to host and read the @OCTOLAPSE TAKE_SNAPSHOT from there? I thought it might already work, but haven't been able to get Octolapse to start at all in this manner. The command shows up in Octoprint terminal, but it seems Octolapse doesn't read it from there yet?
No fancy animated timelapse possible, but a least a stabilised timelapse from SD prints?
