Printer Profile - Anet A8 - Compatibility check about octolapse HOT 32 CLOSED

A few additional settings have been added to the printer profiles (Issue #42) that control the default axis mode (relative/absolute/unknown) both for X/Y/Z and for E.

I fixed the problem with layer tracking caused by your priming code (extrudes at 15mm to prime, issue #43) and irritations caused when Zhop is disabled in your slicing profiles (zhop = 0 now for these cases. All the triggers now think everything is a zhop. see issue #44)

All of these combined means the Anet A8 should work out of the box now (fingers crossed). I'm not 100% sure about the origin, though. Maybe you can do a G28, then M114 and let me know what position you see (hopefully it's 0,0,0).

Finally, I may have fixed the issue with 'restore default settings' that required a reboot/clear cache. It's worked in every instance I've tested.

I think Octolapse is as ready now as it ever will be for a print in test mode on an Anet A8! I'm REALLY excited for you to try this out. Now if I can get a profile for the Monoprice Maker Select v2/Wanhao Duplicator i3 (Issue #27), that would bring the number of compatible printers up to 6 (if you count the Mk2 and Mk2S as separate printers). Woot!

from octolapse.

Thanks, I'll look it over in the AM. I'm hopeful that the third time will be the charm!

from octolapse.

I am running a test print now with that same gcode.
It is taking snapshots now!

from octolapse.

I was talking about the bed/extruder being heated during a test print.

regarding the priming issue (z=15 for first layer), double check this priming height setting:

If it's set to 0.5, or something like that (it needs to be under the priming height of 15.0, but above the first layer height, so .5 should work)

If it IS set correctly, I'll have to debug that feature. It's brand new and I can't really test it easily on my Mk2 unfortunately (though I will try in a bit as soon as my print finishes and work is over).

Baby steps I guess, lol!

from octolapse.

I don't believe I ever touched the 'Priming Height' setting until you suggested I check on it.
(It's inclusion as a feature makes excellent sense though!)

I will definitely send you a link to a good timelapse as soon as I have an opportunity to run a proper print.

Thanks so much for your help, you've been marvelously attentive, and your plugin is awesome.
I am very excited to use it.

from octolapse.

I'll add an issue and will switch the format. You convinced me! I deem this issue to be closed! Feels good...

from octolapse.

Hello FormerLurker! I am the fellow who mentioned the issue.

Here is gcode for the calibration tower, sliced per the manufacturer's settings (the seller supplied a guide for configuring Cura):
https://tinyurl.com/y7dtwzwk

Here is the Cura (14.07) profile based on the manufacturer's settings:
https://tinyurl.com/y7p6tfgl

Let me know if I can do more to help!

from octolapse.

Excellent, thank you! I just got the mk3 beta profile finished, and I'll be glad to get another printer working. Unfortunately, since I don't have access to an A8, you'll probably need to be my tester. Hopefully you won't experience anything worse than the jittering you've already seen.

from octolapse.

I am happy to test whatever you need!

from octolapse.

I've already made discoveries.

This code:
G28 X0 Y0
G28 Z0

Has already been found to cause issues, and that problem has been fixed (regex didn't know how to handle the numbers after the axes parameters).

Did you install the master.zip version, or the BetaDevelopment.zip version? There have been a lot of changes since I made that post, and I'm very close to updating the master to v0.2. I'll keep reviewing the GCode and see if I can learn more before having you run a test mode print with diagnostic logging.

from octolapse.

I've discovered a few other things.

1. I had assumed previously that relative coordinates were the default for extruders, apparently this is not true. I've fixed this, but it's going to take a bit of testing.

2. The nozzle prime is done at a height of 15mm, which throws off the layer trigger(it thinks you have printed at this height). I may have to bring back a feature I had removed because I thought it was not necessary: extrusion must be below X mm before layer tracking starts. The timer and custom gcode triggers should be unaffected by this.

I don't think either of these will take too long to deal with. I also added an anet A8 profile. As soon as I've gotten item 2 re-implemented I'll commit my changes and will let you know. I doubt it will be tonight, but it might well be tomorrow.

from octolapse.

I've created Issue #42 and Issue #43 to deal with the non/profile related issues.

from octolapse.

Hey @Ruthalas,

I just pushed an update into the BetaDevelopment branch that might solve your issues. You can install using the same instructions that are located here,, but switch master.zip to BetaDevelopment.zip (did I tell you that before? No matter..). After Octoprint reboots, go into the octolapse settings, restore the defaults, reboot once more and clear your cache (I'm hoping this is not necessary for too long. I still haven't had time to debug issue issue #19 100%). Then go to the debug tab and select the diagnostic test mode profile. Print that gcode you sent me. Hopefully it will complete and deliver a timelapse. If you have any problems, please attach the plugin_octolapse.log and the octoprint.log file to this issue and I'll continue debugging.

You might consider turning on the 4 info panels in the main settings screen after you verify that the print is going well. These can help you visually identify problems. Once you turn them on, they will be visible in the Octolapse tab while you are printing (they go away when not printing).

I'm 99% sure the issue was really with the cura profile, and not the printer. The issue with absolute extruder mode would have caused some filament grinding, for sure. Maybe that's why you saw the 'jittery axis'. I've never seen start-up gcode that didn't include M82 or M83 before. Not saying it's uncommon (I don't know), but it seems dangerous to me. I've changed the code to default to absolute extruder coordinates for now, but may update the printer profile to make this adjustable. If I do that I'll probably do the same thing for X,Y and Z (why not... who knows what other squirrely gcode exists in the wild, lol!)

from octolapse.

I am installing from the BetaDevelopment branch now!

I will report back after debug printing the test column.

from octolapse.

Excellent. I'll be anxiously awaiting your results.

from octolapse.

Ok! The print finished!

The motion appeared normal, but octolapse did not record any snapshots.
This may be a configuration error on my part (but I thought it was appropriately set up).

What logs, if any might be helpful?

from octolapse.

from octolapse.

I used 'Layer Change' as my trigger.

Here is the octolapse_log: https://tinyurl.com/y8wh95c4

from octolapse.

It looks like one of the Anet profile settings is incorrect. Specifically this:

"e_axis_default_mode": "require-explicit",

This should be

"e_axis_default_mode": "absolute",

Not sure how that got changed. Maybe you didn't click 'restore default settings'? Since we're still in Beta, I've not made any effort to upgrade old setting formats, so sometimes default values get inserted if the settings don't currently exist in your settings.json file. Also, FYI, uninstalling Octolapse does not get rid of the settings file (at least not when running windows. I've not tried it on my Pi), so if you had an old version of settings.json, that could have possible caused an issue.

Anyway, here are the Axis mode settings you should have (printer profile):

Here are the info panel settings you can use to visually debug your snapshots:

Here is what you can see in the position state that identifies this problem (The question mark next to the Extruder Relative flag. If you hover over it the tool tip says 'not set'):

You can also see that E remains at 0 throughout the print:

In short, if you restore your default settings (restart octoprint after doing this and clear your browser cache by pressing ctrl+f5 after it comes back up just in case, no need to debug two issues at once), make sure your e axis mode is 'absolute' and your xyz axis mode is 'require explicit...' and you should be good! It wouldn't hurt to go to camera profiles and click the 'test' button to make sure that's working before starting another test. If the test print works, try again using without using test mode.

Lastly, after you get this working you might want to stick an M82 gcode right under the G90 command for safety in your start up gcode, or set Cura to slice using relative extruder coordinates. They are better to use anyway, because they reduce rounding errors. However, I'm REALLY glad to have seen this situation so that I can account for it.

Hope that helped, and good luck!

from octolapse.

Ah! I didn't clear the cache- I misread your previous message regarding that.
The camera tests out good, I have been trying that with each change.

I have now restarted, cleared cache, and changed the e-axis mode.
I will print another test print.

(And look into adjusting my Cura slicing profile.)

from octolapse.

Please try with the GCode you sent me first, I'd like to know if the default profile works with the default cura settings. Then, by all means change your cura settings ;)

from octolapse.

Hot damn! Feel free to cancel the print at any time since it appears to be working. Make sure the timelapse generates properly, then try the same print in live mode (debug - either 'no logging' or 'Full Diagnostic - Live Print'). If that works I'll close the issue. W O O T!

from octolapse.

I found an issue.

The timelapse starts partway through the print.

I re-ran the print, and the print begins, homes, moves to a point somewhat (15mm?) above the bed for the first snapshot, then doesn't take another snapshot until the print reaches that same elevated point again. (Thus skipping taking snapshots for the first portion of the print.)

The 'Position State' header starts at "Layer 1" and "15mm", even at the very first layer.

(Even though the 'Position' read-outs appear to all be correct.)

Screenshot: https://tinyurl.com/ybujjz3j

from octolapse.

(As a side note, the test mode seems somewhat inconsistent in whether it heats the bed/extruder. The first test print heated both, and didn't turn them off when done, the second test print (beta build) didn't turn either on, the third test print (beta build) only turned on the bed.)

from octolapse.

Thanks for letting me know. This is an unfortunate issue that will be resolved when the next version of octoprint releases. Gina (creator of octoprint)added a feature to help with this. On a side note, once this feature is in I'll be able to take snapshots without pausing the print!

from octolapse.

Are you referring to the snapshots starting at z=15mm, or the inconsistent heating of the elements?

from octolapse.

The priming height was set to 0mm. (Which should theoretically turn it off, according to the tool tip.)

I have set it to .5mm and am trying a new test print.

from octolapse.

That fixed the priming issue! Thank you.

from octolapse.

Sweet! I'm going to write a novel again here, so bear with me. I want other folks who have problems to understand the issue.

Setting priming height to 0 does in fact turn this feature off. Did you change this setting from 0.5 to 0, or was it there when you restored the defaults? I might need to look into that (very irritating) issue. I just can't seem to quash it.

Octolapse uses a (i think) unique method of detecting layer changes. Not only does it look at the z axis position, but it doesn't consider something to be a new layer until it detects plastic actually extruding from the nozzle. It ignores anything printed on lower layers after it sees an extrude at a given height. This is mostly for safety (don't want to take a snapshot and run into the print after we lower Z). The 'Height trigger' works similarly, but is independent of the actual layer height (useful if you have support material printing at a different height than your standard layer height, or if you're printing in vase mode). I REALLY need to create a good user manual. ugh..

The new priming height feature allows you to ignore extrusion and layer detection until the printer has extruded BELOW the priming height. I am using it on my Mk2 also, since the priming layer is at 0.25MM (it primes outside of the print area), but the print starts at 0.2MM. That means the first layer snapshot will be taken AFTER priming process is complete. In the case of the MK2, it's a matter of opinion what is better, but in your case losing the first 15mm of snapshots is really unacceptable.

Please post your first good timelapse on Youtube or somewhere else I can get to it. If it's a nice looking video, and I get your permission, I'd like to use it when I release the new Beta. I want to showcase the newly compatible printers! Later I'll look for some Anet A8 forums to post to so folks know it's working. Do you have any suggestions?

Thank you so much for going through this debug with me. I can honestly say it's done a lot to improve the program, and should facilitate adding many new printer profiles! Don't forget to let me know if you changed the priming height manually, or if it was an error with the 'restore default settings' feature. Depending on your answer I'll be able to close a bunch of issues, which always feels good :)

Happy Octolapsing!

from octolapse.

(What is the naming convention for timelapses rendered by Octolapse? "151992577392.MP4" doesn't seem to match the usual YYYYMMDDHHMMSSMS format the default renderer uses.)

from octolapse.

It's in Unix Epoch time. I used to have a setting for the naming template, but it was too complicated for users to understand, and the templates are difficult to validate. Try sorting by create date, it should be the most recent file. I just printed a Benchy, and it took about 2 minutes to render, but it's taken up to 10 minutes for prints with a whole lot of frames.

Let me know if you have a better suggestion for the default naming convention. I could easily use the octoprint format. I honestly didn't put too much thought into that!

from octolapse.

Ah! Ok, that makes sense.

If it were up to me, I'd mimic the octoprint format by default.
That would be more meaningful to users switching to your tool, sort properly with pre-existing timelapses a user may have made already, and be more visually parse-able for the user.

(I personally download my timelapses from the pi to another PC, so the 'date modified' depends on when I download the file, rather than the original creation date, making sorting by that meta-data less useful.)

It's up to you though!

from octolapse.