Driving two stepper motors

[tenaja]

Bill, that's very good looking. I wrote a similar program in Proton. I made one timer a high priority interrupt, and the other low. Obviously not necessary but since I wanted one axis more accurate than the other, the one always got priority.

If you ever decide to try to squeeze more speed out of it, toggle the Step pin high (your Drive pin) immediately at the top of the interrupt axis section. Then at the bottom of the interrupt, toggle it back. (My motor drive moved when the pin went high.) What that will do is allow you to go through the interrupt without the delay loop. Most drives will have a spec for the minimum pulse width, and the rest of the int routine took longer than that requirement on my drives. If you implement this, then your motion can be more consistent. (But maybe that doesn't matter for your application.)

[Bill Legge]

Tenaja,

Thanks for your comment. That's a good idea - I presume toggling the drive pins will be OK as long as they stay high for the minimum time for my driver - 5uS.

I'll give it a try.

What I want to do next is incorporate a ramp-up/down (for constant accelleration) but can't see how to do it with both motors?

I've done it with one motor OK:
1. Using a list of pulse times held in EEPROM, as in David Benson,s book 'Easy Step'n'.
2. Using a maths routine to calculate the periods - too slow in PBP.

Any ideas how to do it with two motors?

Regards Bill Legge

[tenaja]

Well, to get true linear accel, you either need a long lookup table or a complicated calculation--just as you've already worked out.

I've tried a calculation (look on embedded.com for a few acceleration formulas), and it takes up to 105uS to do it in Proton, for each pass through the calc (on a 40MHz 18F). PBP would be similar, or maybe a couple uS slower. Either way, you are limited to about 9khz for a single axis or 4.5 for two, but you'll have to calculate them out of the interrupt so they are prepped for use inside it. (You will also have to deal with context saving, which you short-cut on your posted code.) I've considered buffering the calculations in an array so when the motors are going slow you can calculate a lot of values so when it is going fast you have some done ahead of time. You'd be limited by RAM, though.

Since I was more concerned about simplicity and overall travel than smooth motion, I did it a little different. I used a delay scale, then by trial & error came up with a few Case statements that shifted it left (increasing the delay offset) or right (reducing the offset) depending on the current speed. I just tuned it by ear (literally), listening for the motor accel to sound smooth. The problem with adding/subtracting a constant to the time delay is that at higher speeds the change is drastic but at slower speeds the same change is hardly noticeable. That's why I did the select/case to shift it. You end up with stepped acceleration, but it sounded smooth and worked for me.

I wouldn't do it for cnc, though. For CNC you need one of the two previously mentioned accel methods.

[tenaja]

Oh, yeah... if your drive only needs a 5uS pulse, you should minimize the delay in the interrupt, or use it to check for a second interrupt. At 40MHz that is 50 instructions minus the call/return, and you could exit early if you were going to handle the other motor stepping.

[Bill Legge]

Tanaja,

Yes, I've seen the embedded.com article by David Austin. There is also a good application note on the ATMEL site (Application note AVR446) that has rampup/down calculation:

Cn = Cn_1 - 2*Cn_1/(4n+1)

In the C language - I have yet to see if PBP is fast enough to do this.

Was the formula you used like the one above or was it the more complicated 'exact' calculation that needs square roots? If it takes 105uS that's in the ball park for my application.

Re 'context saving' - if you mean 'wsave' and so on - I don't think it's necessary on the PIC18F8722?

Regards Bill Legge

[tenaja]

Yes, I've seen the embedded.com article by David Austin. There is also a good application note on the ATMEL site (Application note AVR446) that has rampup/down calculation:
Cn = Cn_1 - 2*Cn_1/(4n+1)

In the C language - I have yet to see if PBP is fast enough to do this.

Was the formula you used like the one above or was it the more complicated 'exact' calculation that needs square roots? If it takes 105uS that's in the ball park for my application.

1. The concept that Basic is slow and C is fast is a remnant of the 70's when there were no basic compilers, just interpreters. Although it has bee nreduced to a myth that won't let go, in reality it is now all about which compiler author wrote efficient code--not which language he wrote. Recently someone posted that PBP compiled some code in 460 words, but MikroB wouldn't even fit in the chip. My guess would be that the MikroC would be just as bad, unless they had two compiler authors and one was a lousy coder. BTW, in short code, PBP and Proton are similar... but when it gets long, or you use a mix of Words and Longs, Proton really shines. (And when using interrupts.)
2. That's the article and formula I was talking about. without much tweaking, it was running at the speed I previously quoted. It takes around 400 instructions to do a 32 bit sqrrt on a PIC... only good for buffered or slow moves.

Re 'context saving' - if you mean 'wsave' and so on - I don't think it's necessary on the PIC18F8722?

The 18F does save the wreg if you use the Fast Return, but not the variables you are changing and the registers related to them. For instance, if you are in the middle of changing an array value and an interrupt occurs, and you access an array (any array) in the interrupt, you have to save the INDF & FSR registers and anything else PBP uses to manipulate arrays. Proton has this built in, and many PBP users have used the DT Instant Interrupts... which is kind of an oxymoron since all of the saving removes the instant part.