Octolapse-Like Timelapses

Danal

@railgunner13f said in Octolapse-Like Timelapses:

I tried using telnet to connect to the duet. I can ping it fine. But the telnet fails. the Duet & the Pi are on the same wireless network.

--- 192.168.1.113 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9007ms
rtt min/avg/max/mdev = 18.092/112.886/221.724/69.362 ms
pi@octopi:~ $ telnet 192.168.1.113 23
Trying 192.168.1.113...
telnet: Unable to connect to remote host: Connection refused

Do you have telnet turned on in your configuration?

M586 P2 S1

Or M586 with no parms to read current state.

Railgunner13f

That was it! Thanks Danal. Now time for a crash course in python to figure out what to do with the telnet message.

resam

FYI: I created a tool to take timelapse snapshots on every layer change: https://forum.duet3d.com/topic/6058/timelapse-pictures-videos-with-duet-and-webcam-on-layer-change

T3P3Tony

Octolapse has now added a function to compare each picture and fire a warning if the difference is "too great"

https://twitter.com/ppaukstelis/status/1017576602266370048?s=19

punamenon

I'm working on similar. Instead of doing it every layer, I want to take the photos every 30 Seconds. Is there a way to trigger a macro to run based on a time interval?

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.