Printer Profile - Monoprice Maker Select v2/Wanhao Duplicator i3' about octolapse HOT 58 CLOSED

FormerLurker,

I have linked to a YouTube Video produced on my modified Wanhao Duplicator i3 V2.
https://youtu.be/R3ZFfW2l7Lo

I am also attaching the settings.json file here.
Settings.zip

Let me know if you need anything else.

from octolapse.

Here is a new YouTube video with the snapshot delay set to 2000ms instead of 1500ms for the previous video. That solved the jerking in the previous video.
https://youtu.be/z7mM_oCBDD4

Here is the new settings.json file.
Settings.zip

Here is a link to the Fusion 360 model:
https://a360.co/2H4QIjK

from octolapse.

I have a Wanhao, but I'm unsure about what exactly you need. If you give me a bit more info, I can help! Also, a question, will this plugin adversely affect my prints in any way? I worry about the Y moves.

from octolapse.

Here is my profile I am using for my Maker Select v2.1.
Layer Height: .2
Initial Layer: .3
Shell: 1.2
Infill: 20%
PLA Temp: 220
Bed: 60
Retraction: 6.5
Print Speed:50
Travel Speed: 100
Initial Layer: 40
Z Hop: Yes
Z Hop Height: .1
Cooling: Yes
Support: Everywhere
Adhesion Type: Everwhere
MK21 PLA Normal 220 60.zip

Getting an error after installation on OctoPi/Octoprint 1.3.7 mc2:
Unable to restore the default settings. Status: error. Error: INTERNAL SERVER ERROR and
Octolapse could not load the current state. Please try again in a few minutes, or check plugin_octolapse.log in the 'Logs' menu for exceptions.

Log just says loading template information.

from octolapse.

Here are my Cura settings, all my other slicers have the same:

https://printsettings.stavros.io/settings/3wk4Fv/

from octolapse.

Thanks for all of the information! Give me a while to collate all of this and I'll come up with my best guess for the printer profile settings.

from octolapse.

Hey, how does this printer prime? Does it prime directly on the bed like the Prusa Mk2, or does it typically prime ABOVE the bed several MM? If it primes above the bed, can you tell me approx how high?

Note: I have NOT entered in the print volume, so it will use your printer profile settings in OctoPrint:

Retraction Length: 0.6mm
Z-Hop Height: 0.1mm
Movement (travel) speed: 9000mm/min
Retraction Speed: 2400mm/min
Detraction Speed: 2400mm/min
Z Movement Speed: 9000mm/min (not 100% sure since sometimes zhop speed is different than travel speed, you might need to slice something and look for z hop gcodes and see what the F parameter is)
XYZ Axis Mode - Require explicit...
E Axis Mode - Require explicit
G90/91 influences extruder - Use Octoprint SEttings
Default Units - Millimeters

auto-detect position - enabled
Additional location detection commands - LEAVE BLANK
Override Octoprint Printer Profile - DO NOT CHECK FOR NOW, but let me know what your print volumes are.
Abort snapshot when out of bounds - enabled
Printer Position Tolerance - 0.001
Priming Height - UNKNOWN. If your printer primes at a height ABOVE your layer height, enter that value here, or enter a value slightly above your layer height (0.5mm for example)

from octolapse.

Also, if you have already installed, please re-install. I have found and fixed a bug that could prevent the default profile settings from loading on startup (doah!) See issue #84 for details

from octolapse.

Priming depends on the slicer, for me. I usually have it zero everything, pull up a few mm, extrude some filament and start printing. Different slicers do different things afterwards, though. S3D zeroes the Z axis again and drags the nozzle all over my print surface, whereas other slicers just go to the specified XYZ point.

Is that what you meant?

from octolapse.

Yes that is exactly what I meant. You can set it just above the largest layer height for your nozzle. Maybe 0.5 mm? Do you ever prime below that height?

from octolapse.

I have added custom Gcode to all my slicers for that, so I don't remember what the original settings were. I prime at 15mm high, so I can clean up the filament afterwards. I'm not sure what this setting does (shouldn't Octolapse only care about what happens after the print has started?) so if you explain a bit I may be able to help you better.

I never prime below 0.5mm manually (because I extrude too much and want to wipe it off).

from octolapse.

By the way, can I use one of the existing profiles to test Octolapse out now (I just installed it for the first time), or do I have to wait for you to make a release with these settings?

from octolapse.

Sure thing!

See the printing profiles wiki for the current description, it may need to be clarified

So Octolapse detects layer changes by looking for extrusion, so this only affects the Layer/Height trigger. When it detects extrusion on a layer, this triggers a layer change and sets the current layer height to the current z position. The next layer change only happens if extrusion is detected ABOVE this height.

Octolapse doesn't start detecting layers until it's detected extrusion below the priming height (unless the priming height is set to 0). If you don't set the priming height and and you prime at, say, 15mm, Octolapse will detect a layer change and will not detect another layer change until after there is an extrusion ABOVE 15mm, so you'll miss snapshots for the first 15mm of your print.

Does that make sense? Maybe it could be distilled into a description I can use for the printer profile wiki?

from octolapse.

@skorokithakis , you can add a new printer profile and fill in the settings with those I've provided above. WATCH YOUR PRINTER LIKE A HAWK during your first print in case something unexpected happens. Maybe the 0.5mm-thin-wall.stl file here would be good?

Once you get the settings working you can export settings.json (can be done inside the Octolapse settings page) and post it to gist.github.com, or you can cut out the json for your new printer profile if you know how to do that sort of thing. I'll add the profile to the default settings and will push with v0.2.3.

I appreciate your help!

from octolapse.

Also, a question, will this plugin adversely affect my prints in any way? I worry about the Y moves.

@skorokithakis , I forgot to answer this question! Octolapse can most certainly affect print quality pretty much in the same way that printing multiple parts at once can affect the quality. Imagine if you printed two parts, one at the center of the bed, and another in the back left corner. You could have some stringing in-between the two parts because your printer has to travel from one part to the other. Also, it would require an extra lift and retract to move from one piece to the other. Just imagine that one of the parts is your snapshot position (from the stabilization profiles).

That's not a 100% accurate analogy because when Octolapse takes a snapshot, it doesn't extrude! This means the travel distance is about 2X what it would be if you were just printing two parts separated by the same distance.

You can reduce this effect by putting the snapshot position right over the center of your part. You can reduce it even further by taking advantage of the 'Position Restrictions' in the advanced snapshot settings (see the wiki here). They are not super simple to use just yet, but there are some enhancements in the works to make this feature more user friendly.

Your best bet for your first print would be to choose the 'Fixed - Extruder at Center' stabilization and center your part when you slice.

By the way, about that thin wall stl I suggested: That is the WORST case scenario for Octolapse from what I can tell. A lift and move here can maximally affect print quality since that part is very sensitive to oozing and movement. If you print that file you will pretty much the worst possible quality problems using Octolapse. You may not even notice any affects at all when printing less sensitive parts.

I may add a section on print quality to the wiki.

from octolapse.

I see, thank you! Yes, the extrusion detection makes perfect sense, and no, I never extrude below that, so I should be safe. I added the settings now, I'm going to try a test print to see how it goes. Do I need to enable/disable timelapse in Octoprint, or does Octolapse just disable Octoprint's timelapse completely so I can leave it alone?

I'll try to print the thin wall model as well, and I'll post the settings here afterwards if everything goes as planned. Thanks for the help!

from octolapse.

You can leave the default timelapse enabled if you want. It might be neat to see a side-by-side!

from octolapse.

Alright, it printed fine! Although now I can't find the video anywhere, hmm...

from octolapse.

Oh, and the 0.5mm wall torture test is so bad, my slicer can't even slice it!

from octolapse.

LOL! are you using Slic3r? You might need to enable thin wall detection else you'll get no paths!

from octolapse.

Alright, it printed fine! Although now I can't find the video anywhere, hmm...

Did you check the default timelapse plugin? By default they timelapses go there until I have time to create a native file browser (pain in the butt, been putting it off).

from octolapse.

Ah, you're right, it doesn't love thin walls by default. Alright, sliced! I also did find the video, I think Octoprint just hadn't scanned it yet. Here it is:

https://www.eternum.io/ipfs/QmfXsXoWqwTt7o5dyhQ7FLuw6QGCkft3QYcdieRBaj6ZS2

As you can see, the print head isn't at the same place every time, which is odd :/ If you have any suggestions, I can add them before trying the thin wall print.

from octolapse.

from octolapse.

You're right, this is an old file. I turned the default plugin off, but this means that Octolapse didn't produce a file. Maybe I just forgot to turn it on (I've never used it before, sorry). Will investigate now, thanks!

from octolapse.

I tested the above settings from @FormerLurker with priming heights of 0, 15, 20, 25, 30, and 50mm, all with the same result. First it goes to home in XYZ, moves up and primes (I think it's supposed to be doing 15mm). That is all normal behavior without Octolapse. Then it quickly translates to the start in XY, re-homes in XY, and fails, all still at the ~15mm Z height. Then I get an error that Octolapse can't render a timelapse with just 1 frame.

from octolapse.

Hmm, for me, it says "Octolapse is not running", even after the print has started.

from octolapse.

@Frankenberrypi , try setting your priming height to 0.5 and see if that helps. If not, can you submit an issue and follow the steps below? @skorokithakis, would you be willing to do this also?

Set your debug profile to 'Diagnostic - Live Print', run your print, then create a new issue and fill out the form as best you can. When filling out the form, I especially need the gcode file, plugin_octolapse.log, and settings.json. I know it's a lot of work, but if you do I'll look at it right away.

from octolapse.

Sure, doing that now. The log is filling up with an error:

  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_octolapse/__init__.py", line 958, in on_gcode_queuing
    return self.Timelapse.on_gcode_queuing(cmd, cmd_type, gcode, kwargs["tags"])

You might want to be a bit more defensive there and use .get()? I'm not sure why that argument isn't being passed.

from octolapse.

The log is already 10 MB large and it's full of just that error.

from octolapse.

What version of OctoPrint are you using (it's in the lower left hand corner)?

from octolapse.

1.3.6, sorry :/ I'll upgrade and then post again.

from octolapse.

I should DEFINITELY include a version check in the plugin startup! I made the same mistake a few days ago when I was testing on a different raspberry pi. Easy to do.

from octolapse.

Ah, 1.3.7 isn't out yet. I'll have to wait for the stable release, as upgrading by hand is going to be a hassle, sorry :/

from octolapse.

Yes, and it's generally a good idea to not require pre-release versions, as very few people are going to be running those :(

from octolapse.

from octolapse.

Yeah, makes sense (and I was afraid of that). I'll post back when 1.3.7 is available from the auto updater then, thanks!

from octolapse.

I'll submit an issue now. I just switched to 0.5 and I get this:
2018-03-24 18:54:01,929 Position - Unable to parse the gcode command: G1 Z+0.5 E-5 X-20 Y-20 F9000

...more details when I create the issue.

from octolapse.

from octolapse.

By "that file" do you mean my setup file? Here's setup.json.
https://pastebin.com/j7K5ycaL
Also, I put all of this in issue #88.

from octolapse.

Oh, @skorokithakis, I just noticed that you were not wanting to upgrade OctoPrint by hand. Well, you actually don't have to for release candidates.

Go to Settings->Software Update and click on the wrench icon. Change version tracking to 'Release' and set OctoPrint Release Channel to 'Maintenance RCs', then click save. You should be prompted to upgrade to 1.3.7 RC2 automatically!

from octolapse.

Oh fantastic, I was really looking forward to trying out Octolapse. I'll upgrade now, thanks!

from octolapse.

Alright, all upgraded and printing! It's doing a nice z-hop to the center and back, what do you need to know in the end? Whether the thin wall object printed properly? Everything seems good with the video.

from octolapse.

from octolapse.

Unfortunately, I started printing and left my printer unattended, and this happened. I think the printer centered and then stopped moving but kept extruding.

from octolapse.

Ugg.. Did you get a timelapse at least? If you were printing in diagnostic mode (debug profiles) maybe post the plugin_octolapse.log file for me to review?

That print was really looking good too!

Edit: I found logs from a later post, thanks for that!

from octolapse.

I did get a timelapse, looks like the model got unstuck, but I still don't understand why it didn't print the rest. No log, unfortunately 🙁

from octolapse.

from octolapse.

OK, I had something similar happen. I left an overnight print going (I know, not that smart when trying something new) and woke up to it stuck about half way through. In Octoprint, I hit pause, then resume, and it started printing again. It restarted just fine. I didn't have logging on, but it happened again and I heard it, so I grabbed the output from the terminal. I will turn on logging for the next several prints and report back if it happens again.

Terminal output:
https://pastebin.com/Yj7viqxj
Gcode for what I was trying to print:
https://www.thingiverse.com/thing:2839559
Settings file:
https://pastebin.com/5uLaFcdb

from octolapse.

from octolapse.

@Frankenberrypi, the lockup issue has probably been solved. If you update OctoPrint to 1.3.7rc3 it should start working! It's probably a good idea to upgrade Octolapse to v0.2.3 after you upgrade OctoPrint, though 0.2.2 should work as well. I may be pushing v0.2.4 later today, fyi.

from octolapse.

Added to v0.2.4. If anyone wants to look over the beta version, install the latest version of Octolapse first, then restore the default settings in Octolapse. You might want to export your settings.json file first, in case you want copy it back into the "~/.octoprint/data/octolapse/" directory. Please create a separate issue if you find any problems.

Whew, Thanks!

from octolapse.

Running v.0.2.5 and using the Monoprice Maker Select profile. All is working good, except retraction settings were not correct and created a bit of a mess. The defaults use .6mm, but I've been typically using between 3-6.5mm and between 3000-4200mm/m, depending on the material.

Great Plugin though, really amazing results, now I need to get a better camera. Thanks for creating this!

from octolapse.

@zjed42 Can you share what it took to get captures working with the Monoprice Maker Select? Did this work for you after modifying only retraction settings?

from octolapse.

@azide0x37, are you having troubles? @zjed42, I'll double check the default settings, thanks for the heads up!

from octolapse.

@FormerLurker wasn't getting snapshots with the default settings (My octoprint setups are all over the place, but my Cura profile is pretty much OOTB) (edit: 1.3.7-rc3/0.2.5)

I set X/Y/Z Axis Mode to Default to Absolute (using Cura 3.2.1; no G90/G91 by default) and getting snapshots and position updates now. Kicking off a non-test mode print to confirm.

This is a really neat project, btw! What an effort!

from octolapse.

Thanks, it turned into a much bigger project than I bargained for. Its almost stable now, thankfully. Still have one or tow big things to fix before v1.0.

I have seen missing g90s in lots of GCode. It seems unsafe to me, but I may end up setting xyz to absolute for this profile.

from octolapse.

@azide0x37 - To be honest, I just used the profile included and didn't change much. The Timplapse built fine without any tweaks, but I had a pile of fuzz building up in the corner, which eventually caught on the model and knocked it off. Other than that it was fine. I'd be happy to share any of my config if there's something specific you need to know that's not included, please let me know.

@FormerLurker - The only other thing that i've noticed is a significant increase in print time. 1.5hrs with octolapse turned off, and 3hrs with it on. I don't think it's due to the stabilization movement though, it just seems to run slower overall. i'm going to do a little testing and I'll let you know if i find anything that helps.

from octolapse.

@zjed42: it's certainly possible that there's an issue with Feedrate tracking. I just looked at this and can't see anything obvious, but if your gcode has LOTS of little operations you might have been running into some performance bottlenecks. There were 3 pretty big issues that have (hopefully) been greatly reduced. Some of these fixes are only in the devel branch (don't recommend you try yet, still testing):

1. Async logging - without this if you do lots of logging on slower hardware (or with slow memory cards) there could be hiccups that can translate into stalls. These can be short enough to not be noticeable visually all the time, but they were definitely having an effect. Things work much better now. In fact, Gina has implemented this for OctoPrint, so we should get better logging performance in general soon, especially for servers running with multiple cores.
2. Way too many status updates were being sent to the clients when the info panels were enabled. They are now sent at most once every second. If you had any info panels running and have a slower (wifi) network connection, this definitely could have caused some performance issues.
3. Some snapshot post processing was blocking the main thread. This includes image transposition (recently added too), thumbnail generation, and updating the latest full sized snapshot image (essentially a copy job). These processes now run in the background, though I need to add an event so that the 'most recent snapshot' is actually the most recent one. Not sure how much this would contribute to slow prints, but it certainly added to the snapshot time.

You should see a notice to upgrade to version 0.3.0 in a few days, which will contain these updates.

from octolapse.