Stepper motor library homing/limit capability

[soundanalogous]

From @FineLineAutomation on March 23, 2014 20:5

I have been looking over the stepper motor library and was wondering if there was a way to stop a motor movement based on on a digital input going low. I have 2 use cases:

1) Using a stepper for position control you get to the end of physical motion and would like to put a limit switch in place that can stop the stepper. 2) Performing a homing operation on a stepper controlled motion axis with

I could always perform #2 by bit banging everything from the PC, but would prefer to use a higher level command if necessary.

I also thought about just doing it in hardware and just having the limit switch trip the enable pin on the Big Easy driver I am using, but you would need some way to manually control re-enable that pin to get it to move off the switch.

Copied from original issue: firmata/arduino#124

[soundanalogous]

There is currently no way to do this. However it makes me think it may be beneficial to add a 'stop' command to the stepper implementation. Then you could watch a digital input. Depending on the step speed you could potentially get one additional step by the time the digital input changes.

[soundanalogous]

From @FineLineAutomation on March 23, 2014 22:5

I am not worried about one additional step, especially at the microstepping resolutions of driver. I would think that something like this would also be very nice for implementing a software emergency stop. I think a stop command is nice, however, I would say that being able to set a stop pin input attached to a particular stepper motor and have the ardunio watch it during moves might be a worthwhile implementation. Either way will work.

How do y'all test the stepper motor implementation? I haven't found any PC side library that implements it?

[soundanalogous]

See my reply to your post on the firmata dev email list. There are at least 4 Firmata client libraries that support the stepper motor implementation.

[soundanalogous]

From @ntruchsess on March 23, 2014 22:33

yes, I've been missing a 'stop' command (or even better the opportunity to move until a digital pin changes it's state) as well. At the end of such movement the stepper should report the number of steps (or it's position?) to the client.

[soundanalogous]

Are you thinking stop with the ability to resume? In that case clear would would also be useful unless starting a new sequence (even if just a single step) automatically clears the prior sequence.

[soundanalogous]

From @FineLineAutomation on March 23, 2014 23:40

I am thinking that it should probably up to the PC to figure out what the device needs to do in the event of a stop. In each of my use cases I don't need the ability to resume where the stepper left off. I think that if you just stop and post the number of steps moved back to the PC, the PC should be smart enough to calculate what it needs to do and handle any resuming with a new move command. That way we can keep the stepper implementation as small code wise as possible.

[soundanalogous]

From @DomAmato on January 10, 2015 8:35

I was playing with this for an implementation I needed and found a few things that seemed to work. The way I implemented it prevents the stepper motor from moving in the same direction but allows it to move in the other direction. It doesn't stop the motor though I probably should add that. Certainly the feature seems easy enough to add since the run state already includes a STOP which a command could just automatically set the runstate to effectively stopping the motor.

https://github.com/DomAmato/Robust-Firmata

Actually this could perhaps help me with a problem I ran into, if the pinModes weren't set in the constructor they didn't seem to work so I had to include it in the constructor. Is this caused by the implementation of the steppers being a pointer? I also had an issue with the encoder library not working as a pointer at all and had to add an empty constructor as a work around.

[soundanalogous]

Are you specifically talking about setting the pin modes for the limit pins? I see in RobustFirmata you're setting them to STEPPER, but they should be set to digital input or output since that is their function.

I'm also going to change the Stepper implementation at some point to use static rather than dynamic memory allocation.

Also if you want to propose an addendum to the stepper protocol, please open a pull request against: https://github.com/firmata/protocol/blob/master/stepper.md. See how I have done something for the I2C protocol: https://github.com/firmata/protocol/blob/master/i2c.md.

[soundanalogous]

From @DomAmato on January 10, 2015 20:50

I am. In an earlier version I had a separate function that would add limit pins but within that function when I set pinMode to input_pullup it didn't enable the pin and would never work. Perhaps it was an error on my end but the code was pretty simple and for the most part is what I ended up moving over into the constructor.

I am still tinkering with the functionality of the implementation so I have waited before proposing an addendum. I wanted to make sure it worked properly before I did that so that I didn't propose something and then change my own protocol.

[soundanalogous]

see https://github.com/firmata/ConfigurableFirmata/issues/33

[dtex]

We haven't added limit pins to in AccelStepper, but we have the ability to use digital inputs and send a stop command from the host server. Perhaps this issue can be closed?