Submitted by shutterdrone on Fri, 04/16/2010 - 15:24
Posted in
... yup, started working on it last night.
Was able to get two axes running at the same time w/ async control (meaning you don't have to wait, and can do other things at the same time) at about 10kHz with a configurable velocity ramp.
So, it looks pretty straight-forward and do-able, it will still require a lot of modifications to the state machine to add it to the engine, but it looks like I'll be able to enable you guys to use real-time joysticks for positioning and stuff soon.
A little poll though: for 'real-time/async' control -- do you guys expect to be able to control multiple motor axes at once, or one-at-a-time? I ask because the complexity of managing multiple velocity curves at once in the async control greatly complicates the instruction set and slows us down to a theoretic max of somewhere around 2-8kHz step rate when using all four motors with how I intend to implement it.
!c
Chris, do you ever sleep ?
Chris,
do you ever sleep ? ;-))
I think it should be possible to move at least three or four axis at once. It's needed for realtime moco for sure.
Just my two cents...
Matthias
Not if I can avoid it! Just
Not if I can avoid it! Just kidding, I get a good 6 hours each day, and still find time to fish (going tomorrow, actually =) *grin*
Yeah, I can make all four move at once, just not as fast as I can make one move =) It will limit the top speed below the configured max (cfg max RPM = (1000000 / min_step_delay) * 60) if the configured max speed is below the # of instructions as calculated against the instruction speed, yadda yadda...
So, I think the absolute max possible with all four axes going different distances would be around 2,000 steps/second - but all motors would move at 2,000 steps per second at the same time. (Assuming they were all at a 'peak velocity' point in their movement.)
Of course, if they're all going the same distance - then, well, we're back up to speeds in the MHz range!
This is not to say that it's impossible to reach speeds in the MHz range - and, in fact, I've challenged one of the devs I work with to find an algorithm that uses fewer instructions than I do now; but that the effort may not be worth the few cases that would actually need those speeds. (At 2MHz my 120:1, 8 microstep setup would do 10 and 1/2 360' rotations per second!)
At the low level, it's just two instructions to step all four motors (PORTD |= B11110000), but the ISR called to change the status of the pins is 4 instructions on exit, and I'm currently cheating and rather than throwing the ISR at every min_step interval (wasting a min of 8 cycles every 240uS or so) and asking whether I should be firing (which will be needed for the multi-independent axis), I change the overflow value on Timer1 (which is the timer I'm using) while in the velocity ramp. Obviously, when it comes down - I can't cheat, and will have to throttle the PORTD register based on which motors should step this cycle - which means 4 if statements touching 16 or 32-bit values, so a minimum of 6-10 instructions to know whether a motor should step.
!c
Sweet! That's awesome news.
Sweet! That's awesome news.
I'm happy as pie with single axis quality/quick moves vs multi axis potentially slow/wonky...
I can't even rub my head and
I can't even rub my head and chew gum at the same time so why should my camera :-)
Excellent work.
For us realtime nuts
For us realtime nuts multiaxis is a must! Pretty please with sugar on top, give us multiaxis.
All the best.
Ludvig
Cool deal guys - I'll make it
Cool deal guys - I'll make it run whatever you want it to run, when you want it to run.
Also, how about a "go to" kind of command, where you specify up to 4 coordinates on a graph, relative to home for each axis, and it just goes there? For non-interactive stuff, that is?
e.g.: go to (x) (y) (a) (b) --> go to -5000 3500 -23000 0
It seems like it would make the scripting engine complete in the control sense.
!c
Sounds good to me!
Sounds good to me!
I'd love to get real time
I'd love to get real time control of more than one axis - - but yes, it's tricky to keep the timing stable when other things are going on. The folks at makerbot handle this by having one small uC handle the pulse generation per axis - - this seems like a good idea to me, that way they don't block each other. Maybe something like that could work well here.
3ric, check out the nanomoco
3ric, check out the nanomoco thread =)
!c