search

FormerLurker / Octolapse

Stabilized timelapses for Octoprint
GNU Affero General Public License v3.0
634 stars 99 forks source link

It's not clear what I need to put in my gcode for the gcode trigger #465

Open adcurtin opened 4 years ago

adcurtin commented 4 years ago

This seems like a dumb problem, but it's not clear to me what exactly I need to put in my gcode to trigger a snapshot.

is it a gcode command?

neither https://github.com/FormerLurker/Octolapse/wiki/Printer-Profiles#snapshot-command nor https://github.com/FormerLurker/Octolapse/wiki/Snapshot-Profiles#gcode-trigger

mention what the command is.

Any chance I could put the command for this in a gcode comment, so I never have to worry about it being sent to the printer?

Version of Octolapse

Octolapse Version: 0.3.4

Version of OctoPrint

OctoPrint Version: 1.3.12

Operating System running OctoPrint and Octolapse

OS Name: octopi Os Version: .15

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

Link to Gcode File: meh

I used SNAP in my gcode, best I could find in my searching.

FormerLurker commented 4 years ago

The snapshot command is whatever is entered into this box within your printer profile:

image

Since you are using v0.3.4 (I'm using v0.4.0rc1.dev5), your settings will look slightly different, but the default command is:

snap

There is an option in the Octolapse main settings to always suppress this command (prevent it from being sent to the printer). If Octolapse is enabled this command will NEVER be sent to the printer anyway, but if you want your gcode to run without errors from the SD card, you can change the command to:

G4 P0

That command is a wait for 0 MS, so it is pretty safe to include, even if you are printing from SD. If you are using Teacup firmware, use G4 P1, since G4 P0 is equivalent to M400 on that firmware. Waiting for 1MS is probably better than waiting for all moves to finish, though I've never run that myself.

Assuming you go the G4 P0 route, just enter that into your printer profile, add it to your layer change gcode, and you should be set. Let me know if that all makes sense, and thanks for posting!

Uko commented 4 years ago

Sorry for being stupid, but why comments are not allowed? It would be super easy if we can use something like ;BEFORE_LAYER_CHANGE which is automatically added by PrusaSlicer.

My problem is:

  1. I really don't like the idea of detecting layer change based on z-lifts when you can use a 100% correct info from a slicer.

  2. I don't like the idea of putting the fake commands into the gcode, when the data is anyway available in comments.

    In any case, I agree with @adcurtin that it's not clear how this gcode command should work. I spend a long time and it was still not clear how to use it. Maybe there can be some simple example like the one you wrote here in the answer?

P.S. As I mentioned reuse of data provided by a slicer, Octolapse could read all the printer config from a gcode directly (as the SlicerSettingsPlugin does). Because for example retraction may change based on the filament (PETG has longer retraction). But I understand that this is a big feature, so please don't treat this as a request but rather as an idea that I'd like to share with you.

FormerLurker commented 4 years ago

@Uko,

Sorry for being stupid, but why comments are not allowed? It would be super easy if we can use something like ;BEFORE_LAYER_CHANGE which is automatically added by PrusaSlicer.

Comments are purged from all gcode before they are received by Octolapse, and comment only lines are ignored by Octoprint. This is done for performance reasons, so without pre-processing this is impossible in the current version of OctoPrint. The next release of Octolapse (V0.4) actually DOES have pre-processing capability, though I have not implemented comment based layer change detection as of yet.

I really don't like the idea of detecting layer change based on z-lifts when you can use a 100% correct info from a slicer.

Layer change detection is not based on z-lift in Octolapse. It is determined by looking for the first extrusion on a given height. This is done for universal compatibility since there are many slicers out there. The solution to this in the current master release of Octolapse is the gcode trigger, unfortunately.

I don't like the idea of putting the fake commands into the gcode, when the data is anyway available in comments.

There is no need to use a fake command. You could just as easily use G4 P0 if you want, which is a real command, and unless you are using Teacup firmware, this would have no affect if you ran the gcode via an SD print. Again, regarding the comments, these are not available to Octolapse unfortunately in the current version.

it's not clear how this gcode command should work

The next version (0.4.0) has complete documentation integrated within the interface itself. Here is an example of the help for one of the printer profile settings:

image

image

Here is a link to the raw help markdown for the snapshot command within the printer profile. I didn't include a pic of this because it is quite long.

It's been very difficult keeping all of the documentation straight up until now, since a lot of things have changed with each release (github only shows the wiki for the current master). Now I'll be able to add more documentation right where it is needed, and display it all without relying on the wiki. I'll admit the documentation isn't perfect, but I try my best. Submissions are welcome :) Also, I've been mostly focusing on the next version for the last year, which hasn't left a lot of time for other things.

As I mentioned reuse of data provided by a slicer, Octolapse could read all the printer config from a gcode directly (as the SlicerSettingsPlugin does

The pre-release of Octolapse V0.4 already does this (I finished this feature early in 2019). There is new 'Slicer Type' option in the printer profile called 'Automatic' that attempts to read current settings from the gcode file. It currently supports Slic3r variants (including prusa slicer), Simplify 3D and Cura (cura requires a small set of comments to be added to start/end gcode). Since Octolapse V0.4 supports pre-processing, it has no problem extracting settings from the comments.

Because for example retraction may change based on the filament

This won't be a problem for long, due to the new settings extraction feature. In fact, Octolapse V0.4 also supports multi-material/multi-extruder printers, and can extract settings per-extruder/material (this is beta! I have a shared extruder printer, but have NOT tested on multi-extruder printers since I don't have access to one). You can also manually enter settings still if you want to. You can probably tell that I've been working very hard on these items you have mentioned for a very long time now.

I understand that this is a big feature

You are right there :) It was a lot of effort, but it was easy compared to adding the pre-processing necessary to read out comments and to generate a snapshot plan (a pre-compiled list of places where Octolapse will take snapshots).

Lastly, I wanted to point out something regarding detecting the layer change, which was your first point, but I wanted to wait until after I explained some of the changes in v0.4. It turns out that the beginning of a layer isn't necessarily the best place to take a snapshot, especially since a lot of the time this happens over exterior perimeters. Since Octolapse V0.4 can read an entire gcode file before starting (including comments), it can also see the 'feature' tags that some slicers produce. Prusa slicer will output these as long as you enable 'verbose' gcode comments. The new Smart triggers take this into account, and attempt to minimize both the travel distance and print artifacts. It builds up a list of potential places to take a snapshot and ranks them based on the estimated quality impact (outer preimeters=bad, interior perimeters = OK, infill = good, wipe tower = great). If will replace the current 'best' place to take a snapshot with one closer to the stabilization location if it finds one. It will even let you know how much travel was saved over using the standard layer change trigger (estimated, but close). There's even an option to prevent Octolapse from moving the extruder away from your model, which completely eliminates travel, though the timelapse won't be as smooth (I call this a quasi-stabilization).

The current pre-release is v0.4.0rc1.dev5, which I'm planning to promote to v0.4.0rc1 this weekend if all goes well. You can take a look at the features by reading the release notes for all versions after V0.3.4 here. You will have to scroll down a bit since there have been 5 pre-releases since then with v0.4.0rc1.dev0 being the first. If you want to try it out check out this guide, and use this URL to install when asked: https://github.com/FormerLurker/Octolapse/archive/v0.4.0rc1.dev5.zip

Sorry for writing a novel, but I enjoy chatting about this :) Let me know if you have any more questions or suggestions!

Uko commented 4 years ago

Hey @FormerLurker, that you very much for your detailed feedback, this is very informative and very kind of you to share so many details. Thank you also for your hard work, I know that it takes a lot of effort to implement this, and I didn't know that you did so many improvements in the new version. I'm looking forward to trying it out.

Thank you again for your amazing work!