Octoprint: Feature Request: G-Code for take timelapse picture

Created on 8 Mar 2016  路  7Comments  路  Source: OctoPrint/OctoPrint

I love the timelaps feature in octoprint. Unfortunately using lift for moves totaly screws with taking pictures on Z change. It would be nice to have a special G-code to take a picture. One could insert that easily as "custom G-code between layers" in many slicer. When encountering such a G-code octoprint would take a picture and omit the G-code from the stream so as not to confuse the printer.

request timelapse

Most helpful comment

How about this... I'll create a new ticket for making timelapse types modular. That's been on my personal TODO list for a while now anyway, mostly due to tickets like #452, #1116 and #1164. The idea is that a modular timelapse type system would allow plugin authors to basically have timelapses start, stop and take pictures on conditions _they_ decide. So something like "on some command or GCODE in the file" or "on this and that echo from the printer" would be entirely possible all of a sudden. I think opening up that part of the platform for people to get creative with makes more sense than to try (and fail) at covering every possible angle within the core application. Would probably make sense to even extract the z-based and time-based timelapse into (bundled) plugins, to decouple stuff further.

I'll then mark this ticket "plugin-only", and once the other part gets implemented it should be trivial to do even for someone only getting started with plugin development.

Does that sound like a deal?

All 7 comments

PR #1148 will solve the issue with z based time lapses and z-hops.

concering PR #1148: The patch assumes that you have a constant z hop height and have configured the same value in the slicer and octoprint. That probably often works. But then someone will tune his slicer config and suddenly the timelaps is all screwed up again. Then there are tool changes and wiping that will introduce further Z movement that would have to be compensated. Or the different layer height for supports or for combined infills will throw it off. Overall it seems fragile.

On the other hand with a picture G-code the slicer can insert it at the right moment. You can take a picture for every real layer but skip the support and infill layers. Or only take a picture every 3 layers. Or only between 10mm and 20mm height where the interesting bits are.

Would you accept a patch for this when I find the time to write one?

Note: The G-code already exists (available in Marlin firmware):

M240: Trigger camera 
Triggers a camera to take a photograph. (Add to your per-layer GCode.) 

How about this... I'll create a new ticket for making timelapse types modular. That's been on my personal TODO list for a while now anyway, mostly due to tickets like #452, #1116 and #1164. The idea is that a modular timelapse type system would allow plugin authors to basically have timelapses start, stop and take pictures on conditions _they_ decide. So something like "on some command or GCODE in the file" or "on this and that echo from the printer" would be entirely possible all of a sudden. I think opening up that part of the platform for people to get creative with makes more sense than to try (and fail) at covering every possible angle within the core application. Would probably make sense to even extract the z-based and time-based timelapse into (bundled) plugins, to decouple stuff further.

I'll then mark this ticket "plugin-only", and once the other part gets implemented it should be trivial to do even for someone only getting started with plugin development.

Does that sound like a deal?

Would work, I am mostly doing timelapses of vases with continuous Z movement, and used to use M240 which is inserted by the slicer.

I need to be able to take unobstructed pictures for a plugin used by a commercial project. I'm still new to OctoPrint and Python so I will need some help getting it to work. If someone is willing to help me, I can see if my employers would be willing to help fund you and/or the project. My thought would be to take the code from the working plugin and then fold it back into a mixin along with a corresponding example plugin. The resulting code should be automatically triggered using Timelapse or by each M240 in the G-code file.

For my two cents ... IMO, the existence of M240 is errant. Octoprint is not the machine under control and it should therefore not be intercepting and interpreting gcodes. Instead, I would suggest using special tags in gcode comments, as is done elsewhere.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

christianh17 picture christianh17  路  5Comments

cp2004 picture cp2004  路  4Comments

halkeye picture halkeye  路  4Comments

JohnOCFII picture JohnOCFII  路  5Comments

dkingsjr picture dkingsjr  路  5Comments