Octolapse-Like Timelapses

[resam]

If you want to make it every 30 seconds - what do you need a macro for? You don't even have to use a slicer plugin - just a simple script to take the picture on you webcam / Raspberry Pi:

while True:
    takePicture()
    time.sleep(30)

[punamenon]

Because I'm not using a Raspberry Pi, or a webcam. I'm trying to accomplish it all through the DUET.

[AlexLin]

Use an mobile phone's audio jack (4 connections) and connect it to the Duet Wifi trhough an opto coupler. the pin connects the pin on the audio jack to ground (i think with 200ohm).Then the phone takes an image.
The G-code is modified through a script that adds g-code on each layer that moves thehead to a fixed position toggles the pin.
link text

[punamenon]

@alexlin said in Octolapse-Like Timelapses:

The G-code is modified through a script that adds g-code on each layer

This is the same approach as discussed previously. I'm trying to trigger the event not on layer change, but instead at a specified time interval.

[AlexLin]

@punamenon if you want to do it at certain time intervals and with no relation to the g-code, I would just use an external controller like and arduino/attiny...you can then still connect an io from the Duet to the Arduino to indicate when to start/stop a timelapse.

[punamenon]

@alexlin This is probably what I will resort to, but I shouldn't have to. The Aduino DUE which the DUET is based off should have full clock functionality. We just need to get a timer implemented in the firmware. I wish I was a programmer, I would join the Dev. team.

[AlexLin]

@punamenon I agree that what I miss most with the Due vs Octoprint is the possibility to add plug-ins like Octoprint has

[punamenon]

I've succeeded in accomplishing Octolapse-Like Timelapse videos without using a raspberry pi: https://youtu.be/CwHVQ81GfXw

Total project cost was under $10

It would still be nice to be able to trigger photos based on a time interval.

[Phaedrux]

@punamenon nicely done.

[Phaedrux]

@punamenon now I understand why you were asking about running the pause and resume macros before.

But I'm wondering why you didn't just use M226 to pause. Nevermind. I understand now. M226 can only be resumed manually.

I suppose Instead of pausing you could have inserted a retraction and G1 move to get the head out of the way, trigger the photo, and then the print head should move back to where it's needed to continue the print, shouldn't it?

[punamenon]

@phaedrux Wow, that would be cleaner! I should test it.

I was originally trying to accomplish it all through macros where I inserted a single line into the Gcode at each layer change: M98 Ptake_a_photo.g

Within that Macro I was trying to call pause.g and resume.g which lead to the problems with the parser that I also made a post about. With your simplified approach, I might be able to get it to work the way I was originally trying. I'll do a little testing tomorrow, and let you know how it turns out.

[Phaedrux]

@punamenon

Assuming you're using firmware retraction you can use G10 and G11 to retract.
G1 X0 Y0 F6000 to move the head to home. The faster you can do this, the better for oozing. Trigger your photo. Unretract. Then I would think that because it's absolute coordinates it should move to the next layer height and continue. Actually, if you insert your code AFTER the layer height move, and you have retract on layer change, it will already handle the retraction for you, and give you some clearance from the printed part for the travel move out of the way.