Speed, Encoders and homing

Matthias,

You shouldn't ever have any missed steps - no matter the distance moved. What stepper driver are you using? The primary causes of missed steps are not waiting long enough between step requests, too much/too little power going to the motor, and, of course, simply not sending the step request.

Have you tried making MIN_STEP_DELAY longer? I say this, because if you're missing steps on long runs, you're just as likely to miss them on short runs too. (So, if you miss 1 out of every 1000 steps on a long run, you run a similar chance, not exact, but similar, on shorter runs.)

The basic formula I've used to prevent missed steps is the same used on my stepper CNC machine (both with EMC2, and with Mach3), which is to set a maximum step speed (the value of MIN_STEP_DELAY, by default of 500 uS = 2,000 steps/second), and given velocity. Normally, missed steps (or overshoot!) will happen at the beginning or end due to poor velocity setting, and steps in the middle due to too high of a step rate. The velocity also reduces the jitter, in that it will slow down as it reaches the end of the move, and speed into the start of the move - preventing jittery starts and stops.

The velocity ramping is hard-coded at the moment, but I can make that adjustable. That is, velocity is determined by (MAX_STEP_DELAY - MIN_STEP_DELAY) / ( steps_requested / 3), the division by 3 is automatically reduced by 10% (continuously) until the difference between each step speed change is at least 1uS. So on the longer moves, the first 500 steps (using default values) will each be 1uS faster than the previous step, until the speed reaches 500uS between steps.

Can you try increasing MIN_STEP_DELAY and MAX_STEP_DELAY (doubling them would be a good place to start), and see if the causes the missed steps to go away? I suspect the issue lies there, and using variable speeds may mask the issue that could occur in shorter moves as well.

I doubt it would be in the velocity adjustment, but just in case - if adjusting the min/max step delay settings _together_ doesn't do the trick, can adjust the velocity by _only_ increasing the MAX_STEP_DELAY. That is to say, anything else done in the code won't fix the problem, because the minimum speed change between steps will always be 1uS. The algorithm will always move you back to this point if you try to extend the velocity amount - as not doing so will result in error, much worse than you have now. =) By increasing the MAX_STEP_DELAY, but not adding a subsequent increase to MIN_STEP_DELAY, you will increase the difference between them, and thereby add more steps to the velocity ramp. (Doubling the different between MAX and MIN will double the steps it takes to speed up to full speed on longer runs. It may, however, have a negative impact on shorter runs as with fewer steps, the increase in speed between steps will be much higher.)

We definitely have the pins available for encoders. I think I have four already available - especially since but I want to kill the ALT IN/OUT, so I can use i2c anyhow. If I keep the alt in/out, and also keep i2c, we'll definitely be short pins, and all channels would have to share the same encoder line, which could create serious issues. I have largely ignored the feedback stuff at this point, as it was going to drive the cost up for the small DIY guy, but I don't see any reason why the support can't be there for the people who can afford it! I'll look and see, but I'm presuming it would be fairly simple, if we limit to particular kinds of encoders (i.e., pulse encoders would be easy, but quadrature would probably be a nightmare). Of course, even with pulse encoders, it's going to be tough to find enough interrupts available on the existing board to read more than one. (And blocking while reading will not be an option, as it will kill the motor control functions.) So, that may still mean one shared encoder line for all axes.

Let me know if you can try adjusting the step delay, and see if that eliminates the problem. Your dolly should be able to move at a given max speed, no matter the distance - its just that other factors may be coming into play (friction, etc.) and you may have to slow it down. For example, my CNC will do jogs and rapids easily at 100 IPM, but when I add arcs or am cutting in material, my "real" max speed is 60IPM - anything faster and I miss steps.

!c

Uh oh! Thanks for finding that. I'm having a little trouble tracing down the issue though, could you provide me a little more info to help re-create the problem? Namely, when the motor moved away from home, what direction (0 or 1) were you going previously, and when the motor moved towards home, what direction had you been going then?

I'll make min/max step delay adjustable in the near future, it's no big deal to do that. Still working on the stereoscopic shooting function.

For continuous motion, I'll definitely have to re-write large portions of code (is that what you meant by real-time?) - I just need to see what interrupts I can steal for that, it may end up having to be a choice between alt in/out and real time w/ the current implementation. (Or, even, a choice between i2c and alt/in out =)

Someone else has asked me to keep the ALT in/out, so I guess I'm just getting ahead of myself there. There are a few issues that Milapse and astronomerroyal reported, namely in that in the latest NewSoftSerial, it's obfuscated the pin change interrupt assignments, so I have to re-think which ones I'm going to use, and how to adapt to his new code and avoid impact.

!c

Matt,

The homing issue is fixed in last night's checkin to subversion. Also fixed is a focus tap issue. I'm still looking into how to better handle velocity changes, I expect that to take some more time.

!c