AccelStepper Library feedback on steps

Projects Programming
1

I am having trouble with the smoothness of my stepper motor due to other events happening.
For example, in a simple test to run my stepper at 1/4 micro steps, 200 RPM, and to move it to 90 degrees, I set the position, and then continually call mystepper.run() in my loop. if nothing else is going on, it runs nice and smoothly. But if I try to send a serial command to my motor controller every 100ms, I get interference which causes the stepper to be choppy.
I have determined that with no accel, I would be needing to update the stepper pulse about every 375uS, and that to send out a 3 packet serial command, would take much less than that, so if I actually KNEW when the stepper motor advanced, I could then do my serial send without giving any interference to it. The my stepper.run() is a bool, but it only return true/false based on whether the target destination has been reached. Is there a way to tell when a pulse to the stepper has been sent, so I would know, ok, now is a good time to send a serial command without messing up the timing of my stepper motor?

thanks.

2

Poll whether stepper.currentPosition() changes:

static long lastPosition = stepper.currentPosition();
...
stepper.run();
if(stepper.currentPosition() != lastPosition) {
   lastPosition = stepper.currentPosition();
    sendMessage();
}
...
3

That looks like it’ll work, I look forward to trying it! Thanks.

4

stepper.run() returns true if the motor is still running to the target position indeed.

AccelStepper's currentPosition() returns the position in steps, not microsteps. The value corresponds to the number of full steps as tracked by the library, regardless of any microstepping configured in the driver.

➜ if you want to know when a micro step pulse has been sent, that won't cut it but it will work if you are happy to detect a full step.

Also note that if you've reached the destination, the position no longer changes and thus no message would be sent.

5

Definitely NO. Accelstepper doesn't know anything about the microstepping of the driver. It simply creates step pulses. And if the driver is configured for microstepping, then every step pulse is a microstep. So Accelstepper counts microsteps in this case (without knowing about that). It isn't even easy to know when a full step position is reached when using microstepping.

6

of course, you are totally right. Not sure what I was thinking.

7

So it should work for me. I’ll test it tonight and see.

8

Or you can ditch the AccelStepper library and use the MobaTools library. That library is interrupt driven and does all the steppping in the background so you are free to do other things without it missing a step.

This isn’t entirely true if you are using something like the FastLED library which turns off interrupts while doing its updates, but mostly true.

9

A quick test with MobaTools stepper example, adding in a serial print, and it seems flawless. I’ll have to do to research on this library and try it in my main sketch. Thanks.

10

MobaTools is working great so far. I can send Serial commands, and it doesn’t affect my smooth Stepp motion.

Question; will software serial also work? I have to unsolder some things to test it, so thought I’d ask. Unless I can use software serial on pin 0 & 1, I’ll have to research that…

11

I’m meaning just for testing purposes, to test software serial and the MobaTools, by testing with pins 0 & 1.

No hardware serial, no other connections during testing. If it works fine then I can remove my board and redo the traces.

12

Hi, I never tried SoftwareSerial and MoToStepper together, so it's up to you :wink:.
As far as I know Softwareserial uses interrupts intensively - much more than HW-Serial. And of course it depends on the baudrate.
I think for testing purposes you can try on pin 0/1 if you don't use HW-Serial ( No Serial.begin() ).

[EDIT] And timers could be a big problem: I don't know if Softwareserial uses a timer. MobaTools uses Timer1 on AVR. If Timer3 is available ( eg. on Mega2560 ) it is used for MobaTools, and Timer1 remains free for other usage.

13

A quick look in to the source of SoftwareSerial shows that it switches IRQ'S off during the whole time of sending a byte!

14

SoftwareSerial uses a pin change interrupt for the TX pin, so no timers.

It does turn off interrupts during any transmit, so depending on if the application is sending a lot of data, you could mess up MobaTools if it was trying to move while data is being sent.

15

It sounds like software serial is not a reliable method. I’ll look into other options.

I’m really thinking of just adding another little SMD Atmega328P to handle my stepper. If I communicate to it from another, via I2C, that communication shouldn’t mess with MobaTools timing? I can test that out right now with my current set up. I can use Moby tools to run the stepper and I can poll my AS5600 over I2C and see how it all works.

I could run MobaTools, doing a smooth stepper control, and poll my AS5600 sensor over I2C every 10ms, with no issues, so I should be able to just have a designated 328P chip take care of my stepper, and tell it what to do via I2C.

Thanks for the help.

16

You told us very little about your project so far. Why can you not use HW-Serial but needed to use SoftwareSerial? Using HW-Serial with a stepper should not be a problem.
Instead of using two 386P it may be worth using a MCU with a free HW-Serial?

17

The standard Arduino SoftwareSerial does not use a hardware timer. It relies on pin-change interrupts for receiving. Both receiving and transmitting are handled with calibrated delay loops within the ISR ➜ When a configured pin changes state, the interrupt service routine is triggered and samples the line at the expected bit intervals. While this routine is running, normal sketch execution is suspended and other interrupts are disabled.

This means that timer interrupts are also paused while SoftwareSerial is processing its pin-change ISR and the length of this pause depends on the baud rate.

At 9600 baud one bit lasts about 104 microseconds, so a full 10-bit frame (start bit, 8 data bits, stop bit) keeps the ISR busy for roughly 1 millisecond. At 19200 baud the pause is about 0.5 milliseconds, and at 115200 baud it is only around 87 microseconds. A Higher baud rates shortens each individual pause but increases how often they occur.

Because the bit period is so short at 115200 baud, even tiny timing errors from interrupts being disabled, background tasks, or delay loop inaccuracies can cause incorrect sampling. This makes SoftwareSerial fragile at 115200 and beyond, and it is generally considered unreliable for sustained communication at such speeds.

18

You could look at an ATMEGA328PB - all the familiar trappings of our venerable 328P, but a few more I/O, AND a second hardware serial. It's available at least two ways:

  • Pololu A-Star board - great company, great support, add-ins available for the IDE to make programming simple.

  • SOME Nano clones at Ali-Express, often but not always those with a type-C USB connection, have been updated with the '328PB. The difficulty is identifying one, because they typically don't mention it, and often use photos that are too fuzzy for identifying the chip(and, who's to say they actually used the right photo). If you successfully get one, there are threads on this forum about what you need to do to get them working (sometimes, nothing).

I bought a pack of 10 of the Ali specials, came out to about $3.50 Can apiece, and they work just fine, but you have to pay attention. They used the 328PB, BUT the board they put it on is for a 328P. As a result, two pins who's function changed in the upgrade are fouled. One used to be a ground, now it's a digital I/O, but the board shorts it to ground. The other faces a similar problem. No big deal, as long as you know not to set those pins as outputs. That's a small price to pay for having a second serial, for sure.