Confirm "Encoder" Library Use With Arduino Due MCU Platform

[geng]

I've been reviewing the documentation to use the "Encoder" library with a NEMA 17 STEP motor (200 step/revolution, using the EasyDriver 4.4 board with the A3967 driver https://www.schmalzhaus.com/EasyDriver/ ) with an integrated quadrature encoder attached to the extended shaft of the STEP motor.

I'm using a single Arduino Due 32 bit MCU to monitor and control the STEP motor and the physical capacitive encoder attached to the shaft of the STEP motor.

My main question is: To use the "Encoder" library with the Arduino Due MCU, I just want to confirm that I need to use the "Encoder" library version 1.41 (from 2016) on GitHub ( https://github.com/PaulStoffregen/Encoder )? Which requires installation of the Teensyduino add-on?

Thanks for the help and time.

Note: I'm a bit worried that the Arduino Due MCU CPU can handle the processing required to both drive the STEP motor using the AccelStepper library and also use the Encoder library to monitor/count the quadrature pulses from the physical encoder... Because of this worry, I've ordered a couple of Teensy 4.1 boards, but first I want to make sure the Encoder library can work with the Arduino Due MCU and the Encoder library.

Note: I also found this other different Encoder library for Teensy 4.1 on GitHub ( https://github.com/mjs513/Teensy-4.x-Quad-Encoder-Library ), but I'm not quite understanding when to use the regular Encoder library vs this other Encoder library. But I will look into that later on a separate forum string. Just interested in getting the right Encoder library to work with the Arduino Due MCU right now.

 

[geng]

Hi:

A follow-up question regarding the ENCODER library while using the STEPPER library. We've noticed that in the past with the Arduino UNO and DUE that the step motor functions seem to slow down or change behaviour when also running and monitoring the encoder. Take the encoder off the configuration, and the step motor functions as it should again.

Does anyone have an example program for running the ENCODER library and the STEPPER library on the same Teensy or Arduino Due/UNO? I looked all over and can't find an example program that runs these two libraries on the same MCU with the encoder directly on the shaft of the step motor.

Thanks for your help and time.

 

[mjs513]

If you are going to use a Teensy you can check this out: https://github.com/luni64/TeensyStep. As for using the encoder library and stepper library and issues with DUE/UNO I can not help you with that that. Don't play with steppers to be honest.

 

[geng]

If you are going to use a Teensy you can check this out: https://github.com/luni64/TeensyStep. As for using the encoder library and stepper library and issues with DUE/UNO I can not help you with that that. Don't play with steppers to be honest.

Thank you for the information. Greatly appreciated.

Yes, I'm planning to check out the TeensyStep library with the Teensy MCU (compare that setup to the Arduino Due performance). Right now, I'm just trying to get the ENCODER and ACCELSTEPPER libraries working on a STEP motor with a capacitive incremental coder directly attached to the rear shaft of the STEP motor and both controllers with the Arduino Due.

 

[PaulStoffregen]

We've noticed that in the past with the Arduino UNO and DUE that the step motor functions seem to slow down or change behaviour when also running and monitoring the encoder. Take the encoder off the configuration, and the step motor functions as it should again.

That's not too surprising for Arduino Uno. The encoder library generates a lot of interrupts, which will siphon off a lot of the CPU time. I'm a little surprised to hear it's also a problem on Due.

Most of the Teensy 3.x board are faster than Due, and the Teensy 4.x boards are *much* faster, so this should be less of a problem.

 

[geng]

Thanks. Appreciate the information.

We mostly got the STEP motor working with the ENCODER library and the AccelStepper library smoothly with the Arduino DUE. But we can't even serial print readings or the motor performance is negatively impacted and the motor behaves different (you can hear and see it clearly). Next we'll try the same setup and code with the Teensy 4.1s I ordered and see if there is a difference.

Now trying to verify the accuracy of the counts generated by the ENCODER library quad decoder for one revolution. The counts seem to change slightly each test, but maybe there are other factors involved causing this. Just want to ensure it's consistent (I believe it should be 8192 counts per revolution for a 2048 PPR incremental encoder with the motor speed set to 1RPM which is 26.6667 steps/sec for a 200 steps/rev STEP motor with 1/8th micro-stepping, or 1600 microsteps/rev)

Maybe I'm missing it, but the other thing we found out is the the ENCODER library is not meant to track/interface with the Z (aka Index) signal (gated to the A & B signals) from the encoder. So now also looking for a sketch example to home the encoder using the Index signal on a incremental quadrature encoder.

 

[luni]

Actually a Teensy should have no problem at all to drive a stepper and read out an encoder at 25kHz. However, Accelstepper relies on calling run/runSpeed with at least the maximum step frequency, the faster the better. Depending on how you organized your code in loop, it can be that you don't call run() often enough. Might help if you show us your code.

You might try to call run() from within a timer interrupt. E.g. something like this:

//....
AccelStepper s1;
IntervalTimer t1;

void setup()
{
    //...
    t1.begin([] { s1.run(); }, 20) // call s1.run every 20µs (50kHz) in the background

//...

 

[geng]

Actually a Teensy should have no problem at all to drive a stepper and read out an encoder at 25kHz. However, Accelstepper relies on calling run/runSpeed with at least the maximum step frequency, the faster the better. Depending on how you organized your code in loop, it can be that you don't call run() often enough. Might help if you show us your code.

You might try to call run() from within a timer interrupt. E.g. something like this:

//....
AccelStepper s1;
IntervalTimer t1;

void setup()
{
    //...
    t1.begin([] { s1.run(); }, 20) // call s1.run every 20µs (50kHz) in the background

//...

Thanks for this, I will verify this approach on the Arduino Due and get back to you all with the code. I just want to go through the code changes and clean them up first. Will post the code and my latest measurement findings in a couple days.

Also, I've noticed others mention the ENCODER library does not handle the Index (Z+) signal, so you are on your own to do any error checking when the ENCODER counts get out of line with the position of the step motor actually is.

I was going to try this approach/logic for the error checking and autocorrecting small errors (where the error check value is not equal to zero) that I read in an article (see attached image).

See attached image where the error checking and small error autocorrect approach is described.



I guess autocorrect means based on the feedback from the ENCODER library information used to calculate the error checking, you would send a command via the AccelStepper library to advance or hold (we only go one direction, clockwise) the next step of the step motor by the amount needed to eliminate the error value and ensure the error checking value stays at zero. This constant error checking and autocorrect if/when needed is even more processing time on the Arduino Due CPU or Teensy 4.1 CPU

 

[PaulStoffregen]

I believe you should set that Arduino Due aside and give Teensy 4.1 a try.

Judging only by clock speed, you might expect Teensy 4 to be about 7 times faster. But Due uses Cortex-M3, which isn't nearly as powerful as Cortex-M7. The M7 can execute 2 instructions per clock. It has branch prediction, large caches, large tightly coupled memory, and lots of other features that make it so much better than M3.

The CoreMark benchmark shows you get about 24X faster performance if you step up from Arduino Due to Teensy 4.x.