How does StackShot know when it has reached the rail limits?

Have questions about the equipment used for macro- or micro- photography? Post those questions in this forum.

Moderators: rjlittlefield, ChrisR, Chris S., Pau

kaleun96
Posts: 270
Joined: Sat Oct 20, 2018 3:47 pm
Location: Stockholm, Sweden

How does StackShot know when it has reached the rail limits?

Post by kaleun96 »

I've built an automated rail of my own and use limit switches to find the min and max positions of the rail. It's a bit of a pain in the sense that it makes the cabling just that much messier.

I was looking at the StackShot, through its manuals, including the communication manual, yet I can't find anything that references how it deals with reaching the beginning/end of the rail. Does anyone here know?

My suspicion is that it is using some form of sensorless stall detection but if so, do we know what driver it is using for this?

rjlittlefield
Site Admin
Posts: 23564
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

It just runs into the end of the rail and keeps trying to run farther. No stall detection as far as I know.

--Rik

kaleun96
Posts: 270
Joined: Sat Oct 20, 2018 3:47 pm
Location: Stockholm, Sweden

Post by kaleun96 »

Thanks Rik, that's a bit surprising though. It's my impression that running a stepper motor while stalled out can damage the windings. Then again, they're fairly cheap to replace.

ray_parkhurst
Posts: 3417
Joined: Sat Nov 20, 2010 10:40 am
Location: Santa Clara, CA, USA
Contact:

Post by ray_parkhurst »

kaleun96 wrote:Thanks Rik, that's a bit surprising though. It's my impression that running a stepper motor while stalled out can damage the windings. Then again, they're fairly cheap to replace.
It's doubtful any damage would be done unless it continued for a long time and caused overheating. There is no physical contact between the rotor and stator, only magnetic, so there is nothing to be damaged. I'd be more concerned about the jerky forward/backward motion causing problems elsewhere in the system due to resonances and such.

Edited to add: the mjkzz controller will automatically stop when it reaches the end of physical travel during calibration, after it stalls. Unfortunately this does not happen in use, so if the calibrated end is offset manually, it will continue to try moving until it reaches the programmed number of cycles. I don't know why it stops during calibration, but I have always presumed that the IC controller must have a current or voltage sense function which can determine the end of the physical movement. Perhaps Mike or Peter can give us more info on how this is handled?

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

Hello,

Agree with Rik, that's what my Stackshot does.

I'm developing my own Stack and Stitch setup and controller also, and considered the "limit switches" approach but for the same reasons as you decided not to implement them.

If you limit the motor current peak in the controller, then the risk of motor damage is small, although I don't recommend banging into the rails often.The surplus THK rails I'm using in the development S&S setup have rubber bumpers for protection and squeal when the carriage hits the bumper giving a good loud audible "limit" detection.

If you are using controllers that have nonvolatile memory, including motor position count, then you can set the limits in program software and they will remain as will the motor position count when you power up again. This is what I'm doing and it works well as long as you don't manually move the motor with power off or when the motor is disengaged (power down the motor while the controller is still active).

I think folks would be interested in what you're developing and what components you've using.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

ray_parkhurst wrote:
kaleun96 wrote:Thanks Rik, that's a bit surprising though. It's my impression that running a stepper motor while stalled out can damage the windings. Then again, they're fairly cheap to replace.
It's doubtful any damage would be done unless it continued for a long time and caused overheating. There is no physical contact between the rotor and stator, only magnetic, so there is nothing to be damaged. I'd be more concerned about the jerky forward/backward motion causing problems elsewhere in the system due to resonances and such.

Edited to add: the mjkzz controller will automatically stop when it reaches the end of physical travel during calibration, after it stalls. Unfortunately this does not happen in use, so if the calibrated end is offset manually, it will continue to try moving until it reaches the programmed number of cycles. I don't know why it stops during calibration, but I have always presumed that the IC controller must have a current or voltage sense function which can determine the end of the physical movement. Perhaps Mike or Peter can give us more info on how this is handled?
Ray,

I don't know what driver control chip Peter is using but the new Trinamic driver/controller chips have a "Stall Detect" which could possibly be used for limit detection.

I'm evaluated the TMC-5130, 5160 and 5161 but shying away from them because of the interface (I prefer USB for the Raspberry Pi 3B). The Pololu Tic-500 I'm presently using doesn't have stall detection, but employs a motor current limit control that should protect the motor and/or setup if correctly configured.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

kaleun96
Posts: 270
Joined: Sat Oct 20, 2018 3:47 pm
Location: Stockholm, Sweden

Post by kaleun96 »

the mjkzz controller will automatically stop when it reaches the end of physical travel during calibration. [...] Perhaps Mike or Peter can give us more info on how this is handled?
Interesting! My brief understanding after 5 minutes of Googling was that the stall detection works partly based on back EMF from the stepper motor, e.g.
https://www.eetimes.com/document.asp?doc_id=1279185

I found a few motor drivers that handle this for you but I wonder if something approximate can be done even with an A4988 or DRV8255.
This is what I'm doing and it works well as long as you don't manually move the motor with power off
I considered something like this as well but decided I wanted to keep manual operation functionality as a possibility. Also without a closed loop system, I'm not 100% confident I don't miss any steps during my stack runs (even though I don't use microstepping).

An alternative would be to "home" it yourself at each power-up based on the knowing steps for the length of your rail.
I think folks would be interested in what you're developing and what components you've using.
Sure! I posted my rig over in the other subforum the other week:
http://www.photomacrography.net/forum/v ... hp?t=39132

Nothing particularly novel about what I've done; the biggest difference is probably the TFT touchscreen which you don't usually see on homemade rigs.

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

Thanks, nice setup!!

I would stay away from the Ti DRV types, apparently they have very poor micro-step behavior.

I've run multiple days continously trying to invoke missed steps on 3 axis S&S without success utilizing the surplus THK rails and Pololu Tic-500 controller/driver.

Think as long as you have a good design & setup electrically, and good clean power supply, missing steps are rare.

BTW I like the Touch Screen but I've got too many parameters to enter and display, so use VNC to my Mac which actually works pretty good!

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

kaleun96
Posts: 270
Joined: Sat Oct 20, 2018 3:47 pm
Location: Stockholm, Sweden

Post by kaleun96 »

Cheers!
I would stay away from the Ti DRV types, apparently they have very poor micro-step behavior.
I had been looking at the TMC2130s etc as an alternative to DRV8825/A4988 but they didn't seem as plug-and-play as the former two. But the stall detection may make it worth it if I can get rid of the limit switches!
Think as long as you have a good design & setup electrically, and good clean power supply, missing steps are rare.
Do you have a method for knowing your "zero" independent of the value stored by the driver/your software? I've done some limited testing but nothing that can independently confirm the repeatability of my zero position to within 1 step (2.5um).

My other concern is during the time I run the steppers in no-current mode to reduce the heat (not really a concern) and the buzzing/vibrations. I found out the DRV8825 doesn't like waking from sleep and then stepping 1 step, I was losing a step here unknowingly. I haven't quite figured out why but perhaps some issue with it losing its position between phases. It was only an issue when taking less than 4 steps for some reason.

Using the ENABLE pin functionality instead of SLEEP solved that problem however.
BTW I like the Touch Screen but I've got too many parameters to enter and display, so use VNC to my Mac which actually works pretty good!
Thanks! Yeah I can understand if you want full control (input lens parameters, calculate stacking sequence optimized for a given DOF, etc) that a touchscreen isn't ideal. You'd need a 5-7" screen as minimum and even then programming all the functionality takes twice as long as a regular screen.

Interesting thought with the VNC! I had been thinking about adding a bluetooth module and developing an Android app as a way of learning some more programming but it's a bit out of scope for me at the moment.

Have you posted your setup on the forums yet? I'd be interested in seeing it operate.

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

Haven't done a video yet, just some stills. You can see the evolution of the Precision Stack & Stitch System on these.

http://www.photomacrography.net/forum/v ... ht=anatomy
http://www.photomacrography.net/forum/v ... ht=anatomy
http://www.photomacrography.net/forum/v ... ht=anatomy
http://www.photomacrography.net/forum/v ... ht=anatomy

I'm running some tests now to access the vibration reduction parameters for the setups. This is an attempt to tailor the motor control parameters to reduce or eliminate rail induced vibration, which must be "tuned" for each setup configuration. The emphasis behind this is to reduce the overall image capture time for long stack and stitch sessions. Reducing the time between exposures plays a significant role in the overall time, so minimizing this time by means of rail movement induced vibration reduction.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

Do you have a method for knowing your "zero" independent of the value stored by the driver/your software? I've done some limited testing but nothing that can independently confirm the repeatability of my zero position to within 1 step (2.5um).
I just marked the motor shaft and mount, then looked for a missing step. I can't tell below a regular step though.
My other concern is during the time I run the steppers in no-current mode to reduce the heat (not really a concern) and the buzzing/vibrations. I found out the DRV8825 doesn't like waking from sleep and then stepping 1 step, I was losing a step here unknowingly. I haven't quite figured out why but perhaps some issue with it losing its position between phases. It was only an issue when taking less than 4 steps for some reason.
The shaft is held in micro step positions by the current induced magnetic field and the PM field. When current is removed the rotor will move to a normal cog position aligned with the PM field, when current is reapplied it may or may not return to the same micro step position. This is why I use a holding current rather than cutting the motor current completely off, the holding current should keep the rotor at the micro step position, or very close to that position. However I wouldn't count on the micro position accuracy beyond 1/8 steps, or maybe even 1/4 steps, but the smaller micro steps do make for a smoother motor behavior.

One of the reasons I like 0.9 degree motors over 1.8 ones is the cogs are machined/cast in place and thus somewhat fixed and should be more repeatable IMO than a 1/2 micro step 1.8 motor to get to the same step resolution. This should play thru with the smaller micro steps as well I believe.
Interesting thought with the VNC! I had been thinking about adding a bluetooth module and developing an Android app as a way of learning some more programming but it's a bit out of scope for me at the moment.
I wouldn't even think of trying that, developing the app, I'm already over my head with these controllers and the Raspberry Pi running Python!!

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

kaleun96
Posts: 270
Joined: Sat Oct 20, 2018 3:47 pm
Location: Stockholm, Sweden

Post by kaleun96 »

Fascinating stuff! Looks like a fairly large project at this stage, particularly with several thousand lines of code. Are you implementing your own code for directly controlling the stepper motor stepping, positioning, and acceleration or is there a library that you can leverage like the AccelStepper for Arduino?
The emphasis behind this is to reduce the overall image capture time for long stack and stitch sessions.
I didn't come across it in your links but how are you checking the recycle time of the flash? I thought I could do it by plugging into the PC Sync output of my Godox transmitter but it turns out this is independent of flash recycle time and is only useful for determining how long to trigger the shutter for. I'm not quite sure why the shutter trigger time changes if it's not related to flash recycle time. I see it change from less than 300ms required to trigger the shutter to up near 1100ms after a stack sequence.

I'm thinking about including a photodiode to watch for the red LED on the back of my flash indicating it is ready but this isn't an ideal solution.
I just marked the motor shaft and mount, then looked for a missing step.
Ah yes, good point. That would be fairly accurate, assuming you don't lose steps in both directions that cancel each other out haha!
This is why I use a holding current rather than cutting the motor current completely off,
Are you able to control the current to the motor with your driver? With the DRV8825 this doesn't seem possible so it's all or nothing.

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

Fascinating stuff! Looks like a fairly large project at this stage, particularly with several thousand lines of code. Are you implementing your own code for directly controlling the stepper motor stepping, positioning, and acceleration or is there a library that you can leverage like the AccelStepper for Arduino?
Yes, its several thousand lines of code overall. I'm using the Pololu Tic-500 now, it has a micro controller & motor driver builtin, so I don't need to directly control the motors. Trying to control the 3 motors directly from the Raspberry Pi, the OS gets in the way and slows things down I found, so went with a dedicated micro controller for each motor.
The emphasis behind this is to reduce the overall image capture time for long stack and stitch sessions.
I didn't come across it in your links but how are you checking the recycle time of the flash? I thought I could do it by plugging into the PC Sync output of my Godox transmitter but it turns out this is independent of flash recycle time and is only useful for determining how long to trigger the shutter for. I'm not quite sure why the shutter trigger time changes if it's not related to flash recycle time. I see it change from less than 300ms required to trigger the shutter to up near 1100ms after a stack sequence.
I use AC Line powered strobes, from 3 to 11 depending on what I'm trying to do. These recycle pretty fast at full power, but much faster at lower power. Multiple strobes not only help with light distribution, but overall recycle time.

The shutter to strobe "Hot Shoe" trigger time for the Nikons I'm using are reasonably consistent, however when using EFCS in totally electronic shutter "Silent Mode" (no mechanical curtains) Nikon blocks the Hot Shoe as others camera do.

Long ago I built a strobe/flash delay trigger that is activated from the camera trigger with some NE555 timer chips. This simply issues a strobe/flash trigger after a predetermined and adjustable time delay which fires the strobe after the camera trigger. The delay varies depending on the camera body, but reasonably consistent.
I'm thinking about including a photodiode to watch for the red LED on the back of my flash indicating it is ready but this isn't an ideal solution.
This is a very good idea. You can add a optical coupler to the flash and use that as feedback but requires you open up the flash and install the coupler. Since I use multiple strobes I would need to pick the one with the longest recycle time. Another option would be to include a built in strobe/flash recycle delay that covers the recycle time in the code, since I already have a shutter time and camera trigger & settling delay, this would be just another parameter.

I just marked the motor shaft and mount, then looked for a missing step.
Ah yes, good point. That would be fairly accurate, assuming you don't lose steps in both directions that cancel each other out haha!
For a more precise check, Zerene can be used to compare the before and after alignment of 2 images. I'll probably do this later when I get ready to take some serious image to make sure things are all in order.
This is why I use a holding current rather than cutting the motor current completely off,
Are you able to control the current to the motor with your driver? With the DRV8825 this doesn't seem possible so it's all or nothing.
Yes the motor current can be controlled directly from the driver, this is very important for my use. Different motors/setups require different characteristics, so having direct motor current control is required, not to mention dynamically controlling motor current "on the fly" as a possible method to mitigate motion induced vibrations and the ability to use a "holding current" during idle times to reduce heat buildup.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

mawyatt
Posts: 2497
Joined: Thu Aug 22, 2013 6:54 pm
Location: Clearwater, Florida

Post by mawyatt »

mawyatt wrote:
ray_parkhurst wrote:
kaleun96 wrote:Thanks Rik, that's a bit surprising though. It's my impression that running a stepper motor while stalled out can damage the windings. Then again, they're fairly cheap to replace.
It's doubtful any damage would be done unless it continued for a long time and caused overheating. There is no physical contact between the rotor and stator, only magnetic, so there is nothing to be damaged. I'd be more concerned about the jerky forward/backward motion causing problems elsewhere in the system due to resonances and such.

Edited to add: the mjkzz controller will automatically stop when it reaches the end of physical travel during calibration, after it stalls. Unfortunately this does not happen in use, so if the calibrated end is offset manually, it will continue to try moving until it reaches the programmed number of cycles. I don't know why it stops during calibration, but I have always presumed that the IC controller must have a current or voltage sense function which can determine the end of the physical movement. Perhaps Mike or Peter can give us more info on how this is handled?
Ray,

I don't know what driver control chip Peter is using but the new Trinamic driver/controller chips have a "Stall Detect" which could possibly be used for limit detection.

I'm evaluated the TMC-5130, 5160 and 5161 but shying away from them because of the interface (I prefer USB for the Raspberry Pi 3B). The Pololu Tic-500 I'm presently using doesn't have stall detection, but employs a motor current limit control that should protect the motor and/or setup if correctly configured.

Best,
Ray,

Just thought of another possible method to detect the "limits". Set the motor current to a very low value, just enough for reliable movement, then slowly run into the rail stops and record the "limit". This should put little stress on the motor, stops, and rail.

I might actually implement this in my developments I'm working on.

Best,
Research is like a treasure hunt, you don't know where to look or what you'll find!
~Mike

iconoclastica
Posts: 486
Joined: Sat Jun 25, 2016 12:34 pm
Location: Wageningen, Gelderland

Post by iconoclastica »

Do you have a method for knowing your "zero" independent of the value stored by the driver/your software? I've done some limited testing but nothing that can independently confirm the repeatability of my zero position to within 1 step (2.5um).
I have a few suggestions that don't answer your needs, mainly for lack of precision, but they may give starting point for new thoughts:
- Digital calipers contain linear encoders that can be tapped. Typically they are more precise than 0.1mm and may have reference to a an absolute zero. Right now I am trying to turn a pair of them into a position reference for the x-y stage on my microscope, but it's too early yet to report success.
- Likewise, when I dismantled a large format inkjet printer, I found two position encoders: a linear one for the print head position and a circular one for the paper transport. Both are transparent plastic (sheet/strip) with engraved markings that are optically read. I didn't salvage the reader component, but I suppose they can be found in any printer. Even if you don't use them for positioning, they still might come in useful for motion detection.
- The thought crossed my mind that e.g. a laser beam shot through a narrow hole (e.g. the needle of syringe, o a pair of apertures) would mark a pretty exact position (but maybe not enough...).
--- felix filicis ---

Post Reply Previous topicNext topic