I've created a printer profile repository that can be used to simplify setup for Octolapse, and I want to know how popular each Make/Model is so I know what types of printers to start with. It takes quite a while to hunt down all of the necessary settings to create a complete profile, so it makes sense to start with the popular models. If you'd like your printer to be supported, please fill out the following brief (less than one minute) survey.
If I can gather the info, you'll see your printer listed in the new Octolapse profile repository, and will be able to import settings and receive updates directly from the server.
I'm going to share any info I gather with Foosel, so this might eventually be useful for OctoPrint as well, so please fill this out if you have the time, even if you never plan on using Octolapse.
I can query (and track if opted in) firmware identifiers, but currently don't have a reliable source for printer make and model (printer profiles are free form and unreliable). This survey is fine with me.
When I mentioned Gina's name, I was thinking maybe she had this data already but I guess I was wrong. Would it make sense to add some "reliable" fields to the printer profile? I'd guess they would have to be dropdowns populated from an external source to be "reliable".
Seems like this would be good information to have.
The long term goal for printer profiles has always been to make them shareable and have a central repository, similar to the plugin repository now. The problem is that I simply haven't gotten around to do that yet. If I had, such a dropdown would be easy peasy and the data more or less reliable (we'd probably also need a "customize" option which would make things free form and hence tricky again)
@FormerLurker and me discussed a potential collaborative approach to a repository that would help him and me, but for now he needs some data that doesn't yet exist and there we go
First, thanks for contributing to the conversation!
If I recall correctly you helped me create the existing Taz-6 profile, no? I'm going through the existing profiles and I took a look at the printer profile, and noticed that the volume is a bit unexpected:
X = -20 to 289
Y = -9 to 289
Z = 0 to 250
First, I'm curious why X starts at -20, but goes only 9mm past the print volume on the right side.
Second, is the extra area defined in any default slicer profiles (are there any default slicer profiles?), or is it used only for priming? I'm wondering if users can print in this area out-of-the box, or if there is simply some wiggle room around the edges.
If it's used only for priming (like Prusa printers that prime on a special area on the bed), I have some new settings to prevent any snapshots during the priming process, and am wondering if I should enable this feature for the Taz6 and set it to allow snapshots only when X = 0 to 280, Y = 0 to 280, Z = 0 to 250.
Edit: Also, is the origin really at X= 20, Y=10, Z=10? That seems a bit odd. Perhaps you would be willing to send a G28 + M114 and post the resulting location returned from your printer?
My printer is a Robo C2 for what it's worth. From what I understand, they sold a half a million printers in 2017 and a million more in 2018. Only my own would, in theory, show up in foosel's statistics since I've replaced their forked software. And yet, it's still OctoPrint under the hood.
Don't forget to check the Printer Profile thread in Guides, making sure to scroll that table so that you can see all the data.
The build volume of the LulzBot TAZ 6 is 280x280x250. There is a z-min switch and a nozzle wipe pad between x=-20 and x=0. There are 4 corner washers that hold down the glass bed that are also used for 4 point auto level and they are at (-9,-9), (289,-9), (289,289), and (-9,289). I believe y can go close to -20 as well. The area(s) outside the build volume cannot be used for printing. All the slicers I use are set to 280x280x250 with 0,0 in the lower left.
The […] are suppressed temperature reports and I threw in a G29 for good measure.
Send: G28
[...]
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
[...]
Recv: X:-19.00 Y:258.00 Z:10.00 E:0.00 Count X:-1910 Y:25929 Z:16000
Recv: ok P15 B4
Send: M113 S2
Recv: ok P15 B4
[...]
Send: M114
Recv: X:-19.00 Y:258.00 Z:10.00 E:0.00 Count X:-1910 Y:25929 Z:16000
Recv: ok P15 B4
[...]
Send: G29 V4
Recv: G29 Auto Bed Leveling
[...]
Recv: Bed X: -9.000 Y: -9.000 Z: 0.496
[...]
Recv: Bed X: 288.000 Y: -9.000 Z: 0.507
[...]
Recv: Bed X: 288.000 Y: 289.000 Z: 0.490
[...]
Recv: Bed X: -9.000 Y: 289.000 Z: 0.225
Recv: 4th probe point, distance from plane: 0.25
Recv:
Recv: Eqn coefficients: a: 0.00046465 b: -0.00048238 d: 0.43221545
Recv: Mean of sampled points: 0.42950000
Recv: Recv: Bed Height Topography:
Recv: +--- BACK --+
Recv: | |
Recv: L | (+) | R
Recv: E | | I
Recv: F | (-) N (+) | G
Recv: T | | H
Recv: | (-) | T
Recv: | |
Recv: O-- FRONT --+
Recv: (0,0)
Recv: -0.20412 +0.06037
Recv: +0.06613 +0.07763
Recv:
Recv:
Recv: Corrected Bed Height vs. Bed Topology:
Recv: +0.00000 +0.12650
Recv: +0.12650 +0.00000
Recv:
Recv:
Recv:
Recv: Bed Level Correction Matrix:
Recv: +1.000000 +0.000000 +0.000465
Recv: +0.000000 +1.000000 -0.000482
[...]
Send: M114
Recv: X:-9.00 Y:289.00 Z:6.28 E:0.00 Count X:-904 Y:29044 Z:10038
Recv: ok P15 B4
Thanks for the detailed info, that should be very useful. It looks like the after home position is X-9.0 Y289.0, which is very useful for me to know as well. It also makes me realize I need different terminology for this in the printer profile since your origin is in the lower left at 0,0, but the homing position is at -9.0,289.9. This is useful for me because when I pre-process gcode I don't know where the extruder will be after a G28, and can't request the position from the printer. With that info I will have a pretty good guess.
From what I have seen (though I don't use it, as it messes up prints) Octolapse relies a lot on slicer settings. I can understand some benefits from having a good profile for several printer types, but it takes a lot more to set up Octolapse than just a printer profile.
While some folk might be upset with me for saying that Octolapse messes up prints, when you have to move the extruder away from the part at every layer, it's unfortunately going to ooze filament.
Maybe someone has a method of solving this, but I haven't heard about solutions using retract settings so I would appreciate feedback from anyone using Octolapse what hasn't had a resulting print quality problem.
@Al_Wilson, I'm not upset, it's nothing I haven't heard before Print quality is my #1 concern, and I've been hard at work on this since I released the plugin. I love talking about this, so excuse the novel I'm going to write.
I've helped dozens of people troubleshoot quality issues, and there are three general categories I see most often:
Slicer/Printer settings within Octolapse aren't entered correctly - This is by far the most common problem I see. Lots of people mistakenly believe that the slicer settings within Octolapse need 'configuration', but they really just need to be copied exactly from whatever slicer you are using. This is obviously an error prone operation (I made mistakes myself all the time), and requires a lot of diligence and care from the user. Additionally, there are lots of extremely important printer settings that are hard to get right, which is why I've created the server profile repository!
Printer isn't tuned - If a printer isn't capable of printing a quality print without Octolapse, it certainly won't create a quality print with it. That doesn't mean any given print won't look good, but if temperature, ooze or other quality test prints don't look good without Octolapse, things will only get worse when using Octolapse (especially the current version).
Bugs when using absolute extrusion - The latest release has some issues in some cases when using Absolute extrusion (the default in many slicers). I developed Octolapse while using a Prusa MK2 and Slic3r, which use relative extrusion, so absolute extrusion wasn't tested as much as relative. I think I have most of these issues fixed.
I won't lie and say there is 0 quality impact when using Octolapse, but I'm working to get it as close to 0 on a properly tuned printer as possible. Here are some unreleased features that are in the next version to deal with some of these problems:
Automatic slicer settings extraction - This should eliminate the problem of copying in slicer settings as long as you are using Slic3rPE/PrusaSlicer, Simplify 3d, or Cura (Cura requires that a short script be placed in your start/end gcode in cura for this to work).
Server profiles - This should make it much easier to get the printer configuration correct. As long as a profile exists, and you select the correct make/model, this problem should be solved.
Smart Layer Trigger - Previous versions of Octolapse could only read gcode in real time as it is being sent to the printer. This is a big handicap when it comes to picking a good spot to take a snapshot. The new smart layer trigger reads through the entire gcode file, and can make much better decisions about where to take a snapshot. It's capable of reducing the travel distance by choosing a closer point to start the snapshot process, and has a ranking system to determine the impact on printer quality of inserting a snapshot action at any point in the gcode file. It has several different modes ranging from 'Fastest' (closest point to snapshot position) to 'Highest Quality' (only take snapshots when already retracted), and several options in-between.
'Snap to Print' smart trigger mode - Snap to print is an option available in the new smart layer trigger. It prevents the extruder from leaving the print, and attempts to stabilize the timelapse as much as possible. I've been able to create great looking single wall vase mode prints with minimal quality impacts using snap to print. It's not zero impact, but on a properly configured machine it is difficult to tell the difference between prints made with and without Octolapse enabled. Obviously the timelapses aren't quite as smooth, but the resulting video is much better than one would expect with a camera on a timer.
I've been working these features and more for the last six months or so, and things are finally starting to come together. I'll probably push a development release soon (though I've been saying that for over a month now) and will need testers if anyone is interested. I'll create a post in the plugin category when the dev release is ready.
As of today I've received 50 responses, thank you so much folks! At this rate I'll hit my goal of 100 responses within two weeks, and will consider this survey a huge success. If you're reading this and haven't taken the survey, please do so we can get to my arbitrary goal
@FormerLurker Thanks for your response, and also for the novel
I'm generally very happy with the quality of the prints I get from my CR-10 and MicroSwiss extruder after getting the retraction right (4mm) so any ideas about tuning settings to avoid blobs when the extruder returns to the print would be great.
I like the sound of the automatic slicer extraction. I once wanted to make a vb.net application for converting between Cura and S3d, but for one of them (can't remember which) I could not find the file containing the settings.
Best of luck with your continued work. I really appreciate the effort people go to in creating and sharing plug-ins. It's a skill I would like to develop myself!
Definitely cura. S3d packages all settings within the gcode file, but cura only shows the changes from the default setting. You can add this script to your Crua gcode to get access to all of the settings. That was created by tjjfvi, and is generated from cura's settings XML file using a javascript routine that user created.
It's very very tricky to convert settings from one slicer for use with another. For a moment I had routines implemented that could translate the speed settings from one slicer to another, and eventually gave up due to the complexity of all of the various edge cases. It was really crazy, and I have removed all of that functionality (and the associated slicer settings) from Octolapse in favor of less complicated and more reliable methods of getting quality prints (smart layer trigger).
Regarding your Octolapse quality issues, feel free to post an issue here, and I'll take a look as soon as possible.
Octolapse does not (yet) fully support multiple extruders It will work, but might yield poor quality if the retraction settings aren't the same for each extruder.
Print quality is my 
It will work, but might yield poor quality if the retraction settings aren't the same for each extruder.