Can't get correct speeds.

[jka...@gmail.com]

Hey all,

I'm new to stepper motors, and trying to get one working for the first time using the AccelStepper Library, an Arduino Uno R3, and the Big Easy Driver.

I have connected them as specified here:  http://bildr.org/2012/11/big-easy-driver-arduino/

Imported the libraries from here: http://www.airspayce.com/mikem/arduino/AccelStepper/index.html

However, if I try to load up the constant speed example, the motor sputters along at perhaps half a revolution per minute.  I've set the max speed to 100000, and setspeed to 12800, and I'm just about getting one revolution per second.

I am currently using a 12VDC/500mA wall adapter power supply.  Something just isn't right here, as the setspeeds are not corresponding to anything rational.  It is a 200 Step/Rev Stepper Motor.

Thanks in advance,

John

[Brian Schmalz]

With a Big Easy Driver and 200s/r motor, in the default 16x microstepping configuration, you'll need 200 x 16 or 3200 steps per revolution. So use that in your calculations and see if it makes more sense.

Also note that Arduino's can't go more than about 4000 steps/second because of their CPU power. So if you need to more than about 1rev/s with your setup, you'll need to use something faster than an Arduino. For example, chipKIT boards (which are Arduino compatible) work great for this, and AccelStepper runs very well on them without any modifications.

*Brian

---

From: accels...@googlegroups.com [accels...@googlegroups.com] on behalf of jka...@gmail.com [jka...@gmail.com]
Sent: Sunday, November 03, 2013 7:42 PM
To: accels...@googlegroups.com
Subject: [accelstepper] Can't get correct speeds.

--
You received this message because you are subscribed to the Google Groups "accelstepper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to accelstepper...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[jka...@gmail.com]

Ack!

That is a gigantic shame, and a very seemingly-odd limitation of Arduino!  Particularly since our Collegiate Senior Design team just invested so heavily in Arduino systems!  Thanks for the help, Brian.  I assume that because the 4k steps/second limitation is *processing* based, that if we reduced the stepping to quarter steps, we would have a bit more leeway?

To give you an idea of what we're doing, we're creating a seismic Shake Table - using Stepper Motors, the table is moved along a linear track at various speeds, accelerations, and displacements, to simulate Earthquakes to a high degree of accuracy, while staying within a budget that a K-12 Teacher could afford.  I'll have to see if we can get by on Quarter-Steps.  Ultimately, we need a motor that has high reliability, quick direction-switching, high torque (100-200 oz-in / 30-50 kg-cm) so that the motor doesn't simply rip itself apart.

I'll have to look into the chipKits, to see how these work.  We had intended to use Arduino as our sole Microprocessing center in the device, as it is classroom friendly.

Even if we Quarter-stepped it, that means we could easily get 4 rps (240 rpm - which is a bit higher than these stepper motors should be run, and higher than we may need in any event.)  My big question at this point is, if we are doing 3200 steps/second, would that chew threw so much processing power that we wouldn't be able to gather data from the Serial Sensors (accelerometers) and send it to an SD card?  Essentially, our motion control will be telling the stepper motor displacement and acceleration data, on a basis of about 10-20 times per second.  From what you said, I'm getting the impression the Arduino may not have enough raw processing power.

Thanks for your response, Brian!

- John

[Brian Schmalz]

John,

 

That’s absolutely correct. Accelstepper is an awesome, amazing library – I have nothing but the highest praise for the work Mike’s done. One of the downsides of having all of that awesomeness, however, is that it does require some math each time a step is taken, and each time you call the run() function. It’s this math, coupled with Arduino’s 8-bit 16MHz speed, that limits the maximum number of steps per second.

 

With any of the faster 32-bit boards (like Teensy 3.0 – another fantastic product, or chipKIT, or others) the math is done much more quickly, and thus the top speed is correspondingly higher. I have no problem getting 10K or 15K steps/s out of my 80MHz chipKIT boards. (the stepper motor maxes out before the chipKIT does)

 

Your solution to drop down to quarters steps is _exactly_ the right way to go. When you are moving that fast, microsteps have little positional benefit. Dropping down to ½ steps would produce an even bigger top speed and would probably not hurt your actual positional accuracy at all.

 

And you are also correct that moving at high step rates will drop your available CPU cycles for other work almost down to zero. You have to be careful of that – another big issue is that reading analog sensors take an enormous amount of time (in the microcontroller’s world anyway) and so if you do analog conversions using the normal Arduino libraries, you’ll have big gaps in the steps (since you can’t be taking steps at the same time as doing analog conversions).

 

One solution to this problem is to separate out the problem – use one Arduino for moving the motor, and another for taking data and saving to SD. Coordinate them using a higher level protocol – for example, over the USB, coordinated from the PC side.

 

The problem you are running into (system load partitioning) is a very real-world problem that we as embedded systems engineers have to struggle through every day.

 

*Brian

Brian Schmalz  //  Principal Embedded Systems Engineer | product development services

Logic PD
T // 612.436.5134

NOTICE: Important disclaimers and limitations apply to this email.

Please see this web page for our disclaimers and limitations:

http://logicpd.com/email-disclaimer/

[jka...@gmail.com]

Thanks Brian!

Next question regarding your nifty driver :)

I pulled down M1 & M3 to Ground using a 1k Resistor.  Both pins now measure at .4 V instead of 4, well below what is considered 'high' on a uC, but the stepper is still not running any faster.  I seem to be missing something here (apologies, I'm a Mechanical Engineer ~ which should be no excuse since this is rudimentary level electronics / mechatronics...)

On a more philosophical basis, I have a question regarding ChipKIT (This might apply to the Arduino Due, as well).  We are developing this system for wide-spread DIY use in High Schools.  Because of this, unified systems like Arduino are ideal.  This is for three reasons:  1 - Arduino is a well documented playground that has extensive open-source documentation (like here!), has a fairly static specification (units have not become suddenly and irrevocably obsolete), and most important, is coded in simplified C.  

Without having a 32-bit system in my hand (ChipKit, Arduino Due(ARM)), I'm curious just how different the changes would be.  If we're to change uC, it needs to be just as easily programmable as Arduino, and realistically, if we're to convince High School teachers to use our device, it needs to be fully compatible with Arduino libraries, as well as preferably programmable in the Arduino IDE (I'm willing to bend a bit on this one).  I get the impression that the 32bit systems (PIC32, ARM), use different code-bases and other things, such that classroom students can't realistically transition from using an Arduino to using a ChipKit or Arduino Due with ease.  I'm similarly concerned that these 32bit implementations of pseudo-Arduino are just niche enough that they might up and disappear from retail without notice, such that our device would lose Educational value from using 'obscure' Technology.  (I use the term obscure loosely.  You and I both know that it isn't obscure, but in the Education world, anything that doesn't have ten million+ users is considered 'obscure' - C'est la vie)

To give an idea of our processing needs, here is a basic flow chart of our program:

Phase 1:  Control I/O

- User Input Output, involves Serial Comm with LCD & Accelerometers.  Trivial.

Phase 2:  

Phase 2:  Run Phase

- Grab Earthquake Data Points from SD Card or USB Connection

- Calculate Steps, S/s, S/s^2 between every Data Point.  Save to SD Card (or PC)

- Rotate Stepper at 30 rpm, gathering Accelerometer Data.  This calibrates and tells the device what the 'home' position is, if left off at non-zero displacement.

Loop:

     - Take Data from SD Card

     - Send # Steps, Acceleration to Stepper Motor

     - Receive Accelerometer 1 Data (I2P)

     - Receive Accelerometer 2 Data (I2P)

     - Save Accelerometer 1 & 2 Data to SD Card (Or send to PC)

     - Continue Loop to Earthquake Finish

We plan to use all serial connections, but I agree with you that processing power is a concern, but I'm trying to weigh that with my concerns above.  What is the realistic power increase between 8bit 16 MHz and 32bit 80 MHz?  (Is it just 5x, or is it ~20x?)

Thanks for your assistance, Brian.

[Brian Schmalz]

John,

 

You will probably have to fiddle with the current level adjustment pot on the Big Easy Driver. What I suggest to people is to create a very slow, steady pulse train (say maybe 4 hz) and, with it set at 16x microstepping, feel the shaft of the motor as you adjust the pot. You’re looking for the sweet spot where every one of the steps feels equal in size and torque. Once you have that running well, you should be able to switch to ¼ and ½ and full step modes using the M1, M2 and M3 pins and see each step sent to the driver create a different size of step. This is most easily measureable by having it do 3200 steps in say 10 seconds. Then just count the revolutions.

 

As for your other questions, there are lots of things to take into consideration here.  Far too many to effectively communicate in an e-mail. But I will be able to say that we’ve tried to design the chipKIT so that it is as close to the Arduino as possible. With a chipKIT UNO32, for example, all shields that work on Arduino will fit right on the UNO32 board. Also, many libraries will ‘just work’ between Arduino and chipKIT. We use the same IDE as Arduino (We’ve forked it and called it MPIDE so that we could use a different C compiler for the PIC32 rather than AVR). No changes are necessary in AccelStepper code to go back and forth between the two platforms.

 

That said, there are differences, and you will likely need to understand them to make use of  both platforms properly. For example, chipKIT32 (and in fact most 32 bit boards) are 3.3V only on their I/O. They are 5V tolerant, but only output 3.3V. This is fine for most shields, but not all. Also, there are lots of libraries that use direct register access on the ARV – these obviously don’t work on any other platform. And MPIDE is currently only compatible with Arduino 0023, not the newer 1.0 or 1.5.

 

The performance differences between Arduino and the 32-bitters is huge – sometimes considerable more than 20x (depending on the code). For example, I wrote a library for chipKIT that takes advantage of the 80MHz 32-bit PIC32 processor and allows you to output RC servo pulses on every I/O pin simultaneously (all with different values of course), and it still only uses about 10% of the CPU time. (That’s up to 83 I/O pins at once – 83 RC servos going at the same time.) The RAM and Flash are also far, far bigger on the 32-bitters. And they are surprisingly affordable.  But the ‘ecosystem’ around each one is far smaller than the Arduino ecosystem, so you have to be willing to figure stuff out more on your own.

 

It’s a tough call for an educator. It’s easy to get bogged down and frustrated by Arduino, and even more so if you migrate to a compatible, but different, platform.

 

The bigger 32-bit platforms (Due, chipKIT (backed by Microchip), etc.) are going to be around for quite some time, as they’re really the direction that a lot of people will go over the next couple years. (If you could get a 80Mhz 32-bit Arduino for the same price as your 8-bit 16MHz Arduino, wouldn’t you? Lots of people will.) So the critical mass will be moving in the 32 bit direction, and it will only get more supported and more popular.

 

My suggestion is to buy a chipKIT board (maybe the uC32? Or a Fubarino SD if you’re into breadboaring) and a Due and maybe some others and just give it a chance- try running your code on each one, and see where things work and where they don’t. You may be surprised how easily things transition.

 

*Brian

 

Brian Schmalz  //  Principal Embedded Systems Engineer | product development services

Logic PD
T // 612.436.5134

NOTICE: Important disclaimers and limitations apply to this email.

Please see this web page for our disclaimers and limitations:

http://logicpd.com/email-disclaimer/

 

--

[jka...@gmail.com]

This is getting a bit off-tangent from the Goal of AccelStepper, so don't hesitate to stop me if this is better discussed somewhere else.  We're at a 'critical' choice in our design (Use Arduino Due, Abandon Arduino, change Design, or otherwise), so I want to understand a few things about the 32bit Architecture vs 8 Bit.

This is what I currently understand about uC chips.

1.  User Taps Code into IDE (Simplified C, PICBASIC, etc etc)

2.  IDE Verifies, Interprets, and Compiles code such that it can be loaded onto chip.  

Now, with my understanding, the Arduino IDE was designed around placing Simplified C and compiling it onto Atmega chips.  Because ARM (Arduino Due) requires a different compiler, I'm under the impression that, for lack of a better word, code doesn't 'work' as well when created in the Arduino IDE and compiled onto the ARM chip.  (Sorry, Mechanical Engineer, haven't worked with much of this before!).

As such, this worry doubles when I consider something like chipKIT (or anything non-Atmega, for that matter, as that was what the Arduino IDE was meant to compile to).  Diligent has developed the MPIDE such that users can use Simplified C to program (as they would for Arduino).  While it isn't explicitly stated, I sense a hidden subtext that this is not the ideal way to code for the PIC32 chips, and that code may not run as 'efficiently' as it would if developed in a more native Code/Compiler duo.

Furthermore, I'm curious as to some of the reasons the libraries aren't compatible.  For obvious reasons, different boards/chips have different declarations, least of which referring to which pin is which (PWM vs Analog vs etc etc etc).  I'm trying to grasp what the core problem is behind Library incompatibility, if it is a Code Problem (code needs to be made specific to device) or Chip Problem (Code was never meant for PIC32 chip vs Atmega)

In hindsight, I'm a bit surprised that this dogma war over 8bit / 32bit is only going on now.  While Arduino is meant to be a low-cost platform, it has become clear to me just how small 8bit 16MHz of power can be, and with Diligent proving that they can make a 32bit chip for equal cost to Arduino's systems, I'm astonished that Arduino hasn't tried to keep pace.  I agree with you, between 32bit and 8bit, there is no argument - one simply provides far more legroom for processing power than the other.  The former is fine for low end LCD/tinker hobbyists, but the real project-oriented hobbyists are going to need that increased processing power.

[Brian Schmalz]

John,

 

I sincerely appreciate that you’re trying to understand this stuff – I’d be hard pressed to dig this deep into mechanical things. So way to go.

 

Let me correct a number of incorrect assumptions in what you’ve written below, and hopefully it will help you make your decision.

 

1)      We (not Digilent, but we the rag-tag developer group that created MPIDE – which does include Digilent, but also includes a large number of other parties) forked MPIDE from Arduino IDE. The only major change we made was that we added the Microchip C compiler in addition to the AVR compiler. So from MPIDE, you can compile the same code for EITHER Arduino (AVR) OR ChipKIT (PIC32), depending on what board you choose.

2)      Just because something requires a different compiler does not make it any more or less efficient. The ARM, PIC32, and AVR compilers are all different. However, they all interpret the Arduino sketches exactly the same – in the sense that exactly the same input sketches are used – it’s just the output that’s different (by necessity).

3)      There is no hidden subtext about this not being the best way to code. I get very frustrated at the Arduino folks because they seem to keep saying that Arduino is coded in ‘simplified C’ – like it’s some special language or something. It IS NOT. You write a sketch in C++. Normal C++. There are some  shortcuts that the Arduino IDE does for you (like header file inclusion, nice core library support, etc.) that makes your sketch code simpler than a ‘normal’ C++ application, however, it’s still just C++.  There is no difference. There is no performance slow down (because of the language). Writing a sketch is (if you do it right) _exactly_ as efficient in running as writing a C or C++ program, because that’s exactly what you’re doing. The Arduino IDE uses native compilers. It takes your C/C++ sketch, combines it with the core libraries, links it, and downloads it, just like any C/C++ other compiler would.

4)      Like you, I am astonished that Arduino hasn’t come out with more powerful products for lower prices. But that’s not their business model. I’ll leave it at that.

5)      As far as why there are library incompatibilities – there can be several sources of issues when you take a library from Arduino and try to run it on a Due or chipKIT or Teensy 3, etc. If the library ONLY uses built-in Arduino core API calls, and it properly uses the built-in pin defines, then it is almost guaranteed to work without any changes. We have seen many, many higher quality libraries (like AccelStepper) run perfectly well (in fact, run WAY better) on chipKIT without any changes. If the library author needed to use specific registers in the low level chip, and bypassed the Arduino core API, then the library will not work on other boards without being tweaked. Sometimes these tweaks are very simple, and sometimes they require re-writing quite a bit of the library. Different libraries will have different reasons for not being compatible. Maybe one library needs 6 PWM outputs in order to be useful – and chipKIT boards only have 5, so it will never run on the chipKIT boards. Maybe a library makes an assumption about how a particular peripheral works, and this works fine for some boards, but for other boards that peripheral is slightly different, and so doesn’t work quite right until the library’s author makes the necessary board or chip specific code changes. (This is a problem even between Arduino AVR boards – like between the UNO, Leonardo, Micro, etc.)

 

I hope that helps-

[jka...@gmail.com]

Thanks again for your time, Brian,

My last philosophical question for the moment regards the Arduino Due.  Now that I know that our code is transferrable to any like-device (as long as we recognize / account for changes in library, pin declarations, etc), we can proceed while still looking for the 'optimum' Microcontroller for our needs.

For the moment, we'd like to start with the Due, because it is a familiar change from the Uno.  This doesn't preclude use of other devices like chipKIT or other 32bit devices, but it is merely a quick way to get us to our prototype deadline without starting in completely unfamiliar territory (which we'd be more willing to do after our next deadline). 

Do you feel that there are any 'severe' limitations or flaws that the Arduino Due has that we should strongly avoid using it, as compared to other 32bit Microcontrollers?

The only major drawback I see as compared to other systems is that the Due has zero 5V protection on its I/O pins, so one has to be absolutely careful that Voltages are 3.3V or lower, lest the board get toasted.

Thanks again for all of your help and taking time out of your day!

On Sunday, November 3, 2013 6:42:22 PM UTC-7, jka...@gmail.com wrote:

[Brian Schmalz]

Honestly, I've never used a Due, so I don't know. I've hard bad things about it though, from friends who have. Problems with core libraries still not working right, difficulties with hardware issues, etc. I have not confirmed any of  this myself, so I don't really understand exactly what's "bad" about the Due. It may be just great.

*Brian

---

From: accels...@googlegroups.com [accels...@googlegroups.com] on behalf of jka...@gmail.com [jka...@gmail.com]
Sent: Monday, November 04, 2013 5:03 PM

To: accels...@googlegroups.com
Subject: [accelstepper] Re: Can't get correct speeds.

--

[jka...@gmail.com]

Thanks for the input -

Now that I'm back home from work, I'm tinkering again.  Just cannot figure out why this won't even run at a constant speed.

I noticed that the Stepper I'm using is rated for 12, and I was only supplying the Driver 12.34 (Wall Wart PS).  I measured voltage on A1/A2/B1/B2 and got 6.9V across the board, which is lower than the needed 12.  So now I hooked up two 12V Wall Warts in series, measuring just over 24.4V.  Now I'm getting 14V on A1/A2/B1/B2, but no noticeable change.  I have tried fiddling with the onboard potentiometer.  It runs at the same speed at every point on the Pot, except at one extreme end.  At the far "positive" end (mismarked by Manufacturer), it will speed up ever so slightly before beginning to stutter, while making a 30 dB audible electrical 'squeak' from the Motor.

I'm using the 'Constant Speed' Example from the AccelStepper library, with the only change being the stepper.setSpeed(400), which should equate to 1 rps for Half-Stepping.  For Half Stepping, I have connected M2 and M3 direct to Ground, no resistor this time.  Attached is a picture of what I have done.

The Arduino is a SparkFun Redboard being powered via USB.  The GND Pins are connected on either device, Pin 2 Direction, Pin 3 to Step.

Increasing the voltage made the Motor too hot to touch for more than 2~ seconds, but the driver remained warm, but completely comfortable to touch for long periods.  Even 5 Minutes after disconnecting, Motor Surface is around 50 C.

I'm puzzled as to why I can't even get some accurate slow, half-step motion control.

[Jon Magill]

John -- Just a random question, since you haven't posted a sketch, are you using serial for debugging, with print(); or println();?

When I was first starting out with steppers I couldn't figure out why I couldn't get them to go faster than a certain speed... when I did the speed calculations in reverse, it turned out my motors were running at the equivalent of 9,600 steps per second, same as I had my serial baud rate set. When I commented out the serial debug lines, everything worked as expected.

YMMV,

--Jon