accelStepper

[dtex]

Implementation of stepper 2.

Works with this PR in ConfigurableFirmata

Still needs tests and testing. Also name may change from stepper2.

Here is the protocol PR: https://github.com/firmata/protocol/issues/87

Still lots to do of course, but let me know if I should squash commits before this gets merged.

[soundanalogous]

Do you have an example script you are using? I recommend adding it to the examples directory. At least temporarily.

[dtex]

I'll get a couple in tonight (one for accel and one for multi)

[soundanalogous]

What are you using for 2 and 4 wire testing? I just use a couple of L293D H-bridges (one for a 2 wire configuration and another for a 4 wire configuration) on a breadboard. Curious if you've found any breakout boards or shields, etc that you prefer or if you just wire up a custom circuit as well? I use an EasyDriver for the step + direction configuration.

[dtex]

I've been using a couple of L298 breakout boards. One is from Keyes and the other is a no-label Ali Express special. Both are in four wire configurations. I honestly don't know anything about two wire stepper configurations (other than step+direction type) and couldn't find anything with Google.

I soldered up any Easy Driver today to test with, and also dug up an Arduino Motor Shield V1 and V2. I have some three phase motors on the way from eBay.

[soundanalogous]

Regarding 2 wire unipolar or bipolar drivers, this is the article + schematics I used: http://www.tigoe.com/pcomp/code/circuits/motors/stepper-motors/. Specifically the bipolar example with the 2 NPN transistors.

[soundanalogous]

you know that's old when an article has basic stamp code in it :-D

[dtex]

Those examples are ready

[soundanalogous]

Thanks. Trying them now.

A couple of early observations:

• Step + Dir doesn't seem to work. It only takes 3 steps with my EasyDriver, but 4 wire with H-bridge works
• The speed isn't right if an acceleration value is not specified. It's significantly slower if you omit the call to stepper2Acceleration.

[dtex]

It only takes 3 steps with my EasyDriver,

How many steps are you asking for on Step + Dir? I'm testing for the first time right now and I am getting 1/8th steps even thought my MS1 and MS2 logic pins are set low (which should be full step).

The speed isn't right if an acceleration value is not specified.

I believe this is expected behavior for accelStepper. We could certainly put in our own default for this.

[soundanalogous]

This is working for me now. I just had to switch the step and dir pins (but that should really be done in the firmware, not here).

[soundanalogous]

Currently stepType has no effect when using a DRIVER type board. We could however use the stepType as a multiplier so that the user can specify the actual number of steps in stead of the number of sub steps.

For example, by default an EasyDriver is configured for micro stepping (1/8) so if a user wants 1000 steps, they actually need to pass (1000 * 8) and to get the correct speed and acceleration they must also multiply those values by 8 as well. We could instead handle this under the hood (and I think this would be better handled in the client library than in the firmware). We'd also need to add a 1/4 step type, so we'd have WHOLE, HALF, QUARTER and either MICRO or EIGHTH (?). We're currently limited to WHOLE and HALF for non DRIVER types but that could be documented and also enforced in code (if not DRIVER type and stepType > 1 then stepType = 1 and print a warning to the console). But of this would have to be made clear to the user. Thoughts?

update I need to verify that the non DRIVER types actually work this way since it's just an assumption I have at this point (where WHOLE + 1000 steps will be 1000 steps and HALF + 1000 steps will be 1000 steps instead of 500 steps... need to verify).

[dtex]

I'll normalize the step/direction pin ordering to match accelStepper across protocol, configurableFirmata and firmata.js. Makes sense to keep it the same everywhere.

by default an EasyDriver is configured for micro stepping (1/8)

Ohhhhh they're pulled high. I missed that.

if a user wants 1000 steps, they actually need to pass (1000 * 8)

I guess in my mind the step "size" is what changes. Setting step type to HALF instead of WHOLE effectively turns a 200 step per revolution motor into a 400 step per revolution motor. That seems to be how both accelStepper and easyDriver reason about it with a "step" being one increment of the chosen type.

[dtex]

With non driver types, HALF + 1000 = WHOLE + 500.

[soundanalogous]

If I run this on a 4 wire configuration with a stepType of either WHOLE or HALF, I get exactly 10 steps.

    board.stepper2Speed(0, 4);
    board.stepper2Acceleration(0, 0);
    board.stepper2Step(0, 10);

[soundanalogous]

If I run this on a DRIVER configuration, I get exactly 10 steps.

    board.stepper2Speed(0, 4 * 8);
    board.stepper2Acceleration(0, 0);
    board.stepper2Step(0, 10 * 8);

With the 4 wire configuration no multiplication is necessary because it's handled by the AccelStepper library.

[soundanalogous]

I'm counting steps here also by what is audible. Maybe I just can't hear the microsteps.

[soundanalogous]

Okay interesting, I had never really though about it this way, but the count seems to really depends on what a user's perception of "steps" is. Substeps (half, quarter, eighth, etc) happen in quick succession, whereas there are larger intervals that you can hear/feel more easily. These larger intervals align with what the stepper2Step value is set as. I'm not sure however if this is specific to EasyDriver or a universal principle for stepper motors. I'd have to dig in more to figure it out.

Correction the value passed to stepper2Steps is the total number of steps (including substeps) but does not necessarily align with the perception of number steps that occurred).

[dtex]

You can definitely hear half steps on a four wire stepper, but they are much more subtle (smoother). I imagine wether you hear it or not depends on a lot of variables. Torque increases with higher voltages so the motor will snap into place with more force and be more audible. Motors with bigger steps are more likely to be audible as well.

It's easier to tell how many steps you are getting by finding the number of steps per revolution for your motor, and then asking for that number of steps. If it's a 200 step motor and you ask for 200 WHOLE steps it should turn exactly 360 degrees. 180 degrees for 200 HALF steps.

[soundanalogous]

But the way AccelStepper works, if you have a 200 SPR motor set stepType to HALF and set the number of steps to 200, it will still turn 360 degrees, because in half-step mode AccelStepper runs each step sequence twice in a row per call to step. You can see this here for the 4-wire configuration: https://github.com/firmata/ConfigurableFirmata/pull/72/files#diff-6264683f37652d37d943fd4f8ac70e28R502.

[soundanalogous]

Actually it's not running the same sequence twice in a row, it's running 2 half sequences making a whole sequence.

[dtex]

You're losing me here. There is just one call to step8 for each call to step and there is never more than one call to step on a pass through the loop.

[soundanalogous]

Nevermind, tested again and your right :)

[soundanalogous]

I never use stepper motors so you'll have to bear with my confusion as I gain an understanding of how they actually work. I think I have a pretty good grasp on them now. The steps-per-revolution tip is what helped make it all click.

[soundanalogous]

Have tested successfully with a 2 wire configuration. I still need to test groups but that will have to wait for another day. Also I don't have a 3 wire configuration to test. Not sure how common that is.

[dtex]

The three wire is actually for three phase motors which aren't really stepper motors. The most common three phase motors are those harvested from old hard drives. I don't have any either, but I ordered some off eBay.

[coveralls]

Coverage decreased (-13.2%) to 86.777% when pulling 5f9fcd960dafc9cef8aaa3e4487bf94d52be73c0 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-12.9%) to 87.085% when pulling 3da6efb5d624aef82b0a898e57e2247704a76f07 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-9.9%) to 90.143% when pulling f6fa06aeaff3e7b158ec5e6e80c77588790d66b8 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-1.3%) to 98.701% when pulling a5d46f0130d1be6092970a39a699dea8e0a61888 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-0.5%) to 99.528% when pulling 2889fc2e1e0ffe9bb3f6df4d7d4f174efe0cc59d on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-0.6%) to 99.414% when pulling 919a64fd72336112f26077292afdd0b5a02369a0 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-0.5%) to 99.531% when pulling 70c50a9672cbd2a60aebcd4c1a55e4a854aca5a4 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage decreased (-0.5%) to 99.53% when pulling 14be7e2d0a2ff45fd0e2845a74702741c7910e49 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage remained the same at 100.0% when pulling d4005daf7566296ffef5d07efe533e6594eb9f8e on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 68b4d77da4e91f4a7a34ca121dc74f5dacb46683 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[dtex]

@soundanalogous

Update:

Three wire works fine, though I'll be darned if I can think of a good use. Maybe I'm just using crappy motors.

I can hit 920 steps per second with stepper2 in firmata so my assumption that stepper2 would be significantly slower was incorrect.

I have a couple of questions:

Should I squash commits on this and the PR's for protocol and configurableFirmata?

Should I remove stepper and rename stepper2 to stepper?

I've still only tested with an Arduino Uno. What other micro-controllers do you suggest trying?

[coveralls]

Coverage remained the same at 100.0% when pulling 29e9f8ffd98b128e0339d937c89a649b13784496 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[soundanalogous]

I've still only tested with an Arduino Uno. What other micro-controllers do you suggest trying?

One thing I do is compile the code against several different architectures. You can simply do this by selecting different boards in the Arduino IDE then compiling (you don't actually need the boards). I recommend trying to compile for the following boards (you may need to install some of the using the Arduino Boards Manager):

• Zero or MKR Zero
• Due
• Arduino 101
• Leonardo
• Mega
• Teensy 2.0, LC, 3.2, 3.5 and 3.6
• Generic ESP8266 module
• Intel Galileo or Edison (although these are now discontinued boards).

You may see complier warnings as you try different architectures. The Xtensa complier used for the ESP8266 boards for example is very strict. I look over the warnings but tend to ignore a lot of them unless it seems like it could be a real issue.

As far as testing on physical boards, I'd recommend the following if you have them:

• Arduino Zero or MKR Zero (SAMD architecture)
• Arduino Leonardo (or other ATmega32u4 architecture board)
• Any of the Teensy boards if you have one (but preferably LC or one of the 3.x boards)

[soundanalogous]

Should I squash commits on this and the PR's for protocol and configurableFirmata?

Yes please.

[soundanalogous]

Should I remove stepper and rename stepper2 to stepper?

I need to think a bit more about how I want to properly deprecate the older Stepper.

[coveralls]

Coverage remained the same at 100.0% when pulling 0a196d6f0b59ca0fc9a1b29da169a60a6a9adc8d on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 0a196d6f0b59ca0fc9a1b29da169a60a6a9adc8d on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[dtex]

Fixed all the checks where pin value could be zero. I'm really bad about that.

Also squashed all the commits (for the other PR's as well). Sparkfun is going to send me a couple of the boards you mentioned they are kind hearted and awesome. Compiling for Zero is throwing a ton of errors, but they are all in servo.

[coveralls]

Coverage remained the same at 100.0% when pulling 5ad3b8d0912e341922244ad07358556c067de241 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[soundanalogous]

Let's call this feature AccelStepperFirmata and mark the old Stepper constructor and associated methods as 'deprecated' and add a note to the old constructor asking users to use the new AccelStepperFirmata instead.

@rwaldron does this sound good to you?

[dtex]

To be sure i'm clear... Do you want the old constructor still work (with the warning) or should I remove all the old stepper code from this, and configurableFirmata?

[soundanalogous]

I think we need to keep it for a while since other projects that depend on firmata.js may still depend on it for a while. That's where I wanted Rick's feedback to be sure.

[coveralls]

Coverage remained the same at 100.0% when pulling 7b237dbb1e9e02dc181f177d3bc5a8eee9cb1851 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[coveralls]

Coverage remained the same at 100.0% when pulling e1fc76e10b0f60593408f374aeef7e830067e708 on dtex:stepper2 into 0523f58025655ce1d03ef991daf86d68f28917f2 on firmata:master.

[dtex]

No worries. It's not like I have a strong argument for using 0 over 1.

---

From: Jeff Hoefs notifications@github.com Sent: Thursday, July 20, 2017 5:32:22 PM To: firmata/firmata.js Cc: Donovan Buck; Author Subject: Re: [firmata/firmata.js] [WIP] Stepper2 (#176)

@soundanalogous commented on this pull request.

---

In lib/firmata.jshttps://github.com/firmata/firmata.js/pull/176#discussion_r128646469:

@@ -478,15 +501,14 @@ function Board(port, options, callback) {

this.STEPPER = { TYPE: {

• DRIVER: 1,
• DRIVER: 0,

You'd have to make a separate object called ACCEL_STEPPER unfortunately.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/firmata/firmata.js/pull/176#discussion_r128646469, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA0Lfy10x7TFV5aN9rElld3K9q4HIPPFks5sP9VygaJpZM4OMkzc.