[Request] Octolapse as DSLR trigger only, no transfer to Pi nor encode.

[chilicoke]

If this is a feature request describe it here

I just set up an DSLR following your excellent tutorial. However I'm looking to simply use Octolapse as the camera trigger, and would like to keep the captured images on the SLR's memory card to be later processed on my computer, so I can start another print right after instead of waiting for Pi to be ready again.

My guess is this is already possible given the current DLSR instruction is already doing a lot more, however I only have basic knowledge in Linux so am curious to learn what steps to modify to not transfer the photos not render timelapse on Pi

Currently, there is about 3-4 seconds of pause after I hear the shutter before next layer starts, am I correct in assuming that this is due to Octolapse waiting for the image to transfer via USB? If the images stay on the camera could this pause be minimized or eliminated?

Thank you very much!

Version of Octolapse

Octolapse Version: v0.3.4

Version of OctoPrint

OctoPrint Version: 1.3.9

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: YES_OR_NO

What were you doing when the problem occurred

1. STEP_ONE_GOES_HERE
2. STEP_TWO_GOES_HERE
3. STEP_...

What should have happened?

PUT_YOUR_DESCRIPTION_HERE

What happened instead?

PUT_YOUR_DESCRIPTION_HERE

Operating System running OctoPrint and Octolapse

OS Name: OS_NAME_GOES_HERE Os Version: OS_VERSION_GOES_HERE

Printer model & used firmware incl. version

Printer Model: PRINTER_MODEL_GOES_HERE Printer Firmware Version: PRINTER_FIRMWARE_VERSION_GOES_HERE

Browser and version of browser, operating system running browser

Browser: BROWSER_VERSION_GOES_HERE Browser OS: BROWSER_OS_GOES_HERE

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

Link to Gcode File: GCODE_FILE_LINK_GOES_HERE

Link to settings.json

Link to settings.json with all passwords removed: SETTINGS_JSON_LINK_GOES_HERE

Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE

Link to octoprint.log

Link to octoprint.log: LINK_GOES_HERE

Link to contents of Javascript console in the browser

Link to javascript console output: LINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: LINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

[chilicoke]

thank you very much, I really appreciate all your contribution!

Kai

On Thu, Dec 13, 2018, 1:06 PM NinjaMojo <notifications@github.com wrote:

Hi again! I wanted to let you know that I haven't forgotten about this, and will get the guide created ASAP (hopefully this weekend). If you are good with Linux I have the scripts finished and can give you a quick rundown. Let me know.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/284#issuecomment-447120689, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEML2yCR80zURIFnUNVLoUpY_kkK3wTks5u4sFqgaJpZM4ZJezv .

On Thu, Dec 13, 2018 at 1:06 PM NinjaMojo notifications@github.com wrote:

Hi again! I wanted to let you know that I haven't forgotten about this, and will get the guide created ASAP (hopefully this weekend). If you are good with Linux I have the scripts finished and can give you a quick rundown. Let me know.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/284#issuecomment-447120689, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEML2yCR80zURIFnUNVLoUpY_kkK3wTks5u4sFqgaJpZM4ZJezv .

[FormerLurker]

@chilicoke, I wanted to let you know that I haven't forgotten about you! I've been under the weather, which has slowed me down considerably. This is still on my radar though!

[chilicoke]

thank you very much for keeping my updated, you are very kind.

-Kai

On Tue, Dec 18, 2018 at 9:17 AM FormerLurker notifications@github.com wrote:

@chilicoke https://github.com/chilicoke, I wanted to let you know that I haven't forgotten about you! I've been under the weather, which has slowed me down considerably. This is still on my radar though!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FormerLurker/Octolapse/issues/284#issuecomment-448298760, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEML53tBZFCTH4U1pq_D7faRO_r2cIJks5u6SMngaJpZM4ZJezv .

[FormerLurker]

Here is a draft guide. Some things aren't finished, mostly dealing with testing. I'll be testing and updating this throughout the week. Let me know if you have any problems/suggestions, or if things work great!

Thanks!

[chilicoke]

Thank you very much FormerLurker.

I've tested it over the past day with my Pi 3B that I set up over a year ago and a new set up of 3B+ with a Canon 350D (RebelXT) and Sony Alpha A5000 with mixed results.

When I follow your guide to Step 3 /home/pi/scripts/initialize-camera-save-to-sd.sh , I get the follow error with either combination of Pi and cameras

pi@octopi-portable:~ $ cd /home/pi/scripts
pi@octopi-portable:~/scripts $ nano initialize-camera-save-to-sd.sh
pi@octopi-portable:~/scripts $ chmod +x initialize-camera-save-to-sd.sh
pi@octopi-portable:~/scripts $ /home/pi/scripts/initialize-camera-save-to-sd.sh

*** Error ***
capturetarget not found in configuration tree.
*** Error (-1: 'Unspecified error') ***

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt --set-config capturetarget=2

Please make sure there is sufficient quoting around the arguments.

pi@octopi-portable:~/scripts $

I want to primary use this with my Canon Rebel so I tested it with the next command /home/pi/scripts/trigger-snapshot.sh, but got the follow error:

pi@octopi:~/scripts $ /home/pi/scripts/trigger-snapshot.sh
Detected a 'Canon:EOS 350D (normal mode)'.

*** Error ***
This camera can not trigger capture.
ERROR: Could not trigger capture.
*** Error (-6: 'Unsupported operation') ***

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --debug-logfile=my-logfile.txt --trigger-capture

Please make sure there is sufficient quoting around the arguments.

I didn't expect this to work since initialize-camera-save-to-sd.sh from previous step already errored, but then I remembered the gphoto2 --capture-image command from your first DSLR guide, so I replaced gphoto2 --trigger-capture within nano trigger-snapshot.sh with gphoto2 --capture-image and for some reason, my Canon Rebel actually saves the image onto the memory card while my Sony A5000 (USB connection: PC Remote) does not.

As an experiment, I edited and commented the other parts of nano trigger-snapshot.sh as below:

#!/bin/sh
# Camera Capture Script - Leave on Camera, Don't download
# Requires a camera initialization script with the following command:  gphoto2 --capture-image --set-config capturetarget=2
# Written by: Formerlurker@pm.me
# Put the arguments sent by Octolapse into variables for easy use

#SNAPSHOT_NUMBER=$1
#DELAY_SECONDS=$2
#DATA_DIRECTORY=$3
#SNAPSHOT_DIRECTORY=$4
#SNAPSHOT_FILENAME=$5
#SNAPSHOT_FULL_PATH=$6

# trigger the camera and exit immediately
#gphoto2 --trigger-capture
gphoto2 --capture-image

Then disabled OctoLapse's rendering, edited Camera Snapshot Acquire Script to /home/pi/scripts/trigger-snapshot.sh and was able to produce a fairly rough print but relatively successful result.

After some print quality tune ups I went for another timelapse test. However this time print failed half way through, OctoPrint was unresponsive, Pi didn't respond to SSH, and after a few minutes the heatsink on my Pi processor was burning hot.

Here's the log it captured after I let the Pi cooled down enough to boot. octoprint.log

Would really appreciate your help, I'm running another test now and monitoring Pi's temperature, curious if my edits caused something to crash and overheat?

Also, any way to get rid of this snapshop_script_error now that pictures aren't being sent to the Pi anymore?

Thank you very much once again. -Kai

[FormerLurker]

@chilicoke, you may have missed one step from that guide. Increase your 'Snapshot Timeout' to say.. 10 seconds? If it's usually working with only a 2 second timeout, that's pretty great for a DSLR!

Regarding the heat issue, I'd think about adding/replacing your heatsink. Personally I've never had any temperature issues, though my Pi is outside of my enclosure, The 3B+ should have two heatsinks, one on the top and another on the back.

However, your first attempt looks GREAT! See if you can get 'high quality mode' up and running. I bet you'll be pretty happy with the final quality of the print!

[FormerLurker]

@chilicoke, I almost forgot. When I update the guide I'll add some troubleshooting steps for the camera initialization script. Apparently your camera does not support the option, and you've obviously found a workaround. I've been getting better results with gphoto2 --trigger-capture (lower delays), but every camera operates differently.

Thanks for your updates!

[chilicoke]

@FormerLurker, You're right, I just did another test and setting it to 10 seconds prevented the error. I was initially trying to minimize the amount of delay between each layer as much as possible. Now with 10 seconds time out I no longer see the error and it seems like the pause has increased by about 6 seconds. My guess is my camera receives the command to capture, then saves the image to memory card, makes sure the save is complete, then sends back a OK signal to back to Octolapse.

Other cameras (such as my A5000) does not save image to memory card with just gphoto2 --trigger-capture or gphoto2 --capture-image without some sort of additional help such as your initialize-camera-save-to-sd.sh script, so in this case, the dumber older DLSR seems to work in its favor.

In my Rebel XT's case, it appears to be able to capture a good still image and have print head move onto next layer without any additional delay just fine when timeout is set to 2 seconds. Is there any way for me to change Octolapse to not wait for or ignore the OK signal from camera to prevent the Camera error?

Regarding the heat issue, I did a few more identical print tests last night while monitoring Pi temp, they all worked just fine and no noticeable raise in temperature, it was probably just a fluke and the crash drove my Pi into thermal shutdown.

Can you please give a quick explanation between Compatibility mode and High Quality mode? I looked though the settings for both and didn't see any obvious indications. I'd be doing more testing with setting of course, just would prefer to start from the preferred mode.

Thanks again for all your help, Octolapse is quite incredible.

[FormerLurker]

@chilicoke,

The timeout by itself should NOT increase the time it takes to capture an image, but would terminate the process early if it doesn't finish, which is what I believe is causing the extra delay when using the --capture-image flag.

So, the --capture-image flag waits until the image is saved to the SD, which would still probably save time over a USB transfer. However, the --trigger-capture flag returns BEFORE the camera reports success, which would be right after the image is acquired but BEFORE it is saved. I'll do a bit of research to see if there's some other way to accomplish the --trigger-capture without waiting for the SD to finish writing.

Regarding compatibility and high quality mode - Compatibility mode will take a picture as soon as it can after Octolapse detects a new layer. The 'High Quality' mode will only take snapshots over certain parts of the print (by default, Interior Perimeters, Infill, Solid Infill, Top Solid Infill, Gap Fill and First Layers). It does this by calculating the speeds for these features from your slicer settings. See this wiki on the subject (feature detection) and check out this configuration video to make sure things are configured correctly. Be sure to look through the 'High Quality' profile settings so you can see how it's configured. Let me know how it turns out or if you have any more questions!

[FormerLurker]

@chilicoke,

You should be able to run the following command to test the capabilities of your camera:

gphoto2 -a

Then try running this command to see what options are available for the capturetarget:

 gphoto2 --get-config capturetarget

That should give us some idea of what we have to work with. The gphoto2 Remote controlling cameras list seems to include your camera, and states that you should have access to all features. I'm not sure how accurate the list is, but it's worth trying all of the above IMHO.

Can you send me a copy of the console output for both of the above commands when you have a chance? Thanks!

[chilicoke]

Canon Rebel XT:

pi@octopi:~ $ gphoto2 -a
Abilities for camera             : Canon Digital Rebel XT (normal mode)
Serial port support              : no
USB support                      : yes
Capture choices                  :
                                 : Image
                                 : Preview
Configuration support            : yes
Delete selected files on camera  : yes
Delete all files on camera       : no
File preview (thumbnail) support : yes
File upload support              : no
pi@octopi:~ $ gphoto2 --get-config capturetarget
Detected a 'Canon:EOS 350D (normal mode)'.
Label: Camera and Driver Configuration
pi@octopi:~ $

Sony A5000 (PC remote mode):

pi@octopi:~ $ gphoto2 -a
Abilities for camera             : USB PTP Class Camera
Serial port support              : no
USB support                      : yes
Capture choices                  :
                                 : Image
                                 : Preview
Configuration support            : yes
Delete selected files on camera  : yes
Delete all files on camera       : no
File preview (thumbnail) support : yes
File upload support              : yes
pi@octopi:~ $ gphoto2 --get-config capturetarget
Label: Camera and Driver Configuration
pi@octopi:~ $

Both of these camera seem to have noticeable different behavior with gphoto 2, I'll do a bit more testing. Meanwhile I'm also trying different combinations of delays and high quality mode.

[FormerLurker]

@chilicoke, not sure what version of gphoto2 you are running, so you might want to look into this updater. OctoPi changes the behavior of git somewhat, so a slight change to the script may be required. Check out this issue that I created on the gphoto2 github page, which explains how to change the script for OctoPi.

The reason I'm suggesting this is that your Rebel looks like it's being detected as an EOS when using the --get-config flag. Perhaps this has been fixed? If not, it might be worth posting an issue on the gphoto2 git page to see why you can't change the capture target on your Rebel. Also, perhaps there is another way to accomplish this?

[chilicoke]

I went ahead and updated both versions of gphoto2 on both my Pi to the latest version to minimize variables, and are getting the same result.

Seems like it's hard to find the right balance between camera and desired performance. The Rebel XT appears to be too old to support certain functions, so I got my hands on a Sony A6000, which takes substantially better pictures and and supports gphoto2 --trigger-capture, however after many testing only to find that Sony cameras' (specifically Alphas) firmware simply don't allow memory card write/access when it is connected via USB remote mode. Which in my case is actually a step backward from the old Canon Rebel XT with timeout set to minimum (2.8-3.2 seconds) and ignore the snapshot_script_error (any possibly to add toggle to prevent this error in future release). However I still desire to move away from that camera due to multiple reasons, mainly performance and storage type.

I think I will most likely pursuit using Pi's GPIO to do an external shutter trigger with Sony A6000 to further minimize capture delay and keep the images outside of Pi.

On another note, I've also been experimenting with 'high quality mode', and noticed that Octolapse does not get triggered right after layer change, but rather after first extrusion on the new layer; which causes the extrude to retract twice (first on layer change, then another after the first small extrude for Octolapse) and leaves a little bit of blob on the inside premiere of the new layer.

Curious how would I improve this so it triggers right after nozzle lift on layer change.

Much appreciated!

[FormerLurker]

I will add a toggle for you, or some other means of suppressing the error. Too bad about your camera issues :(

Regarding high quality mode, are there any errors listed in either snapshot settings (feature detection area), or around your slicer settings in the print profile? Non-unique or missing speed settings can mess high quality mode up.

Shoot me your settings json and the gcode file and ill take a look.

Im actually revamping that feature as we speak. It should be much easier to work with then.

[FormerLurker]

Hey, i had time to more closely examine your video. Not sure what is up with the double retraction!? I'll look into that once I receive your settings and gcode. However, you can just turn off snapshots for inner and small perimeters (depends on the slicer) so that any blemishes occur on infill (in the layers pictured). Check out the snapshot settings under feature detection and turn off inner (and small if available) perimeters and see what happens. I've not had problems taking snapshots over inner perimeters, though that could be a result of the materials I'm using and/or my printer settings.

Also, what a great video! That obviously took some effort. I appreciate it!

[chilicoke]

Thanks again!, I re-read all your FAQ on each settings a little bit closer and realized that Octolapse is looking for the first extrusion gcode on the new layer to act as trigger? If so that completely explains why I'm seeing a little bit of extrusion before the nozzle move into position for snapshot. Maybe I just need to experiment with both Cura and Octolapse options a bit more. I don't want to trouble you too much for now as I would like to get camera to trigger reliably first.

Regarding my issue with camera trigger, I raided my hoarder bin and was able to build a little break out board using Pi's GPIO + transistor + 2.5mm headphone jack to act as an external shutter trigger for my camera, testing with Canon Rebel for now, but I'm 99% sure it will also work with Sony A6000 once the adapter cable comes in.

I have laughably minimal scripting knowledge from many years ago, but was able to cobble together (after lots of Google search) the below code and was successful in triggering a 0 delay shutter on my Rebel with sudo python /home/pi/scripts/external-camera-trigger.py shell command via SSH.

#!/usr/bin/env python

import RPi.GPIO as GPIO
import time

GPIO.setwarnings(False)

GPIO.setmode(GPIO.BCM)
GPIO.setup(21, GPIO.OUT)

GPIO.output(21, True)
time.sleep(0.2) 
GPIO.output(21, False)

print "Done..."

However, how to get this little python script to work with Octolapse is where my lack of knowledge shows, I understand that we created a bash script in your original guide and it contains the parameters Octolapse is looking for. In this case, how do I get my above script to work as Snapshot Acquire Script,

I'd imagine I would also probably need to add a small amount of delay after shutter trigger to prevent nozzle movement before camera shutter closes. Another reason I decided to go with GPIO route is to later add in relays to triggers lights to only come on for the time lapse for those long overnight prints.

Once again THANK YOU SO MUCH for all your help.

[FormerLurker]

That is a dang good job you did there! I've been meaning to try something like this for a long while, but never got around to it. Mind if I snag your code and use it as an example in the wiki?

It would be pretty easy to create a .sh script to call your python script (you already have the only command you need above!) The variables passed into the script aren't necessary, since you won't be copying any images back onto the pi. If you disable the rendering profile you shouldn't get any errors after the print is complete complaining about missing snapshots.

The hard part will be to get python to run without sudo. In the short term it's possible to add your password to the script itself, but this isn't really very good security practice. I'll do some research to see if there is an alternative.

Here is something you can use in the meanwhile for your script:

echo "PUT_YOUR_PASSWORD_HERE" | sudo -S python /home/pi/scripts/external-camera-trigger.py

Don't forget to give the script you create execute permission!

[chilicoke]

Mind if I snag your code and use it as an example in the wiki?

Of course! it's the little amount I can contribute.

I just tried using echo "paswd removed" | sudo -S python /home/pi/scripts/external-camera-trigger.py into Snapshot Acquire Script but got no shutter and this error message when printing:

[FormerLurker]

That means that subprocess.Popen is not returning a process, which means the command probably isn't working. Can you run the .sh file manually?

Also, try adding this as the very first line:

#!/bin/sh

[FormerLurker]

OH.. Hold on. So the snapshot acquire script setting in the camera = echo "paswd removed" | sudo -S python /home/pi/scripts/external-camera-trigger.py?

That won't work. I execute the command with popen and forbid direct shell access. Don't want hackers sending arbitrary commands to your instance :)

Put that code in a script file at /home/pi/scripts/external-camera-trigger.sh, then set your snapshot acquire script to: /home/pi/scripts/external-camera-trigger.sh

Make sure you give the sh file execute permissions via

chmod +x /home/pi/scripts/external-camera-trigger.sh

[chilicoke]

Awesome! that worked! no errors either!

Doing a preliminary test print right now and so far the performance seems impressive. I've added a .75 second delay after shutter release which gives a total of 1 second "pose time" from initial shutter trigger to allow longer exposure if needed, and the total amount of "capture time" is impressively low, I believe I can probably lower the post shutter delay down to .25 seconds since exposure longer than 1/2 second is unlikely and the whole process took so little time that I might even be able to set retracting back to normal.

https://www.youtube.com/watch?v=cXKJ8MSC_tc&feature=youtu.be looking at that recorded clip sound wave, the total amount of time the nozzle poses (when motors aren't making noises) is actually 1.04 seconds. so basically spot on.

I'll report back after a few more tests.

Thanks a ton!

[FormerLurker]

That looks great! Really nice, seriously.

You can probably turn the snapshot delay (camera settings) down to 0 since that happens before the script is executed. Also, more light = shorter exposures, so that might speed things up a bit too.

What you achieved is similar to what my camera does using the -trigger-capture flag. You should write a guide up! Would be great for people with cameras that don't support that feature.

[chilicoke]

Thanks again for all your help, the result turned out great. I already had delay setting on 0 before, and I've further reduced after shutter wait down to 0.2 second and it is working even better!

I'm really liking trigger via GPIO, as it should be camera agnostic and could easily be expanded to trigger multiple cameras.

Once I figure everything I'll most likely put up a guide. still too many unknowns right now. haha. 👍

[diegotheslinger]

Chilicoke, you ever end up doing a write up or is this process still working out for you? I also have the A6000 and an older Canon Rebel and am trying to figure out the best way to trigger it through Octolapse.

[FormerLurker]

@diegotheslinger and @chilicoke, perhaps a wiki page needs to be created for each model that proves difficult to work with?

[diegotheslinger]

Not to derail @chilicokes thread, but got octolapse working great 'out of the box' with the Canon Rebel Xsi. I'll be trying the A6000 out next, I'll try and post some info if I have any luck.

[FormerLurker]

This was a fun thread, but it's been idle for a good long while, so I'm going to go ahead and close it down. For anyone interested, the DSLR guides have been updated with a lot of the knowledge that has been gained from several DSLR threads, so if you are still having issues it might be worth looking at the three DSLR guides (standard with download, no download, and deferred download) one more time. Feel free to create a new issue if anyone has questions or comments, and THANKS FOR POSTING!

[ijahongirmirzo]

Thanks again!, I re-read all your FAQ on each settings a little bit closer and realized that Octolapse is looking for the first extrusion gcode on the new layer to act as trigger? If so that completely explains why I'm seeing a little bit of extrusion before the nozzle move into position for snapshot. Maybe I just need to experiment with both Cura and Octolapse options a bit more. I don't want to trouble you too much for now as I would like to get camera to trigger reliably first.

Regarding my issue with camera trigger, I raided my hoarder bin and was able to build a little break out board using Pi's GPIO + transistor + 2.5mm headphone jack to act as an external shutter trigger for my camera, testing with Canon Rebel for now, but I'm 99% sure it will also work with Sony A6000 once the adapter cable comes in.

I have laughably minimal scripting knowledge from many years ago, but was able to cobble together (after lots of Google search) the below code and was successful in triggering a 0 delay shutter on my Rebel with sudo python /home/pi/scripts/external-camera-trigger.py shell command via SSH.

#!/usr/bin/env python

import RPi.GPIO as GPIO
import time

GPIO.setwarnings(False)

GPIO.setmode(GPIO.BCM)
GPIO.setup(21, GPIO.OUT)

GPIO.output(21, True)
time.sleep(0.2) 
GPIO.output(21, False)

print "Done..."

However, how to get this little python script to work with Octolapse is where my lack of knowledge shows, I understand that we created a bash script in your original guide and it contains the parameters Octolapse is looking for. In this case, how do I get my above script to work as Snapshot Acquire Script,

I'd imagine I would also probably need to add a small amount of delay after shutter trigger to prevent nozzle movement before camera shutter closes. Another reason I decided to go with GPIO route is to later add in relays to triggers lights to only come on for the time lapse for those long overnight prints.

Once again THANK YOU SO MUCH for all your help.

Hello, Can you tell details, how did you connect headphone cable to raspberry pi to act as a trigger? I wanted to trigger my android phones camera using 3.5 mm heaphone jack using GPIO pins Thank you before hand!