Fast Stacker (Arduino based automated focus stacking rail)

ChrisR · Post by **ChrisR** » Thu Dec 10, 2015 11:29 am

Absolutely.
If the "vibrations" mean that parts (eg antannas) of the bug are moving relative to the body, then they could be in different places on consecutiive shots. A nightmare, because the flash would make them sharp.

pulsar123 · Post by **pulsar123** » Thu Dec 10, 2015 11:58 am

ChrisR wrote:Absolutely.
If the "vibrations" mean that parts (eg antannas) of the bug are moving relative to the body, then they could be in different places on consecutiive shots. A nightmare, because the flash would make them sharp.

Hmm, interesting point. So I think I have decided to do the mod - to include a non-continuous stacking, but only for 2-point stacking regime.

ChrisR · Post by **ChrisR** » Thu Dec 10, 2015 12:09 pm

What's "2-point stacking regime"?

If you mean the "mode", I wonder how many people use?
The Stackshot manual is online, which would tell you
1) A way to write a pretty awful manual
2) What they think are modes worth having.

I use about 2 modes.
Set start, set end, set step distance, and
Start Here, set direction, give me X steps at Y distance each. (Good for eg a flower if you can't be bothered to move the thing the 100mm to and fro just to set the distance.)

Maybe other folk use other modes.

pulsar123 · Post by **pulsar123** » Fri Dec 11, 2015 1:44 pm

This is exactly my "2-point stacking" and "1-point stacking" modes. The twist being that it is all only continuous operation (my preferred way of doing stacking - faster), so one more parameter required for both - frames per second.

I am in the process of putting support for a non-continuous stacking, with two additional (time delay) parameters: first one is the time from the moment the rail stops moving (and the mirror locked) until the shot is initiated, and the second is from the shot initiation until the rail starts moving again (should be longer than your exposure time).

Chris S. · Post by **Chris S.** » Fri Dec 11, 2015 10:19 pm

pulsar123 wrote:I am in the process of putting support for a non-continuous stacking, with two additional (time delay) parameters: first one is the time from the moment the rail stops moving (and the mirror locked) until the shot is initiated, and the second is from the shot initiation until the rail starts moving again (should be longer than your exposure time).

(Different Chris here). While you're at it, I'd suggest you add two more things. One is support for more than one actuation of the camera trigger before moving on, which is useful for those of us you use mirror-up mode. The other is a secondary delay parameter, to adjust the amount of time between the first and second shutter actuations.

pulsar123 wrote:. . .continuous operation (my preferred way of doing stacking - faster). . .

Faster, sure. But only useful for photographers using flash, so leaving out photographers who use continuous light. And even flash photographers may find it useful to build in some delay to allow heat from the flash units to dissipate and for the flash to recharge. At 1/16 power, this may not be a problem. But at full power, it is--and back when I used flash for studio macro, I found plenty of times when full power produced barely enough light for a particular shot.

--Chris S.

pulsar123 · Post by **pulsar123** » Sat Dec 12, 2015 1:44 pm

Chris S. wrote: (Different Chris here). While you're at it, I'd suggest you add two more things. One is support for more than one actuation of the camera trigger before moving on, which is useful for those of us you use mirror-up mode. The other is a secondary delay parameter, to adjust the amount of time between the first and second shutter actuations.
--Chris S.

Can you elaborate please? I thought that is what I just described - specifically for mirror lockup scenario. (I can't imagine anyone making long delays between shots to reduce vibrations and not using mirror lockup!).

This is what I already almost implemented (just have to debug):

1) Rail moves to the next frame position;
2) Shutter is pressed (briefly) once -> mirror is locked;
3) First delay (adjustable parameter) - for vibrations to die off;
4) Shutter is pressed again (briefly) -> the shot is initiated;
5) Second delay (adjustable) - to allow the exposure to take place;
6) Go back to item (1)

nsomnius · Post by **nsomnius** » Sun Dec 20, 2015 1:04 pm

This is fantastic news, the addition of a non-continuous burst mode. It will make the system that much more versatile. It will also enable one to use whole stepping for more torque without having to worry. My build is in progress but some parts are taking the slow boat from china it seems.

Those are some very nice touches to the software, after reading the What's New page. Thank you!

Are the schematics done in Visio? I'm thinking of working them up in Fritzing unless you already have. The more graphic approach of Fritzing I find helps keep me on track.

pulsar123 · Post by **pulsar123** » Sun Dec 20, 2015 1:31 pm

I am releasing the next public version of my stacking software - s0.12. The one important change is the addition of non-continuous focus stacking (only for 2-point stacking). Requires the same hardware - h1.1 - as s0.10.

I have already updated the wikia tutorial to reflect the changes. The full list of changes can be found here:

http://pulsar124.wikia.com/wiki/What's_new

(Or this if the above link doesn't work: http://goo.gl/KnDxfF )

I used SchemeIt (http://www.digikey.ca/schemeit/#) to draw the schemes.

ChrisR · Post by **ChrisR** » Sun Dec 20, 2015 2:42 pm

Linked page (and the zip file name) says S.010 - is that right?

Is there a 'larger' Arduino which would have more pins available & run the same code(, other than pin addresses)?

The continuous versus stop-start test is intetesting.
Any idea how many frames per second could be fired off if the camera were not the limitation?

pulsar123 · Post by **pulsar123** » Sun Dec 20, 2015 2:54 pm

ChrisR wrote:Linked page (and the zip file name) says S.010 - is that right?

Is there a 'larger' Arduino which would have more pins available & run the same code(, other than pin addresses)?

The continuous versus stop-start test is intetesting.
Any idea how many frames per second could be fired off if the camera were not the limitation?

Which page has a wrong link to the software? The direct new software link is

http://syam.no-ip.org/stacker_v0.12.zip

I am pretty sure there are larger Arduino with more pins, though my only experience so far is with Uno R3. But it looks like the Uno's pins should be sufficient, even for my next hardware mod - controlling a second - AF - relay, to make my rail much more portable (for many more camera makes).

Frames per second are limited in camera in two ways: first, the physical limit of repeating shots in a quick sequence; second, the pressing the shutter key cannot be too short: my Canon 50D works okay when it's 50 ms, but looks like when mirror lock is used I need at least 100 ms.

If you ignore both camera limits, than the next bottleneck is likely the relay. (Not sure the exact value in ms.) One can replace relay with an opto-pair or even a transistor to make it much shorter still. In that case, the fundamental limit in my algorithm will be the length of the ARduino loop, which is ~ 250 us. (= 4000 fps).

ChrisR · Post by **ChrisR** » Sun Dec 20, 2015 2:57 pm

4000fps might be enough

.

I was wondering about mirrorless cameras, etc.

(previous link goes to
UPDATE (07.12.2015): My newest software version s0.10 is stable enough, so I am releasing it now. Warning: this version requires slight hardware modifications (version h1.1; see below).
Contents[show]
Hardware h1.1 and software s0.10(released)

pulsar123 · Post by **pulsar123** » Sun Dec 20, 2015 3:23 pm

I think you need to refresh the wiki page to see the update info (Ctrl-R).

Arduino Mega has 54 pins: https://www.arduino.cc/en/Main/ArduinoBoardMega2560 Some small modifications to my code might me required.

nsomnius · Post by **nsomnius** » Sun Dec 20, 2015 5:07 pm

It's a relatively simple matter to extend the number of available pins on an Uno with the addition of a dirt cheap MCP23017 chip if the need arises.

http://tronixstuff.com/2011/08/26/tutor ... -io-ports/

ChrisR · Post by **ChrisR** » Sun Dec 20, 2015 6:57 pm

Ctrl-R didn't do it, clearing my cache didn't do it, clicking the "What's New" link on the right of the page DID do it.

Extra pins - I have various ideas (which I'll doubtless never get round to implementing) for other functions to happen around each exposure.

TheLostVertex · Post by **TheLostVertex** » Fri Dec 25, 2015 7:51 am

pulsar123 wrote: my Canon 50D works okay when it's 50 ms, but looks like when mirror lock is used I need at least 100 ms.

To add to this, in live view, to reliably fire the shutter it requires about a 200-400ms pulse to fire consistently for my 500d and my old 60d. It was not consistent either. It would fire something like 3/10 times with a 70ms pulse. The longer the pulse, the more consistently they will fire. Live view is a strange beast. Since a single timing doesnt seem to do the trick, brute forcing and just doing a long pulse seems to fix the problem.

Rik did a test of the 500d shutter time in live view here http://www.photomacrography.net/forum/v ... hp?t=13726 and i suspect these are actually related issues. Where the reason for the difference in shutter actuation time, is actually from variation in the time it takes to trigger.

pulsar123 wrote:If you ignore both camera limits, than the next bottleneck is likely the relay.

I might have missed it, but I think the first limit will always be moving the rail accurately and quickly. 4000fps is no problem from modern video camera. But to get any where close to 4000fps while accurately moving the rail, stopping, and moving would not be feasible. More ideally a high FPS video camera, flash, and continuously moving rail would be needed. Video stacking on steroids

And at this point we dont really even need stepper motors really!