The popup doesn't always close. Somehow it seems to affect the settings popups too (probably a selector hitting two dialogs). Need to recreate the popup each time it opens and make sure the selectors are specific.

It's possible that some of the logging options aren't doing exactly what they say. I built them to reduce the amount of logging information I was getting while debugging, and my late night debug fest code is not necessarilly the best code there is.

Octolapse does not currently work when printing from the SD card. I don't think this is possible at the moment, but if anyone has any ideas create an issue and submit it. I"m going to mark this as don't fix, but will leave it up for a while in case anyone has a suggestion.

I need to experiment to see if we need origin detection after a G80 and what the coordinates are after vs before running G80, especially a G28/G80 combo.

Currently a reboot may be required after restoring the default settings. This should not be the case.

Hi,

I wanted to get started with OctoLapse so I downloaded and configured everything. I started a print in test mode and noticed the plugin never seemed to detect the homing (It was still waiting for coordinates).

I am using a Wanhao Duplicator i3 v2 modded with a RAMPS 1.4. I use Slic3r (Prusa Edition) to slice. The home command is G28.

Here are the first few lines of GCode:

M107
M190 S60 ; set bed temperature and wait for it to be reached
M104 S210 ; set temperature
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G1 Z15.0 F80 ;move the platform down 15mm
G92 E0                  ;zero the extruded length
G1 F80
;Put printing message on LCD screen
M117 Printing...

; Filament gcode

M109 S210 ; set temperature and wait for it to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G1 E-2.50000 F2400.00000

Also, I noticed that "View as larger image" and the button to its upper right corner are not working. What are they supposed to do? I know my camera is working as configured (both your plugin and the Octoprint timelapse plugin confirm the camera works.

Print in Test Mode

Add an option within the debug settings to allow the user to test their camera settings on their actual GCode file, without extruding any filament or heating up the bed/nozzle. This will also make debugging faster.

Requires that we strip off all commands that move the extruder in any way, and that we completely suppress any commands that heat up the bed or nozzle, or switch tools. All of these commands should be sent to our position tracker BEFORE being stripped or suppressed.

After receiving word that Octolapse is working with at least one MK3, I want to add a default profile. I just need the settings!

Attempting to create a new stabilization profile that has both X and Y stabilization options set to 'Disabled' silently fails.

Workaround: You CAN create it with either set to another value, then edit them later to get the desired "just take the picture wherever you are" setting.

Octolapse will not work if printing from the SD card. I would like to send a notification to the user that Octolapse will be disabled.

When running without OctoPrint or OctoLapse webcam configured (properly), you may get some of the following errors:

2018-02-23 12:08:54,313 Traceback (most recent call last):
  File "/home/wesley/workspace/OctoPrint/src/octoprint/plugins/Octolapse/octoprint_octolapse/__init__.py", line 299, in CopyOctoprintDefaultSettings
    o = urlparse(snapshotUrl)
  File "/usr/lib/python2.7/urlparse.py", line 143, in urlparse
    tuple = urlsplit(url, scheme, allow_fragments)
  File "/usr/lib/python2.7/urlparse.py", line 182, in urlsplit
    i = url.find(':')
AttributeError: 'NoneType' object has no attribute 'find'

2018-02-23 12:22:57,992 Printer event received:PrinterStateChanged.
2018-02-23 12:22:57,993 Printer event received:PrintStarted.
2018-02-23 12:22:57,993 State Change:PrintStarted.
2018-02-23 12:22:57,994 Traceback (most recent call last):
  File "/home/wesley/workspace/OctoPrint/src/octoprint/plugins/Octolapse/octoprint_octolapse/__init__.py", line 437, in on_event
    self.OnPrintStart(origin)
  File "/home/wesley/workspace/OctoPrint/src/octoprint/plugins/Octolapse/octoprint_octolapse/__init__.py", line 481, in OnPrintStart
    result = self.StartTimelapse()
  File "/home/wesley/workspace/OctoPrint/src/octoprint/plugins/Octolapse/octoprint_octolapse/__init__.py", line 507, in StartTimelapse
    if(not os.path.isfile(ffmpegPath)):
  File "/home/wesley/workspace/OctoPrint/octoprint_venv/lib/python2.7/genericpath.py", line 37, in isfile
    st = os.stat(path)
TypeError: coercing to Unicode: need string or buffer, NoneType found

Nothing is displayed on screen at all, so you should probably display some sort of warning...

Since some folks may have z-hop disabled completely, I'm going to allow ZHop = 0, which means IsZHop is always true, so the zhop snapshot restrictions will not have any affect.

It might be reasonable to add an option to enable/disable zhop in the snapshot settings too, so that users who don't want zhop aren't forced to use it for snapshot travels.

I did my first real print and it worked quite well. The only issue that I ran into was that the camera lags behind a bit because of the limitations of the Pi, so I increased the time to wait for the photo to 1 second. I also created a "on z change" time lapse for comparison. Both look pretty bad image quality wise because my enclosure isn't lit very well and thus the ISO value needs to be pretty high, but your plugin does a really good job of moving the head to the exact same spot without much overhead.

Comparison.zip

When I started Octolapse, I was not aware this command existed. It took some substantial modification to support G92. This command has now been implemented, but not well tested. In fact, I'm not sure if I completely understand the expected behavior of this command in all cases, so my implementation is most likely incorrect. I've tested a lot of GCode that included G92 for extruder position, but not X,Y,Z, so beware.

If any settings would obviously prevent a user from taking snapshots/rendering a timelapse, the user should be notified right after starting a print. This already happens in some cases (printing from SD, some other items), but it needs to also happen for a few other things, including 'no default printer selected' from issue #45.

This could be used to fix Issue #29 too.

I would like to acquire a general use printer profile for the Monoprice Maker Select v2/Wanhao Duplicator i3. A good clean description would be a plus!

If you have one, please consider posting your printer profile. You can either post the settings manually, take screen shots of your configuration, or export your settings.json file which can be downloaded within the Octolapse settings screen.

Thanks!

Show all currently selected profiles in a knockout template. Keep it short and sweet so it doesn't take up too much space. Depending on what it ends up looking like it could go under the current status template on the Octolapse tab, or it could be integrated into the same area as the current tab controls.

A bonus feature would be a profile summary for each selected profile (printer, stabilization, etc..). This could be as simple as a tooltip, or it could be a popup dialog.

Add Pre and Post-Roll to rendering options and ffmpeg rendering. Pre and Post-Roll should be in seconds and be calculated based on the framerate.

Using the new job_on_hold feature, eliminate the need to pause the print at all, improving the look of the UI and slightly reducing any delay between the the snapshot start routine and the initial retract/lift.

If the print is cancelled right as a snapshot is downloading, the program will crash when trying to send the return gcode. Need to abort then!

Somehow I lost the code to choose the proper codec. Re-add and re-test this. Add some additional formats if it's convenient.

I've discovered a problem with the ZHop detection. When I implemented 'Undo' for the position and extruder classes, The ZHop detection used to have start-hopped-end type state tracking, but that became unnecessary when I switched to storing the states in a list. I have replaced the position.IsZHop code to now only report on the current state, and the Triggers simply check the previous IsZhop state (since we won't actually execute the gcode that triggers the snapshot until after we take the snapshot) to see if it's time to trigger.

I've tested in the virtual printer, but have not tested live.

All current branches of Octolapse assume that the extruder is in relative mode by default. This does not appear to be true for many (all?) printers. For the time being I'll set the extruder to absolute by default.

Do any printers have relative mode as the default for the extruder? If so, I'll have to add another setting to the printer profile.

While attempting to get Octolapse working for the Anet A8, I stumbled on some new facts:

1. Some gcode does not specify relative/absolute extruder.
2. Some printers extrude well above the build plate to prime.

I was aware of item 2, but I didn't realize what affect it would have on the layer trigger.

To solve these problems some new settings were added to the printer profile (* is the default):

xyz_axis_default_mode - ('relative','absolute','require-explicit' *) Note that if this setting is 'require-explicit' and we haven't seen the proper gcodes(g90/g91), we might not be able to track the axes positions.

extruder_axis_default_mode - ('relative','absolute','require-explicit' *) This affects lots of things. Note that if this setting is 'require-explicit' and we haven't seen the proper gcodes(m82/m83), we might not be able to track the extruder position.

priming_height - when 0 disabled. when > 0 layer/height detection should not work until there is an
actual extrusion BELOW the priming_height. This affects position.py layer and height calculation

g90_influences_extruder - ('true','false','use-octoprint-settings'*) This was added for consistency. Previously we were always using the octoprint setting. This way it's easy for users to see that octolapse cares about this setting, and it can be easily changed without exiting the plugin settings. This affects position.py (g90/g91 command).

Tests need to be written for each possible option for each of the three new settings. This could be done by setting the appropriate settings you want to test, creating a Position object, and sending gcode commands via the .update function. The position states are stored in a member called Positions (array of Pos objects, effectively a circular queue of length 5). This is where you can find which layer/height we are on, the axes positions, etc..

I've gotten word that some strange things are going on for at least one user who attempted to use Octolapse with an Anet A8. The specific complaint was a 'jittery axis' that went away when the plugin was uninstalled.

There could very well be some gcode issues if I've never come across the commands used, or if some commands aren't parsing due to unknown parameters. It's probably not a profile issue, but the end result of testing/fixing an Anet A8 should also be a default printer profile.

Todo: Acquire some sliced gcode (preferable from a default profile for the Anet A8, provided by the MFG, but I'm not sure if they supply one). Run tests in the virtual printer and see if there are any problems.

Add a feature to restrict snapshot positions to certain areas for each trigger. The fences can be either rectangular or circular. Not sure if this would be useful for Gcode Triggers, but I'll put it there anyway to be consistent.

The user should be able to add as many position restrictions as they want. If a snapshot would normally trigger, but the axes are not in the proper place, the trigger will be put into a waiting state until a movement puts it inside one of these 'fences'.

A good bonus feature would be to add another drop down to each restriction that says something like 'allow' and 'prevent'.

This is in-process

Especially the printer configuration page has many number input fields like retraction length that need a unit to make sense. The Octoprint printer configuration page has input boxes with units, so I assume these could be used here?

It would be nice to throw an error to the UI if a print is started with Octolapse enabled but no ffmpeg path defined.

I've noticed some areas where floating point math may cause problems, but I have not resolved or located all of them. They could prevent proper extruder monitoring/zhop detection in some cases and result in missed/late snapshots. It might also cause octolapse to output some position detection errors to the logs while taking snapshots.

Currently this is handled in render.py, but it needs to be moved to snapshot.py because it belongs there logically.

Need to add options to only clean the most recent temp snapshots.
Need to add a menu option to clean all temp snapshots, even those from other prints.
Consider adding some additional cleaning options (clean all before print maybe?)

Occationally I've noticed that my plugin might miss the first few GCodes sent to the printer. This has only ever affected me while using the debugger, but I think it's possible that it could happen during a test print. This can have the effect of letting commands that should be suppressed/rewritten slip past my routines and make it to the printer. In the worst case these commands could heat up your bed or extruder. When using test mode make sure you keep an eye on your printer's fans, temperature, and extruder motor and ALWAYS unload your filament to be safe.

There are probably some additional commands that should be suppressed/rewritten for test mode that are not included. If you find any let me know.

Currently the info panels can only be enabled/disabled within the main settings dialog. It would be nice if this could be accomplished directly on the tab. A menu button on the main tab control would be a good place to put this and any additional controls we want to add.

I have installed the plugin and followed the instructions, but I must have missed something because I can't get it to work. I restarted Octoprint and enabled the plugin, changed some printer settings and enabled test mode. When starting a print, the printer still heats up and doesn't pause between layers. The printer is a Prusa MK2s.

plugin_octolapse.log

10mm_calibration_cube.zip

settings.zip

If you are using an Original Prusa printer, there is a possible issue in the firmware 3.0.12 (linear advance update) that causes lock-ups and, in the very worst case, out of order gcode execution when using Octolapse. I don't recommend using octoprint whith linear advance enabled for the time being.

I've been albe to work around this bug by by avoiding the Linear Advance profile within Slic3r prusa edition. I'm not sure if it's necessary, but I also changed the custom filament gcode found in Filament Settings->Custom G-Code to: M900 K0

I've heard that this bug has been fixed for the Mk3 in the latest release candidate firmware. See the release notes.

Sometimes Octolapse fails to capture any snapshots. After completing the print, the following error appears:

Octolapse has failed to render a timelapse. Reason:No frames were captured.

I have attached a log file where Octolapse properly captures snapshots until the print is cancelled and restarted. During the second print, no snapshots are captured.
plugin_octolapse_fail2.log

I have not been able to determine the conditions where Octolapse captures snapshots properly and when it does not. If I can help by performing any tests, please let me know.

This will help prevent users from installing Octolapse and attempting a print without checking the settings.

Change the timelapse template to:

PrintFileName_YYYYMMDDHHMMSSMS.EXTENSION

These are not currently supported. I hope to include support for these at some point, but I don't own one to test on currently.

Some places in the code are still case-sensitive. I know the parsing front-end is mostly proof against this, but some of the internals will crash if provided a lowercase GCode (one of the tests is failing because of this :( ).

Low priority unless a user-affecting issue is discovered.

The original NIST GCode standard requires gcode interpreters to be case-insensitive, except for characters in comments. However, not all 3D printer firmwares conform to this and some recognise uppercase command letters and parameters only.

Priming is sometimes done quite high off of the build plate (Anet A8, probably many others). I am used to priming being done on the bed (Prusa Mk2/Mk3), which doesn't cause much of a problem.

A long while back I had a setting for a minimum height that needed to be reached before any snapshots could occur, but it wouldn't have solved this problem since the gcode I've seen homes, raises up, extrudes, then goes back down to print. What is needed is a printer setting called 'Priming Height". Any extrusion done on or above this height would be ignored by any layer detection that's going on.

For some reason I was starting with frame 1, but it should be frame 0. Also need to add an error when only a single frame is taken (can't render with only a single frame really!)

Add an indicator on the snapshot profile add/edit page to show if any position restrictions are available. Currently these are stored within the advanced settings, and could easily be overlooked if one is reviewing settings before a print.

The indicator must be outside of the advanced area for each trigger, and plainly visible when any of the triggers are enabled.

These have not been tested. I was made aware of them while writing this plugin. It's possible these printers could work, but things will be a bit wonky for sure. I imagine the 'Front Left' stabilization preset could end up actually taking snapshots in the back right.

I don't think it would be too hard to fix this, or to add a settings to the printer profiles.

After a major rewrite I got lazy and didn't update my tests, now most of them are completely broken. Fix all these tests and keep them up to date, especially since the code is starting to stabilize.

The most recent merge broke the build. Looks like several small issues regarding ')'s at the end of functions that were previously nested within ()s.

Some printers have their origin's in the middle of the build plate. This is another thing I learned while writing this plugin. I'm pretty sure these will work if the settings are correct, but I don't have one to test it out.

Refactor all code to align with the following style guidelines, particularly the naming conventions.

https://www.python.org/dev/peps/pep-0008/

I probably should have read this BEFORE starting the project, lol!

Add a button to download the settings.json file for debug/testing purposes. This should probably go in the debug tab.

I'm using a bunch of different payloads for the rendering callbacks. Need to make these uniform.

If a user cancels a print, especially before the first layer is complete, then there's no reason to do a post roll. This is particularly painful because if you fix the issue that caused you to cancel the print in a hurry and start a new one, then the second print doesn't get a timelapse created.