Trigger Position Restrictions about octolapse HOT 10 CLOSED

This has been implemented, including the newly added 'forbidden' and 'required' types. I have written some tests, and have had success in the virtual printer, but have not fully tested all possibilities on an actual printer. Here are the scenarios for each of the three triggers (timer, gcode, layer/height):

One required position - snapshots can only trigger within the provided shape (circle and rect)

Multiple required positions - snapshots can only trigger within the provided shapes (circle and rect)

One forbidden position - snapshots can only trigger outside of the provided shape (circle and rect)

Multiple forbidden positions - snapshots can only trigger outside of the provided shapes (circle and rect)

Mixed forbidden/required positions - snapshots cannot trigger inside of any forbidden positions. If not in a forbidden position, the snapshot can only trigger inside one of the required shapes (circle and rect).

I'm changing this to 'Needs Testing'

from octolapse.

I'll give this a test on my mk3.

from octolapse.

This is more a note for when these get documented, something I've learned from experimenting with it.

If the bounding box is too small and the move command passes THROUGH it, without stopping IN IT, then the trigger will not fire.

As an example: say you have a model that is a square, centered on 100,100, with a side of 100, and say it is rotating clockwise as it goes up, 1/4th turn every 10 layers. So every 10 layers up it will have spun back to effectively the same position, the "top" and "bottom" lines will be at 50 and 150.
Assume for the sake of simplicity that you are printing hollow, just the outer shell. (in other words, pretend it is vase mode, without the complicated height changes.)

Now, say you set a restriction box from 95,100 to 105,500. So it is 10 wide and stretches from the "center" of the square up through the top, well past any maximum that the square will rotate through. That box is connected to a layer change restriction, and all other restrictions in terms of extruder, axis, etc are disabled.... you are PURELY looking for the print head passing through the box, once per layer.

If that box is rendered with four moves, from corner to corner to corner to corner... it will not trigger on the first layer. Nor the second, third or (probably) fourth. The fifth layer (cube is now 1/2 way rotated, is a diamond with top/bottom points on the 100 line) will trigger a snapshot, as the top point is within the bounding box. Sixth (probably), Seventh, eighth, ninth and tenth layers will not capture either.

(I say probably on the 4th and 6th layers purely because I've not done the trig to figure out if they would land a corner in the capture box.)

On the other hand, if that box is rendered with 80 moves, each 5 long turning every 20, then you WILL capture an image on every frame, as at least one movement command will end/begin within the capture box on every layer. (If this isn't clear, let me know and I'll draw up some pictures.)

Edit to add, you can see the skipped captures in this octolapse: https://cabbey.smugmug.com/Fun/3D-Printing/i-2Lk75Sh/A every time the top of the print jumps way more than 0.2mm per frame... yeah, that's when the lines that made up the vase mode print were longer than the 2mm wide restriction box I had configured for this print.)

from octolapse.

I anticipated this scenario, but haven't thought too much about documentation. Maybe I should start that. It is still a cool video.

I was thinking that it would be possible to intercept and add another GCode between any extrusion line that enters the restriction. Not easy, but possible. I'll think about this.

from octolapse.

Hey, I'm going to close this out now in favor of issue #76 - Test Trigger Position Restrictions.

Also, I added the intersection detection! It's super Beta right now, but it's pretty neat. Now Octolapse will detect intersections and break the current GCode up into two smaller units so that you're guaranteed to hit the position restriction!

Lastly, what do you think about me moving the restrictions outside of the layer/timer/gcode trigger section so they are all in one place? I'm having a hard time coming up with a reason to have alternative restrictions for the different types of triggers.

from octolapse.

Heh, that solution sounds exactly like what I was thinking of doing! Only concern with the split up is the accuracies of FP math needed to do it... the line may not end up quite as straight or extruded quite as well as it should have if the math isn't super accurate.

I've been thinking about the restrictions change you propose. I think it makes sense. When it comes to snapshots you have a set of events that can trigger a snapshot (layer change, timer, code sensed) and you have a set of positional restrictions, either positive or negative that those triggers need to respect. I think it makes a lot of sense to split them up into separate profiles.

from octolapse.

Oh, it's accurate enough. Way past the accuracy of the printer. I tested it with a thin wall test (20mm high, 21.5mm width and depth with a single edge) rotated 45 degrees, and it worked perfectly. I even did a print with absolute E movements and it worked too! There were marks on the print where it moved to take a snapshot, but it was impressively small (I'll post a pic later).

I was able to test with the circular and the rectangular restrictions. Also, I moved the restriction settings out of the individual trigger sections and into the advanced settings at the very bottom. I figured why in the world would anyone want to treat the timer/gcode trigger differently than the layer trigger! It greatly simplifies testing.

Lastly I further improved the extruder calculations. There were some rounding issues in general (not just with position restrictions). This has been basically eliminated down to 5 decimals. There were also some problems switching back and forth from absolute to relative extrusion which I have fixed, among other various improvements. I've been getting GREAT quality recently, especially when using the new position restrictions. Depending on your print, you might be able to make a timelapse with 0 quality impact except a tiny dot on the very top layer! I could add a max-height feature to eliminate that too :)

I'm psyched about this feature. Just have to make it easier to configure. I can't tell you how many times I've messed up just a little bit configuring the restriction. I might add a 'Center' button or something else to assist. I thought about adding an HTML5 canvas that you could click, but I'm not sure the accuracy is high enough. It might be good enough for most cases, however. I might also add a profile for the default prusa MMU wipe tower location. Let me know what you think.

from octolapse.

from octolapse.

Good idea about the canvas as just an indicator. I already have some javascript for plotting the current X,Y position (unimplemented, but it's there).

Also, that's an interesting idea about the definition of a rectangle. The variables would be difficult to validate, but maybe it's possible. What about some different ways to enter a rectangle? Maybe a width, height and a center point? Maybe both options (two coordinates or a center, length and width)? I'm trying to imagine what the UI would look like for that.

Oh, I thought I'd also mention I'm getting the git wiki filled in. It's a grueling process, but hopefully it will help some folks. I realized I didn't know exactly how some functions behaved until i tried to put it down on paper!

I hope you dig yourself out from under your pile of work! Good luck there!

from octolapse.

from octolapse.