Stepper Motors not working
Shop › Forum › Makelangelo Polargraph Art Robot › Stepper Motors not working
Tagged: stepper motor
- This topic has 17 replies, 3 voices, and was last updated 8 years, 7 months ago by devburke.
-
AuthorPosts
-
2016-04-14 at 09:58 #9401AnonymousInactive
Hey all,
I have had no luck getting the steppers to respond even though the 12v power is getting to the shield and all wires are connected properly according to the laser cut signifiers on the arduino mounting board. The Servo is running fine. I have tried running tests specifically to the steppers and no luck. Any idea of what the problem might be?
Thanks
2016-04-14 at 12:47 #9404devburkeParticipantI’m having the exact same issue. The steppers respond fine when I run Adafruit’s StepperTest program, but when I load the Makelangelo firmware and try to move the motors (either manually or by telling it to draw something), the servo responds just fine, but the motors don’t respond at all. What’s weird is that the servo responds a little even when only the motors should be.
For the record, I’m using the Adafruit Motor Shield v2.3, so I changed
#define MOTHERBOARD 1 // Adafruit Motor Shield 1 //#define MOTHERBOARD 2 // Adafruit Motor Shield 2
to
//#define MOTHERBOARD 1 // Adafruit Motor Shield 1 #define MOTHERBOARD 2 // Adafruit Motor Shield 2
And I changed steps per turn to 200, because my steppers have 1.8 degree steps.
2016-04-14 at 13:00 #9406DanKeymasterJog motors works for both of you?
2016-04-14 at 13:06 #9407devburkeParticipantNope, no response from the motors. Although the servo does respond a bit to it.
2016-04-14 at 19:05 #9409devburkeParticipantWell, I made a little bit of progress. I tried commenting out the loop(), and replaced it with a couple commands simply to step the steppers. Still nothing. Eventually I found this:
#if MOTHERBOARD == 2 #define M1_STEP(a,b) m1->step(a,b,MICROSTEP) #define M2_STEP(a,b) m2->step(a,b,MICROSTEP) #define M1_ONESTEP(x) m1->onestep(x,MICROSTEP) #define M2_ONESTEP(x) m2->onestep(x,MICROSTEP) // stacked motor shields have different addresses. The default is 0x60 // 0x70 is the "all call" address - every shield will respond as one. #define SHIELD_ADDRESS (0x60)
It says default is 0x60, but actually defaults to 0x61. Changing it back to 0x60 made my test commands run, so that’s something. Although it still didn’t work right in the Makelangelo software, but in a different way.
This time, in the software, once I connect to the robot, the steppers kind of gently pulse, like a heartbeat. And if I tell them to move, it’s like they try, but something’s not letting them move. Basically, the heartbeat gets really strong, like one command is telling it to step, while another is telling it to stay.
So it still doesn’t work, but progress I guess?
I also found this on the Adafruit website:
The stepping commands are ‘blocking’ and will return once the steps have finished.
Because the stepping commands ‘block’ – you have to instruct the Stepper motors each time you want them to move. If you want to have more of a ‘background task’ stepper control, check out AccelStepper library (install similarly to how you did with Adafruit_MotorShield) which has some examples for controlling three steppers simultaneously with varying acceleration
Sounds like something we’d need here. And it’s nowhere to be found in the firmware. I’m starting to suspect that nobody’s actually ever confirmed that this program works on a v2 shield. I know it works on a v1 shield, because there’s one running next to me right now. Did someone just add in the code they thought would work for v2 and never actually get their hands on a shield to test it out? I’m not trying to be a pain, I’m honestly wondering if this is confirmed to work at all. I sure hope so, because v1 shield look hard to come by.
2016-04-14 at 19:05 #9410devburkeParticipantAnd by commenting out the loop(), I mean commenting out the code inside the loop.
2016-04-14 at 19:07 #9411devburkeParticipantOh man, I’m sorry, I got sloppy there. The code I quoted is from my fixed version. In the default code, although it says 0x60 is default, 0x61 is actually set.
2016-04-14 at 20:35 #9413DanKeymasterIt’s been a long time since I tested on AMS2, but I still have one set up. The differing I2C addresses are always an issue. I2C is a big bottleneck, and the AMS1 was found to be slightly faster in our testing, those long dark eons ago.
The AccelStepper library is of no use to Makelangelo because it takes control of the step timing away from Bresenham’s algorithm. It will drive one or even both motors faster, but not in a way that will make them both reach spot N at the same time. (as far as I can tell.) I would be very interested if you can figure out a way to use it and still get straight lines.
2016-04-14 at 20:44 #9414devburkeParticipantHm, ok. I hope I didn’t come across rude there, it was an honest question. To the best of my knowledge, work on the AMS2 compatibility was still relatively new, so I figured maybe that was an explanation for the trouble I’ve been having. I guess I’ll keep chugging along and see what I can find. Even with the change to the address, the interaction between the desktop program and the steppers hasn’t worked as it should yet. At the moment, I’m copying the firmware_ams folder into my libraries folder, and changing 3 things in firmware_ams.ino: first is changing the comments to choose the v2 shield, second is changing the stepper steps to match my steppers, and third is fixing the address. Aside from that, I’m running it as is. But connecting to Makelangelo is still not working right.
Anyway, I’ll let you know if I find anything!
2016-04-14 at 20:46 #9415DanKeymasterWe looked into AMS2 as an option, but as time goes by we find that offering (and supporting) fewer options makes life easier for everyone. I admire your tenacity in getting it to go.
From the desktop, send an M114 command (console at the bottom). Then send another. If there’s no reply on the second command, I might have an idea about what’s going on.
2016-04-16 at 12:32 #9432devburkeParticipantOK, so here’s where it stands currently:
I can now get the steppers to rotate, but not as they should. They only move in very small bursts at regular intervals, about once per second, instead of continuously. For example, if I use the jog motor buttons, the steppers move just a little bit at a time, bit by bit, for a long time. Some of the little bursts actually seem to move slightly backwards, occasionally.
Neither the first nor second M114 commands got any response from either stepper or servo. Seemingly no effect at all.
2016-04-16 at 12:51 #9433devburkeParticipantI should add that the pulses correspond to the blinking LED on the shield. As soon as I use the connect menu to connect the Makelangelo software to the board, the LED on the shield goes from solid on to blinking about once per second.
When I run the AF stepper test program, it seems that the light blinks whenever a command is being sent to the motor. So maybe Makelangelo is only communicating with the board once per second?
2016-04-18 at 12:14 #9440devburkeParticipantSo I think I may have found the issue. I dumbly got steppers that draw more current than the shield can provide. I need to get replacement steppers, then I’ll try again.
2016-04-23 at 07:07 #9469devburkeParticipantOk, got my problems solved.
- I was just using steppers that didn’t match the shield. Dumb mistake.
- The shield address in the firmware is set at 0x61, instead of 0x60. Changing that (and, of course swapping the commented lines telling the firmware which shield I’m using) seemed to get it working.
I’m still waiting on my replacement servo, since the one I initially got was counterfeit, and to be able to assemble the whole thing. But all seems good so far, except for the fact that the “Start at line” command doesn’t seem to work right.
2016-05-03 at 11:06 #9562DanKeymasterI haven’t looked in a while. There should be a comment in the code that says “change this address!”
Can you please submit a pull request with an improved helpful note? That way the next person doesn’t get confused.2016-05-04 at 20:50 #9598devburkeParticipantI would, but I’m afraid I’m a bit over my head on this. I used GitHub once for a project about 4 years ago, and even then, it wasn’t forked or anything. I’d be interested in learning, but I’ve been very busy this week, so I figure rather than keep you waiting while I try and learn what I’m doing there, I’ll just respond here for now (would it at least be helpful if I submit it as an issue on GitHub?).
Currently, this is what it says:
// stacked motor shields have different addresses. The default is 0x60 // 0x70 is the "all call" address - every shield will respond as one. #define SHIELD_ADDRESS (0x61)
To me, it seems like it should just default to 0x60, like it says it will. No note to change it needed. However, maybe you have a reason for having it default to 0x61 that I’m unaware of. But disregarding that, my suggestion would be to make it:
// stacked motor shields have different addresses. The default is 0x60 // 0x70 is the "all call" address - every shield will respond as one. #define SHIELD_ADDRESS (0x60)
2016-05-05 at 08:13 #9600DanKeymasterupdated the dev branch just now. Better?
https://github.com/marginallyclever/makelangelo-firmware/tree/dev
2016-05-05 at 21:07 #9623devburkeParticipantLooks good to me! I like the new location too, it makes sense for anyone who’s building it on their own but may not be up for digging all the way in.
-
AuthorPosts
- You must be logged in to reply to this topic.