Update Stepper to wrap AccelStepper

[soundanalogous]

I'm open to completely rethinking the interface. To avoid breaking existing client support we should use a different command byte (I'm proposing 0x62) and deprecate the old version (0x72). Since this will be a wrapper library (wrapping AccelStepper) it should be created in a separate repo in the same format as FirmataEncoder. I will need to rename FirmataStepper in the utility folder to allow the wrapper library to be named FirmataStepper. StepperFirmata will then be deprecated.

Start with the updated protocol: firmata/protocol#42

[soundanalogous]

Consider the requests from #26 and #2

[DomAmato]

what features do we all want to wrap? Also I think this is the most recent revision here:
https://github.com/d235j/AccelStepper
though I don't know if that is the dev repo
That one should be up to date with this
http://www.airspayce.com/mikem/arduino/AccelStepper/

[DomAmato]

Looking over the header class it seems we should aim for

• A config/constructor
• move absolute
• move relative
• set Acceleration
• Set Speed

Maybe

• set a max speed
• distance to go
• target position
• current position
• disable outputs
• enable outputs
• set min pulse width <- probably will never get called fast enough
• set enable pin <- not super sure what this does
• set pins inverted

We can't do

• run to position <- a blocking function
• run speed to position <- a blocking function
• run to new postion <- a blocking function

[soundanalogous]

One way to start would be to define the ideal stepper interface regardless of what is wrapped. You had some proposals for the protocol a while back so that could be a place to start and solicit feedback.

[soundanalogous]

We could start by breaking out the proposed commands from here into a list. Maybe do that here: firmata/protocol#42. No need to work out all the details of the protocol yet, just get a list started and then see if others have any feedback. I can bring it to the attention of some people in the nodebots community as there may be some opinions there.

[dtex]

Finally found some time to work on this and am making good progress. I'm finding however that I'm limited in the number of steps I can make per second. Is the frequency of calls to loop() just dependent on what the hardware will allow or is there a predetermined interval?

I'm maxing out around 450 steps/sec right now.

[soundanalogous]

It depends on the clock speed and the amount of work being done in the loop. There is no way I know of to make it faster other than running on a faster microcontroller and making sure you don't include unneeded Firmata features.

[dtex]

WIP for Configurable Firmata and firmata.js.

All the AccelStepper stuff from my Stepper 2 Proposal is in there and working with the possible exception of enable (the motor controller I've been testing against has the enable pins hard wired). So far I've only tested 4-wire full step and 4-wire half step and those both work great. Need to order more steppers and controllers to test the other configurations but accelStepper is handling most of that so should be in pretty good shape.

Still need to add support for multiStepper and test, test, test.

[soundanalogous]

This looks good so far. I only have a couple of steppers and a single EasyDriver and a breadboard with a simple h-bridge driver so I can help with some basic testing.

[soundanalogous]

I'll also starting thinking of a strategy for rolling this out. I don't want to call it StepperFirmata2, I'd rather deprecate the old version entirely. The Firmata protocol will get a minor version update when this feature is released so a client application can check the version to determine which interface to use. However this makes the client side implementation a bit more complicated and probably necessitates keeping the old version around for a while or throwing an error upon seeing the old config ID, informing the user to download the latest version of ConfigurableFirmata.

[dtex]

Here's the script I've been using for testing... https://gist.github.com/dtex/6a601c138f9b9184b214c29b718bcb10

[dtex]

There are two commands that I documented in the Stepper 2 proposal that are not handled by the multiStepper class in the accelStepper library. Specifically, "stop" and "report positions".

To make this work I will need to create a sub class in configurable Firmata that exposes the individual members of the group (they are private in multiStepper). That way I can call stop() and currentPosition() on each member. The drawback of course is that this adds some heft and complexity Stepper 2.

This functionality can be handled higher up the chain by making multiple calls to stop. It seems to me that minimalism in configurableFirmata should win out and this functionality can be handled in firmata.js or Johnny-Five (or whatever the client happens to be).

Do you agree?

[soundanalogous]

How important is having stop and reportPositions in MultiStepper?

My concern with handling that from a client is latency, but I guess you could probably send a reference to all steppers to stop or report positions for in a single command.

Another option, to handle things on the board side is to add a getStepper(index) method to the MultiStepper class (since you're embedded it anyway) that returns a pointer to that stepper object. Then when the stop or reportPositions message is received from the client, iterate over the steppers that belong to that group. But then of course getStepper has to be copied each time a newer version of MultiStepper is embedded.

[soundanalogous]

Done thanks to @dtex! #72

[LinuksGuru]

Hi! I'm having some problems with library. Right now I can init, start, stop motors, with smooth acceleration (with Python on Raspberry Pi). Unfortunately, there are things which don't work for me.

1. Report position. Code snippets attached. Returned position is always "0". Looks like coded something wrong. If you have samples how to properly use "report position" it would be great.

2. Smooth stop command when move is still NOT complete. I have no idea if its possible to reset (re-init) number of steps while motor still spinning. If this is technically possible, report position feature is required (p 1).

Thanks in advance for any help.

def accStepFmt_Step(brd, dev_no, num_steps):
    cmd = bytearray([acc.ACCELSTEPPER_STEP, dev_no])
    cmd.extend(ecn.encodeIntTo7bitSysex(num_steps))
    brd.send_sysex(acc.ACCELSTEPPER_DATA, cmd)

def accStepFmt_ReportPosRequest(brd, dev_no):
    cmd = bytearray([acc.ACCELSTEPPER_REPORT_POSITION, dev_no])
    return brd.send_sysex(acc.ACCELSTEPPER_DATA, cmd)
  
def accStepFmt_ReportPosReply(brd, dev_no):
    sb = bytearray([0] * 5)
    cmd = bytearray([acc.ACCELSTEPPER_REPORT_POSITION, dev_no, sb[0], sb[1], sb[2], sb[3], sb[4]])
    brd.send_sysex(acc.ACCELSTEPPER_DATA, cmd)
    return ecn.bytesToInt(sb)