Hi everyone, I seem to be having issues with my stackshot, particularly involving movement after going up, and then down, and vice versa. It seems to dislocate and jolt before it actually moves.
The other issue I have is when I set my start and end points. At the start point, whether starting at the bottom or top of a subject, it takes the first shot, and then takes a massive jump before the next shot, messing up my stack. I have resorted to having a start point well below what I actually require, but it adds an extra 20 or so shots!
I thought it might be a torque issue or something? Currently I have it on 10, although it was the same with lower torque. Speed is set at just under a mm a second, tramp 2 seconds, hi precision mode on. Step size is set at 7um
Issues with slipping stackshot
Moderators: rjlittlefield, ChrisR, Chris S., Pau
- rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
This sounds like an issue with backlash. The controller can only handle backlash correctly if it knows how much physical backlash there is in the rail threads and bearings. The numbers that you're listing suggest that the controller is using a number that's about 20x7um = 140 um = 0.14 mm different from the real value.
If that is what's causing your problem, then you can come pretty close to correcting it by following one of the procedures at http://www.zerenesystems.com/cms/stacke ... t/backlash. It is more challenging, but possible, to do the same calibration using the StackShot controller by itself.
But personally, I think it is easier and more accurate to bypass the whole problem by using a "pre-run" procedure so that the rail is moving in the same direction when both limits are set and when the stack is started.
--Rik
If that is what's causing your problem, then you can come pretty close to correcting it by following one of the procedures at http://www.zerenesystems.com/cms/stacke ... t/backlash. It is more challenging, but possible, to do the same calibration using the StackShot controller by itself.
But personally, I think it is easier and more accurate to bypass the whole problem by using a "pre-run" procedure so that the rail is moving in the same direction when both limits are set and when the stack is started.
--Rik
I do what Rik mentioned. Set your start point by coming up (or down) to the desired start location, set the start, then continue in the same direction to the desired stop point and set the stop point, but don't go the opposite direction between the start and stop set points. This keeps the loading on the motor, bearings and whatnot in the same direction. Backlash won't have much affect if you do this.
When you start a new stacking session, go beyond the desired starting point by a small amount and allow the controller (either Stackshot or Zerene) to approach the start in the same direction as the stack will be collected.
When you start a new stacking session, go beyond the desired starting point by a small amount and allow the controller (either Stackshot or Zerene) to approach the start in the same direction as the stack will be collected.
Well I tried setting the stack up in one direction, then coming above and reversing into the same direction. In some cases it doesn't move and just started from above the starting point, well out of focus. Then another time it still made quite a jump! Other times it just seemed to work reasonably ok.
Dare I ask how to do it manually with the stackshot? I don't have full Zerene stackshot control :/
And thank you for the information
Dare I ask how to do it manually with the stackshot? I don't have full Zerene stackshot control :/
And thank you for the information

- rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
I would use the following procedure:Koorosh wrote:Dare I ask how to do it manually with the stackshot?
- set up high mag optics looking at an inclined target in Live View with continuous illumination
- press Config, set #pics=1, Tsettle=small, Toff=small, Tpulse=small, Tramp=small, Units=metric, Hi Precision=On, Speed=100 um/sec
- press and hold Config to get into Custom Config
- select Backlash and press Down until value is 0 um (no backlash correction)
- press Config to get back to normal mode settings
- press Up or Down to get into Mode: Manual
- select Dist/step = 5 um
- select Start
- press and hold Back until the rail has clearly started moving backward
- adjust Live View to maximum magnification at whatever area is now in focus
- press Up multiple times, counting the number of presses, until focus starts to clearly shift with each press
- multiply the 5 um step size by the number of presses that had no significant effect on focus, to calculate the backlash distance
- press and hold Config to get into Custom Config
- select Backlash, enter calculated distance using Up/Down buttons
- press Config to get back to Mode: Manual
- reduce step size to 1 um
- alternately press Up and Down to rock the rail through its backlash correction to see if the value is correct
- tweak the backlash value until focus just barely moves with each 1 um Up/Down
However, I don't really expect those instructions to work for you. The reason is that in my world, the pre-run procedure is completely reliable and avoids any need to know a value for backlash. But you've reported that pre-run does not work reliably for you. The only conclusion I can reach is that your world and mine are somehow very different, and I don't know what that difference is. Maybe you have a cabling problem, maybe the motor coupling is loose, or a thrust bearing has gone wacky, or the controller has a glitch, or... Whatever it is, if pre-run won't work reliably then something is badly wrong somewhere.
--Rik
- rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Lou, if you're having trouble getting Zerene Stacker to recognize your Stackshot, you should contact support@zerenesystems.com . (Of course that's me, wearing my support hat.) There are several common causes, usually simple to fix. Typically it's either a bad cable, or some sort of conflict between two drivers, or a missing driver.
For what it's worth, that "PC" on the Stackshot display means only that the Stackshot sees ground and power on the USB cable.
--Rik
For what it's worth, that "PC" on the Stackshot display means only that the Stackshot sees ground and power on the USB cable.
--Rik
Apologies, I didn't see that you'd all replied! I am slightly concerned by the prospect of a physical problem with my stackshot, not least because I'm in the UK... In any case, it does work at least. I haven't got around to trying to sort the backlash, but I did some stacks a couple of days ago- I tried that procedure again as you guys suggested and this time, it did seem to work.. Sort of 

- rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
I would be interested to hear more detail about what "sort of" means.Koorosh wrote:I haven't got around to trying to sort the backlash, but I did some stacks a couple of days ago- I tried that procedure again as you guys suggested and this time, it did seem to work.. Sort of
Again, at the risk of sounding like a stuck record (is that phrase still understood?), the rail movement should be glitch-free if you start by backing off farther than both the physical backlash of the rail and the backlash setting of the controller.
The key element is that the rail must have completely reversed direction and be moving stably in the direction of the stack, at the time the first exposure is made.
If the rail has to reverse direction between the first and second exposures, then almost always there will be some glitch, even if the best possible backlash value is entered into the controller. This is because reversing direction of movement also reverses the direction of frictional forces on the two side rails. Those two rails are not perfectly matched, so the reversal introduces a tiny bit of rotation of the carriage, which multiplies by the lever arm of the lens system to be a noticeable sideways twitch in framing. The pre-run procedure takes care of that problem also.
--Rik