Closed MineThingIssues closed 5 years ago
Are your images on the SD card at all? Try setting capturetarget = 1 if not.
I'm very glad your printer is going faster! I'm going to be out for the evening, but should be around tomorrow AM.
The images don't appear on the camera at all from what I can see
Sorry our time zones are quite different. I am in the UK which is about 5 or 6 hours ahead of most of America I believe. Right now it is 12:10pm in the uk
Thank you :D Setting it to 1 seems to have done the trick! I am still getting the motion blur from the print head tho. Is there an efficient way to increase the delay between triggering the picture and the print resuming? I have done it myself by using the sleep command to make it wait 1 second (which is the perfect amount of time for my settings right now). This results in a total image capture time (Including the movement of the print head) to be 8.5 seconds. Is there a good way to reduce this? Or is this the best I can expect out of this method?
Here is my latest timelapse: https://photos.app.goo.gl/P8yFbA9z6N3Y16JB7. I remembered to set it to manual this time but there is still a change in lighting at the beginning due to the night and day transition. The camera missed no images (Done with the non-deferred image download one). Although I did forget that I hadn't set up the bitrate to be high until 4 hours into the print so it didn't take effect. My next timelapse should be better quality with the higher bitrate. and will save me time because of the deferred image download
I will also change the aperture to get more in focus for next time I do a print of this scale
A trick I use, and that could help : I first put something vertical, centered on the bed, where the thing will be printed (I use a temp tower). I let the autofocus do it's job, then I lock the focus (I switch to manual focus, and don't touch focus anymore). Then I use aperure mode, as you suggested. Powerfull lightings, ISO 400 or 800, f16 or f18 or even 22. But such a tiny aperture could give aberrations (diffraction), and therefore a blur look and feel. f11 (imo) does not give anough DOF, at least for larger prints. For exposure, something near to "Kodak grey", measure, and remember speed. Switch to manual, and set aperture. Or do some f and speed calculation in order to get a compromise (I'm also a beginner with timelapses, and it's not as perfect as Wildrose Builds ! Even if I've been doing photo for many years, this is a not easy. Maybe it could be compared to macro ?)
Or you could use hyperfocal. There are good smartphone apps for calculations.
Sometimes, I suspect Wildrose to do focus stacking... FormerLurker could maybe try to implement such a functionnality, with automatic reconctruction before rendering ? (just kidding, but who knows...) A gphoto script could probably do this .
(still experimenting, it will just be to illustrate open sourced desingns)
I do a similar thing actually where I put an already printed model of about the same size on In the place where it will print and then set the focus with autofocus, I then switch to manual focus and make sure that I am on manual mode to stop the exposure from changing (An issue I discovered in my first timelapse). I then make sure that the aperture is what I like it to be and then set the shutter speed to get the correct exposure. (I also shoot at ISO 100) I also love Depth of Feild so I keep the aperture quite wide but In some cases, I go a bit overboard lol (As shown in my latest timelapse). My nifty fifty lens is quite good at removing chromatic aberration (Or rather not having much in the first place), and so I don't really notice it much even at F1.8. As for the focus stacking, Magic Lantern software for canon cameras uses gphoto and some other custom made code to interact with the camera and do some automatic focus stacking (although I don't think that it auto reconstructs the images for you) and I have seen some commands for setting focus so I believe that it could be completely possible in gphoto. Interesting idea!
Now that I would say that my issue is fixed, I will be closing this issue. Upgrading to the new Pi 3 B + was the main reason it was fixed, and I also believe that the deferred image download is also a solution to the problem. Thank you for all the help you have given me over the past week and I see a bright future for octolapse ahead! The community will continue to grow and the more issues you iron out to begin with, the less work for yourself in the future! I am also always happy to help with anything you need
@MineThingIssues Have you seen this issue since? I am now seeing an identical issue to yours (camera seems to take every other picture) and I already defer download of the images until pre-rendering and I'm already on a Pi 3 B. Followed along with all the potential fixes like making sure the capture target is correct and resetting USB.
@mordhau5 I'm having the same issue. My Canon 250D is taking all photos but in octolapse shows Camera Error without providing information.
The latest release candidate (0.4.0rc1) has MUCH better logging of the camera scripts if you want to try that.
The latest release candidate (0.4.0rc1) has MUCH better logging of the camera scripts if you want to try that.
@FormerLurker I regret not seeing this for a whole month, but is there a release date in sight for the new RC?
@mordhau5, no problem! Rc2 was released a few weeks ago. I am working on getting 0.4.0 stable out now. I worked on it all weekend, but hit a few snags. This week is looking promising though, since I finished the wiki and plugin repository changes. Check out this guide: https://github.com/FormerLurker/Octolapse/wiki/V0.4---Getting-Started
@mordhau5, I found some problems for the 'Deferred Download' method, so if you are using that you may want to hold off a bit. Alternatively, you can install from the 'devel' branch because I think I have it fixed. I will be running some additional tests to ensure that all of the DSLR features are working as designed, so this will add a slight delay to release.
@FormerLurker That's fantastic news! Glad to hear it's dropping so soon. The new method for feature detection has me practically foaming at the mouth right now! I never used them before because changing every single speed to a unique value for every different type of print I run wasn't feasible. Also, I'm noticing the walkthrough and guides are much more thorough this time around! This calls for a Paypal donation for sure!
I'm actually using "deferred download" of sorts on the older version (which I don't have in front of me because my printer is currently down) which mostly works pretty well. But I do get the issue in this thread. Hopefully the new logging methods provide insight, but, I've seen people in the gphoto github issues complaining about their cameras also just refusing to respond sometimes so I wonder if it's truly an Octolapse issue at all.
@mordhau5, You may want to check out the latest release candidate I just dropped yesterday: https://github.com/FormerLurker/Octolapse/releases/tag/v0.4.0rc3
I need someone to test the deferred download method that I just fixed, and if your printer starts working again perhaps you would be willing to help me out here? There is a new guide for deferred download here. Also, here is the getting started guide. If you don't have time or can't get your printer running, that's fine of course :)
I'm REALLY hoping that there are no code changes between 0.4.0rc3 and 0.4.0, so this might well be the final stable version. If I hear back from enough people confirming the fixes I applied, I'm going to deploy this weekend for sure.
@FormerLurker I've already read through the new Deferred Download guide and it's much better than before. I'd be delighted to help. I can also help from the angle of being a Klipper user, which I'm told is less common.
My printer is currently disassembled for upgrades, but I'll have it together before the weekend. As soon as I'm printing again, I'll forward you any feedback I have on the rc3 unless you go ahead and deploy 0.4.0. Is there a Mega-Issue for all RC feedback or would you like a new issue opened up per-feedback?
Awesome 👍 the mega issue is fine. I already got confirmation that one major bugfix worked. Two more to go
Hello everyone, I also had problems with a canon 60 D camera and the octolapse with the same error, it starts taking some pictures and then does not take more or some skipped, it was as if I had some communication problem, investigating I realized that if I have the camera in manual mode gives problems but if I put it in automatic octolapse works perfectly, so when you get error in the camera will have to check the camera menu and the mode in which the photo is taken. greetings.
I just learned that the installer script that is used in the wiki is somewhat outdated. Basically an older version of gphoto2 is being loaded, and many of these problems (I'm looking at you Sony Alpha (and probably others)!) have been solved by subsequent updates. Keep an eye out for a new install script, or if you're impatient, you can go to the source here. Please note that you will need to modify the location of the git command, as it is somewhat hidden to prevent user error in the octopi image. You can look at my example install script to find the correct location, or you can wait until I have a couple hours to implement and test a new script.
If anyone wants to shoot a modified script over to me (if you beat me to the punch), I'll add it to the wiki.
thanks!
Thank you very much for answering, I thought it was a camera problem, I will wait for the new script as I am a beginner in this. I don't know whether to delete the card and install everything from the beginning. greetings
Version of Octolapse
Octolapse Version:0.3.4
Version of OctoPrint
OctoPrint Version: 1.3.10
When you ran into the problem, did you have diagnostic logging enabled?
Diagnostic Logging was Enabled: Yes
What were you doing when the problem occurred
What should have happened?
The camera should have taken a picture every layer or at least thrown a readable error if not done correctly to help with debugging
What happened instead?
Camera worked for a few frames but every now and again it wouldn't take the picture and the error that came up on screen had no information. It simply read "Octolapse - Camera Error". It would either fix itself straight away and take a picture the next layer, or throw the same error again for the next few frames. The issue was more common at the start of prints and was less likely to happen later on. It would happen multiple times per print
Operating System running OctoPrint and Octolapse
OS Name: OctoPi Os Version: 0.16.0
Printer model & used firmware incl. version
Printer Model: Ender3 Printer Firmware Version: Marlin V1; Sprinter/grbl mashup for gen6
Browser and version of browser, operating system running browser
Browser: Google Chrome Browser OS: Windows
Link to the gcode file you were printing when the problem occurred
Link to Gcode File: Deleted -Issue also occurred on 7 other gcode files
Link to settings.json
Link to settings.json with all passwords removed: Forbidden to download.
Link to plugin_octolapse.log
Link to plugin_octolapse.log: https://gist.github.com/MineThingIssues/ff2ca8bdc3c0d0666a599f9eec41cb8f
Link to octoprint.log
Link to octoprint.log: https://gist.github.com/MineThingIssues/c2a7579969c54b6bd2e9c13a34d53872
Aditional Information: gphoto2 version: 2.5.20 libgphoto2 version: 2.5.22
screenshots: