|
|
Post by shieldbuddy on May 18, 2018 10:37:13 GMT
Yes!
|
|
|
|
Post by Admin on May 18, 2018 12:50:54 GMT
If the DIR+ pin changes state then it is hard to see why the motor does not change direction. There might be a problem with the AcelStepper.cpp. The ShieldBuddy is around 20x faster than the MEGA and so some things may run too fast.
We will get a TB660 board and try it with a ShieldBuddy.
|
|
|
|
Post by shieldbuddy on May 18, 2018 19:55:51 GMT
Ok, next week we have to use another driver (see previouse posts) with accelstepper and shieldbuddy.
Will report back the results.
I'm really thankful for the help.
Accelstepper liberary is used offten by arduino users.
N
|
|
|
|
Post by shieldbuddy on May 22, 2018 9:59:37 GMT
Did you all ready get the TB660 board?
|
|
|
|
Post by shieldbuddy on May 28, 2018 7:47:46 GMT
OK, does the DIR+ pin change state? Sry just chacked but the DIR+ pin does NOT change state, its always 0 Volt. No mather what direction i put in. Please help, we hope to get the schield buddy to work with accelstepper.h in the next few days. tnx |
|
|
|
Post by shieldbuddy on May 28, 2018 14:32:46 GMT
Is there anything that i can do? Just done testing with this Driver: www.leadshine.com/UploadFile/Down/ES-Dhm_V1.1.pdfAnd stil no direction pin that changes states. always LOW Also with this dother driver i can't get the correct speed to run the motor. Something is off. Also setSpeed command does not turn the motor. Only Move and MoveTo do turn the motor. |
|
|
|
Post by Admin on May 28, 2018 18:25:58 GMT
Which Shieldbuddy pins are being used to drive the TB660?
|
|
|
|
Post by Admin on Jun 1, 2018 10:47:54 GMT
We have now got a TB6600 and a bipolar stepper motor. Using a simple program, the TB6600 works OK with the ShieldBuddy. We will check what happens with the AccelStepper library. There is some code in this which might need to be changed when run on a very fast processor!
|
|
|
|
Post by shieldbuddy on Jun 3, 2018 8:43:35 GMT
Ok, hope you can see what is needed to be changed to be able to run Accelstapper on this fast processsor.
Thanks a lot for the help!
|
|
|
|
Post by shieldbuddy on Jun 7, 2018 15:12:33 GMT
Hi,
Did you had the time to test de library?
tnx
N
|
|
|
|
Post by shieldbuddy on Jun 25, 2018 6:33:01 GMT
Hi,
Are you working on the solution for this problem? or?
tnx
N
|
|
|
|
Post by Admin on Jun 26, 2018 15:10:46 GMT
Yes we are still looking at this! We should have something next week.
|
|
|
|
Post by Admin on Jul 4, 2018 14:50:26 GMT
It seems that the problem driving the Enable pin is down to a quirk in the compiler optimiser. In Accelstepper.cpp, the function "AccelStepper::setOutputPins" needs to be edited:
// You might want to override this to implement eg serial output
// bit 0 of the mask corresponds to _pin[0]
// bit 1 of the mask corresponds to _pin[1]
// ....
void AccelStepper::setOutputPins(uint8_t mask)
{
uint8_t numpins = 2;
uint8_t NewPinState;
if (_interface == FULL4WIRE || _interface == HALF4WIRE)
numpins = 4;
else if (_interface == FULL3WIRE || _interface == HALF3WIRE)
numpins = 3;
uint8_t i;
for (i = 0; i < numpins; i++)
{
NewPinState = (mask & (1 << i)) ? (HIGH ^ _pinInverted) : (LOW ^ _pinInverted);
digitalWrite(_pin, NewPinState);
}
}
The ShieldBuddy digitalWrite() is actually a complex macro and passing a complex ternary statement to it causes a problem!
We have it all working now.
The fixed Accelstepper.cpp is attached....
AccelStepper.cpp (13.62 KB)
|
|
|
|
Post by shieldbuddy on Jul 10, 2018 22:30:20 GMT
Thanks a lot. I will test it as soon as possible.
|
|
