Octolapse stops after first of multiple objects finishes

[BenBergman]

If this is a feature request describe it here

When I use Cura's "One at a Time" feature, Octolapse stops taking pictures after the first object finishes printing. I would love to get a timelapse that shows each of the parts growing from the print bed.

I think what is happening is Octolapse sees it has already taken a picture for each of the layers of the second object and so it doesn't take any new ones.

Version of Octolapse

Octolapse Version: 0.3.4

Version of OctoPrint

OctoPrint Version: 1.4.0

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: No (I will try to do a test run when I have some more time though)

What were you doing when the problem occurred

1. Load multiple objects into Cura
2. Set Special Modes > Print Sequence to One at a Time
3. Run Octolapse with snapshot method set to "Layer Change - Compatibility"

What should have happened?

Photos should be taken after each layer change of each object.

What happened instead?

After the first object completes, no more photos are taken (more might have been taken if second object is taller, but all my objects are the same height)

Operating System running OctoPrint and Octolapse

OS Name: OctoPi
Os Version: 0.17.0

Printer model & used firmware incl. version

Printer Model: Artillery Sidewinder X1
Printer Firmware Version: Unmodified, so unsure.

Browser and version of browser, operating system running browser

Browser: Firefox
Browser OS: Arch Linux

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: https://gist.github.com/BenBergman/9b82b77ddf41d1752f464385a5d17050

Link to settings.json

Link to settings.json with all passwords removed: https://gist.github.com/BenBergman/3717c7162db3be190bdb1dffcf50f2b1

Link to plugin_octolapse.log

Link to plugin_octolapse.log: https://gist.github.com/BenBergman/ad391e0dffdb51535f0374b5d068c22a

Link to octoprint.log

Link to octoprint.log: https://gist.github.com/BenBergman/9cae03eaedf99780911062a98aed47c9

Link to contents of Javascript console in the browser

Link to javascript console output: Not a UI bug, so not applicable

Screenshots and/or videos of the problem:

Screenshot/Video Links: Can upload the incomplete timelapse once print finishes

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

[BenBergman]

Flicking through more settings I found a workaround. Using the Gcode snapshot method and adding "snap" before each layer change in Cura I'm now getting the timelapse to run more like I was expecting.

[FormerLurker]

Hey, sorry I didn't get to this sooner. Been a hectic day.

Be careful triggering octolapse between sequential parts! You may run the hotend into one. That's why your first attempt failed, octolapse detected extrusion on a lower layer and refused to take a snapshot. The next version (0.4) refuses to do this with the gcode trigger too, so keep that in mind.

The only way i can think to make octolapse work with sequential printing is to raise the z axis before stabilizing, which would add a ton of time to the print. However, i am still considering this so that non planar printing and sequential prints would work too.

[BenBergman]

Yes, I understand the risk of stabilization movement crashing into prints, but thank you for pointing it out as someone else might see my thread and not realize it. I've laid out my parts on my print bed in a way that is certain to not get crashes (basically printing front to back). I already had to muck around with Cura to get it to allow this to begin with.

If you do end up disabling this by default (which is totally reasonable as a safety thing), can you please document a work around (with suitably scary warning messages)?

[FormerLurker]

Sure thing 👍. I may add a command for it.

[BenBergman]

Awesome. Thanks for the excellent plugin!

[Corgano]

IS there a solution for this yet? It's the problem I'm running into.

How is this currently implimented? I'm assuming octoprint only triggers on z INCREASE instead of on z CHANGE - that would reflect the behavior i see - It triggers only when the z increases regaurdless of which item on the bed causes the increase. This means that if I print a short object and a tall object it will give me a timelapse of the short object and the top half of the tall object.

If it works in this manner, could we get a way to reset the height to 0? Ex adding SNAP to g code will also reset height? Then we could manually SNAP after each object to force octolapse to work in the manner required.

[LightningShark25]

Hiya. First up thanks for the awesome plugin!

I'm also running into the issue where the octolapse only works for the first object in 'one at a time' prints.
For some detailed work, I'm using the 'dont wait for move finish' feature which has stopped all artifacts (only msec delays) in my prints (silk particularly) but I still get a timelapse.

Is the feature to allow octolapse for multiple prints (with the appropriate warnings if need be) available?

[SenithDR]

Be careful triggering octolapse between sequential parts! You may run the hotend into one.

What if you add it to the non-stabilised mode?
Since it won’t go into a pre-determined location before taking the snapshot, extruder hitting the objects won’t be an issue :)

[blast-hardcheese]

Also interested in this, though the consideration of other stabilization options other than the one I'm using running into the previous part makes a lot of sense as to why it's just disabled altogether. Thanks for octolapse!

[FormerLurker]

Have been out-of-action for a while all, sorry!

I think I can add a specific command to support this. I think that would be a reasonable trade off between the safety of Octolapse (not breaking things) and power user features for folks who know what they are doing. I'm assuming most browsers support gcode injection after switching parts?

What do you all think? Maybe something similar to the following special gcode that would have to be inserted between parts:

@Octolapse UnsafeResetMaxZ

This is based on @Corgano's observation that Octolapse does indeed track the highest point on a print where extrusion has happened. In this way, Octolapse can never run into any printed part, no matter what crazy gcode is present. So, this command would reset the max height where extrusion was detected to 0, which would result in Octolapse allowing a snapshot on the next layer, regardless of the height.

Alternatively something like:

@Octolapse AllowUnsafeMultiPartSnapshots

Though I'm not 100% sure how this could be easily implemented, and could trigger some other unexpected behaviors with things like non-planar printing. Anyway, I figured I would try to get some additional feedback before I attempted any of this.

Thanks for being patient folks!

[russoj277]

I figured I would try to get some additional feedback before I attempted any of this.

I am also interested in this. Earlier today I attempted a time-lapse of a 'one at a time' print. At the time, I wasn't aware of this thread. To ensure the hot-end wouldn't have any collisions: 1) within Cura I set the prints to run front-to-back, and 2) within Octolapse I set the stabilization to "back left". The print came out great but when I checked the time-lapse footage I noticed two things: 1) there's no footage of any prints after the first, and 2) there's no time-lapse frame of the last (topmost) layer of the first print. A Google search for a solution is what led me here, and I now see others have attempted this unique style time-lapse and ran into the same issues. I'm curious if an update for this might still be in your queue?

[ToxicFrog]

I just encountered this myself. I run with stabilization off, so there's no concerns with the hotend smacking into other prints during the snapshot procedure.

[etlam262]

@Octolapse UnsafeResetMaxZ

For me this option would suffice as I tend to disable stabilization to prevent artifacts.

[STiFTW]

Just ran into this as well, makes sense with the Z safety

[FormerLurker]

Yes, I am considering the following options, and one definite change:

1. If stabilization is off, or if snap to print is used, take a snapshot anyway.
2. If stabilization is on and the gcode trigger is used, only allow snapshots if an override parameter is included.
3. If stabilization is on and the other triggers are used, raise z to max Z and stabilize. I may add a warning.

Here is what I do NOT plan to allow right now: An override for stabilization without moving up to max Z before taking a snapshot.

That is just too dangerous, and might give Octolapse a bad name. I feel the gcode stabilization is OK since users are inserting these themselves.

There are a few details to work out yet, but this is doable.

[mathieucarbou]

Just saw this thread after discovering my timelapse was stopped after the first object :P

@FormerLurker : if we deactivate stabilisation ? What are the modes that would currently work (even if this is as bad as the default Timelapse option from OctoPrint), or you would advise for the moment to go with the OctoPrint timelapse feature instead for sequence print ?

Thanks :-)