Maintenance notice: These forum archives are read-only, and will be removed shortly. Please visit our forums at their new location, https://www.evilmadscientist.com/forums/.

400 steps / revolution steppermotors higher speeds than 1000 steps per second

StefanL38StefanL38
edited March 2014 in Egg-Bot
Hi,
I builded an Egg-Bot myself. Now I've mounted stepper motors with 400 fullsteps per revolution to be able to draw at a higher resolution.
I made some speedtests. As the new motors are 56mm 1,7A 0,89Nm I guess I can drive them pretty fast.

But when I tried more than 1000 steps per second the thing goes crazy. The pen-motor jumps very quickly than
the stepper is stalling. this happends even at 1100. While 1000 steps per second is moving the pen quite easy.
Is this a problem of the firmware? If speeds higher than 1000 steps / sec where used the firmware gets out of snyc?

does anybody now how to manage that?

best regards  

  Stefan 

Comments

  • EmbeddedManEmbeddedMan
    Hi Stefan. The EBB uses some very simple math to determine the time between steps, based on the number of steps in the SM command, and the amount of time that you ask the move to take. There are some higher steps speeds (like you've found) that cause this math to 'break' and give incorrect results (i.e. motors go crazy). Because the EBB never needs speeds this high, the existing firmware is just fine for normal EggBot use. But you're in a special situation!

    I am currently working on an updated EBB firmware that will solve some other long-standing problems (none that affect EggBot usage) and add some new features (like being able to handle very long moves). I will also now add to my list of things to do your request - to be able to handle faster step speeds. If the EBB is not able to produce smooth steps, it should report back an error (i.e. not say "OK") rather than making the motors act crazy. 

    Now, this same type of problem may be happening because your input voltage is not high enough for the motors you are using and your current adjustment pot is set too high. So, can you try this for me? Run your motors over and over at the higher step speeds, and very carefully adjust the current adjustment pot slowly in both directions and see if you can get smoother movement than you're getting now. You can also try using higher input voltages to the EBB which will help produce more torque at higher speeds.

    Let us know what you find, and I'll get to work on improving the firmware.

    *Brian
  • EmbeddedManEmbeddedMan
    Stefan,

    I just did some testing with EBB v2.0.1 firmware. I have no problem running my motors at step rates up to 32,000 steps/s.

    I have some 400s/rev steppers that I'm using for testing (like your setup). Since we have 16x microstepping, this should provide me with 1 full revolution at 6400 steps. So I executed the command:

    SM,1000,0,6400

    I saw my motor move exactly 1 revolution in exactly 1 second (timed with a logic analyzer on the step signal to the motor driver chip). This proved that we are able to handle step speeds up to 6400 steps/second no problem. The motor moved very smoothly.

    Since the largest step value you can use with SM (in this version of firmware) is 32,767, I decided to pick a nice round number of 32,000 steps. I then did 

    SM,1000,0,32000

    And saw exactly 5 rotations (as expected). However, the timing is off - the total move took around 1.4 seconds, and the pulses to the motor driver were not equi-spaced in time. The way that the EBB generates pulses, each pulse has to line up on a 25KHz ISR boundary, so the fastest step rate we'll ever see is 25,000 steps/second out of the EBB. Since I'm asking it to do 32,000 steps/second, it still took the exact right number of steps, but it had to spread them out a bit and thus take longer than 1 second.

    Again, my motors smoothly moved the 5 revolutions. Even thought the pulses sent to the motor driver were not perfectly smooth, the mechanical system of the motor smooths them out and we get smooth motion.

    So, in answer to your question: can the EBB support step speeds above 1000 steps/second? Yes, absolutely it can, as these experiments show. Up to about 25,000 steps/second, things should work as you expect.

    My guess, at this point, as the the cause of your issues is a mis-adjusted current adjustment pot on the EBB. It appears that the firmware is doing what we expect of it.

    *Brian
  • StefanL38StefanL38
    Hi Brian,

    thank you very much for your testings and info. Next thin I will do is checking the firmwareversion.
    I noticed another effect/bug.
    With a 400 steps per rev. Motor the canvas is 6400x1600 steps. If I use the hole area of 6400 steps
    some parts of the drawing is shifted to another position. So this caused me to think that the software is "thinking" 
    oh I'm near to one full revolution (which normally is 3200) I'll do move optimisation and moving backwards to the new position. 

    As long as I do a move that does only move the egg-axle everything is OK but if a try to draw some small rectangles
    that are distributed over an area of 6400 pixels the rectangles that are beyond the 3200 steps border get misplaced.

    If you tested the command SM this sounds like sending a single command to the EBB. Did you do some testing with the Inkscape-extension?

    Is this problem located on the EBB or in the Inkscape-extension?

    best regards  

     Stefan 
  • ragstianragstian
    Hi.

    Have you selected the "Egg (x) axis wraps around" in the options tab?

    RGDS
    Ragnar
  • StefanL38StefanL38
    Hi Ragnar,

    yes the Egg(x) axis wraps around option is activated. should it be disabled?

    best regards  

    Stefan
  • ragstianragstian
    edited April 2014
    Hi

    I plot designs 6400 wide on my 3200 pixel eggbot (1.8° motor) without problems
    ( with the "Wrap around" option enabled )

    The largest canvas size I have used was 32000  pixels (to get a 10 turn spiral of text on the egg - the text go between diagonal corners).

    What happens if you plot a continuos line?

    I might get a 0.9° motor for some experimentation, reckon the added resolution won't be of much use since the arch length for a 48mm diameter egg will be 0.047mm/microstep for the eggmotor and 0.069mm/microstep for the pen (70mm dia circle). What's your experience plotting with this motor (apart from the above problems).

    RGDS
    Ragnar


  • StefanL38StefanL38
    edited April 2014
    OK so I have done some more tests.

    As long as I run the motors over the manual function I can increase speed up to 10000 steps per second.
    the Inkscape-plugin limits the speed to this value. So as the number of steps is limited to 3200 steps through 
    the inkscape-plugin.

    in plotting a drawing thinkgs work as expected up to a speed of 1000 steps/sec.
    As soon as I go over this limit even at 1001 steps/sec The motors are driven at a much higher speed.
    I estimate 5000-10000 steps per second. It is the same thing for speed pen up and pen down.
    Whenever one or both of the speeds are over 1000 steps/sec the motors run at a much higer speed when I try
    to plot a drawing.

    So does this mean that the InkScape-plugin has a bug that it calculates the wrong speed?

    EDIT:

    I took a look into the python sourcecode
    I guess these lines cause the problem


    self.nTime = int( round( 1000.0 / self.fSpeed * distance( self.nDeltaX, self.nDeltaY ) ) )
    strOutput = ','.join( ['SM', str( self.nTime ), str( self.nDeltaY ), str( self.nDeltaX )] ) + '\r'
    self.doCommand( strOutput )

    nTime = int( math.ceil( 1000 / self.fSpeed * distance( self.nDeltaX, self.nDeltaY ) ) )

    I did'nt analysed the code in detail but I guess because these calculations are based on "1000" 
    that values above 1000 are causing the problem.

    best regards  

    Stefan
  • StefanL38StefanL38
    EDIT2:
    through some more try and error I found this codeline
    strOutput = ','.join( ['SM', str( td / 4), str( yd2 ), str( xd2 )] ) + '\r'  #this line determines the plotting-speed 

    The first parameter of the SM-command is "duration" which means the time within the move to the new coordinates
    shall be finished. So a smaller value means less time => higher speed. So I added a "/ 4" divide by four
    to get shorter duration-values. This means now the speeds setup in the eggbotcontrol must be multiplied by 4
    to get the real speed. 

    But that's no good coding-style. Can somebody explain to me how the code works or modifying the code in a way that higher speeds than 1000 steps/per second is possible and the speed-value in the eggbot-control represents the real speed? 


    The construction of my DIY-eggbot-mechanic has to parts that form the arm holding the pen.
    Inside this arm there is a little play (space) which means the horizontal part of the arm can move a little bit where it shouldn't. You can seen this at higher speeds as overmove of the pen through inertia. 

    Any ideas on how to get rid of the play? The original Kit has a a plastic joint which is just one part.
    Very clever solution cheap and stiff against moving and as it is just ONE part there is no space for play possible.
     best regards  

      Stefan 
  • ragstianragstian
    Hi StefanL38.

    Good catch on the coding.
    Using "hard-coded" values in (any) code is a 'pain in the neck".
    It' is used "all over" in the inkscape extensions,
    I have changed most of my extensions where I need higher default values - like in the
    "Render - Parametric curves" the max value for the independent variable "t" is 1000,
    if I use the "degrees" option this will plot less than three "revs:" I have set it
    to 100000 in the "param_curves.inx" - I then store the extension files in my %appdata%
    folder ("C:\Users\Ragnar\AppData\Roaming\inkscape\extensions"on my win7 system)
    - the files here will not be deleted by uninstall / install of Inkscape.
    You can do the same to increase the too low step/second value in the eggbot.inx file.
    Having experimented with higher step values in my standalone driver program my motor fails to move fast as it is not accelerated or ramped up/down.
    How do you overcome this?

    For the pen arm play you will have to 'design out" the play.
    I agree that the original design is "clever" and very simple doing a very good job.
    Two changes to the original design would be beneficial.
    In the original design the pen tip moves along an arc when the pen is lifted, when changing pens the getting the "new" pen height just a tiny fraction different from the previous pen height will introduce a "large" offset along the X-axis. I am working on a design where the pen moves straight up/down when lifted/lowered to remedy this. (there are already one in thingiverse).
    Another "problem" in original design is that it's possible to "twist" the pen along the x-axis as the hinge part is not stiff enough. (using the optional "stiff" hinge almost eliminates this problem though).
    I use extra force (provided by a rubber-band) to keep the pen down as some of my pens require this "extra" force to work.
    The RC-Servo does not "like" the constant force provided by the rubber band in the up position.

    I try to come up with something "simple" that can be mass-produced using the existing technology (laser cutter) of EMS.
    Currently I have a design on my napkin using a wedge (moved by the servo) lifting the pen.
    Another change I would like is to move the pen arm servo off the pen arm to reduce the "moment of inertia".
    By having the servo link operating in the center of the pen arm motor axis the servo can be attached to the eggbot frame.

    Good luck "pimping" your eggbot ;-)
    Thanks to the EMS team for providing me hours and hours of fun!
    RGDS
    Ragnar

  • StefanL38StefanL38
    edited April 2014
    Hi Ragnar,

    I guess my motors can move pretty fast because of the specs
    current up to 1.7A holding torque 0,89 Nm.

    I bought them from here

    For pen Up/Down I got the idea of a linear magnet. But maybe the move down is to fast damaging the pen.
    Would you mind to share your modified construction?

    For exact repositioning the pens. One idea that I have is to mount some kind of quick mount/release part
    on the pens which have a standardised shape which can be mounted / released easily in an exact position
    on the arm. some kind of a cone or at least something rectangular where you push both parts together
    on plane surfaces.

    As I have looked into the code. The protocol seems to be quite simple. Send duration, Motornumbers and coordinates sending back "OK"

    I'm coding for the 8-core propellerchip. There are step/dir drivers that include ramping. 
    But I guess it is still some weeks of work to get a propeller-based EBB to work with the existing
    EggBot-extension.

    best regards  

      Stefan 
  • Windell OskayWindell Oskay
    There is a lot of stuff in this thread, and I do not immediately have all of the answers.  Some things that I can add, though:

    1.  The Eggbot Control extension does have a facility for adapting to the 1600 step/revolution resolution: Add a new, empty file in the directory called "motor1600", and it will make that switch. Look in the code for how that works, and it should be straightforward to use that code to instead adapt it to work at 6400 step/revolution resolution.  This one scaling factor should (hopefully) take care of most of the "hard coding" problems that you are describing.

    2.  The 1000 speed limit has never been a problem before, since the Eggbot does not generally work nearly that fast.  An actual bug is that you should not be able to set the input value to 10,000, but instead to 1000 max.

    3.  The WaterColorBot extensions for Inkscape use much of the same code, but with a little more flexibility and fewer hard-coded values.  It uses an external configuration file "wcb_conf.py" where you can set some of those numbers like DPI and relative speed scale.  You may want to look at it for additional examples.

    4.  We did come up against the 1000 speed limit in the WaterColorBot code, and fixed it as follows:

    Eggbot code:
     nTime = int( math.ceil( 1000 / self.fSpeed * distance( self.nDeltaX, self.nDeltaY )))

    WaterColorBot code:
     nTime = 10000.00 / self.fSpeed * distance( nDeltaX, nDeltaY )
     nTime = int( math.ceil(nTime / 10.0))


  • StefanL38StefanL38
    Hi Windell,

    thank you very much for your answer.
    I will test this tomorrow.

    How about a pen-adapter for exact repositioning made by a 3D-printer?

    best regards  

    Stefan 
  • Windell OskayWindell Oskay
    >How about a pen-adapter for exact repositioning made by a 3D-printer?

    There are a few different ways that we could go about making an adapter for high-precision multi-pen positioning, but we wouldn't make any of them on a 3D printer.  In practice, we've always been able to reposition the pen to a degree that it hasn't been a significant concern.   

    What we really need is a way to reposition the egg exactly once you take it out and put it back in.  That's one that I do not have a good solution for.
  • StefanL38StefanL38
    Hm that's seems to be pretty hard to do.
    Why would you like to take out the egg and then put it into the eggbot again? Why not do all the marking at once?

    my spontaneous ideas:

    two sticks in V-shape above and below the egg to center the egg while rotating the egg axle

    mounting a non-marking pen doing a "dummy marking"

    mounting a laserpen with a real small light-point starting a dummy-marking of adjustable length (number of lines) watching the deviation and then correct egg or arm-position

    repeat this until dummy-marking fits sufficient to existing marking


    best regards  

    Stefan 
  • Windell OskayWindell Oskay
    >Why would you like to take out the egg and then put it into the eggbot again? Why not do all the marking at once?

    Certain important processes require that. :D
  • StefanL38StefanL38
    Hi Windell,

    I made the modification factors 10000 and 10 to setup higher speeds.

    Through step_scaling_factor = 0.5  now I can use the standard svg-files without modifiyng 
    the documentsize to 6400x1600. And this did even cover speed-adjusting.

    Thank you very much for the tip.

    As I could test now higher speeds. It turned out that my arm is not stiff enough for speeds of more than 1200 steps
    per second. (which means 2400 steps per sec for a 400-fullstep/rev motor)


    I found another thing that is a bit annoying. Somewhere in the sourcecode I read that 
    if option start centered is chosen the first line has to start at a centered position.

    What's so hard about calculating the difference between a first position with ANY coordinates
    and the centered position?

    As I started to modify the code. I have several ideas how to polish the code 
    remove hard coded factors that they CAN be replaced through parameters
    if parameter not found use hardcoded default value.

    How about using the *.INI-file standard Identifier=value?
    I'm a delphi programmer
    does python support INI-file-reading writing with commands or would I have to write everything from scratch?

    changing move-direction in the manual register through +- is annoying. 
    How about more buttons to just do a click on each command?
    Where is the GUI of the eggbot control defined?

    How much evolution of the python-code would you allow?
    should it be 100% downwards compatible or would you allow changing some things?

    best regards  

    Stefan
  • Windell OskayWindell Oskay
    Hi Stefan,
    I would appreciate any code polishing that you are interested to perform, especially ones that help to remove fixed factors that should be changeable.  However, please keep in mind that our primary concern in "official" Eggbot driver software is reliability-- and we have in the past gone so far as to remove features that reduced reliability.

    There are a great many improvements that are possible.  However, we have made the decision to implement the Eggbot software within the framework of an Inkscape extension, which does have some (well, many) restrictions on what is possible.

    The Eggbot control software has, at times past, included separate file saving and reading capabilities, and live buttons to control manual movements.  However, we were also plagued by poor reliability, and (especially) poor cross-platform compatibility.  I am the one that made the decision to strip the software down to be a "real" Inkscape extension, and it has had a very positive effect in that the software is generally quite reliable.  However, I do also feel quite limited by it, and we have often thought of using an entirely different approach. 

    The GUI for the extension is defined in the .inx file; only a few types of GUI elements are possible, and (most unfortunately) only the "Apply" button can actually launch the program.   There are some possibilities for how to get around this-- for example, one might imagine an extension that puts the Eggbot into "live arrow key" mode, until you hit the escape key.  Or, one could use the Extension framework to launch an independent program (e.g., RoboPaint, in its Eggbot painting mode), rather than a "true" Inkscape extension.


Sign In or Register to comment.