Submitted by Matt on Sun, 02/07/2010 - 11:13
Posted in
Hi,
I have discovered an issue, which I am not sure where to look into to fix it.
I will try to describe it:
In my windows GUI, I have a "quick program" function, that helps me setting up a timelapse shot very quickly. I set the start and the end of the motor movements, enter the real time and the screen time and a framerate. The GUI then calculates the necessary intervals (camera and motor). My track is about 7500 steps (1500 mm) long. With a real time of 20 minutes and a screen time of 20 seconds, I end up with a camera interval of 2 seconds and a dolly intervall of 15 steps (I turned of ramping for these tests). When I start this programm, everything seems to work fine, but the dolly stops after about half the way down the track. When I send the dolly back to home with the home command, it runs past the home position, not just a couple of steps, but what seems to me about half of the track. I can't really tell because it hits the end of the track and stops, but I can hear the motor go on for a couple of seconds.
When I modify the program to have more screen time, so I have smaller intervals (for example 5 motor steps), the dolly moves all the way to the end of the track and when sent home, goes to the home position (precicsely !) with no problem.
Now I tried the same thing with 100 steps and voila, the dolly almost exactly hits the home position. It misses a couple of steps, but audibly not more than ten.
So there seems to be a problem with certain step intervals. I have tested from 10 to 20 and it seems that the position of the dolly at the end of the program is about the same for all step intervals.
What I imagine is that with these short intervals there is hardly any ramping and so the motor might loose steps. But why is it working with the extremely little intervals ?
Does anybody have an idea ?
Matthias
Let me see if I understand
Let me see if I understand clearly:
* 15 steps results in reduced total movement (not equivalent to 15 steps * shots), but proper accounting for movement (hence the overshooting of home)
* No output ramping was utilized
I'm confused though, you said you tested all from 10-20 and they all worked well (including 15 steps?), or that you tested just 10, 20, 100, and 15?
I think the problem seems to stem, if I'm correct, in the velocity calculations for un-even numbers of steps. I'll start with that assumption, and run some charts through the velocity algorithm, and see if it comes up short. Oddly though, 15 should work out beautifully, and numbers divisible by two and not three should be more of an issue. Either way, it's easy for me to generate the data and see what it actually comes up w/.
!c
Chris, I updated to 0.82 and
Chris,
I updated to 0.82 and the behavior is still the same. But I actually think, it is a problem with my motor, which just is not strong enough.
Is it possible to have the motors ramp for very small intervalls like 5, 10 or 20 steps ? If not, I might just get a gearbox and/or a decent motor to get rid of the problem.
Matthias
Matthias, you can ramp at
Matthias, you can ramp at intervals like 5, just make sure your ramp value is a factor of 5, to make clean ramps (it can only ramp one step, obviously, so '7' would not result in a clean ramp, a ramp of 5, 10, 15, 20, 25, etc. will).
Also, I _was_ able to re-create your problem, but only by overheating my motor/driver. When running for 30+ minutes at 400mA+ on my little NEMA15 motors, after they both had fully heated up (for at least 30 mins), attempts to step at a max rate caused the easydriver to hit thermal shut off, and simply stop taking commands for a second or two, causing a lot of steps to be missed.
By using the new motor kill line, I haven't been able to re-create the behavior, both the motor and the driver stay cold. I believe those probotix drivers have a 'sleep' line as well, that might be beneficial to your needs.
!c